Re: Shrinking the C core

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Unix which? Unix is not a single program; it is a family of operating
>> systems, and I am quite sure nobody runs the same kernel they did back
>> in 1970. I don't know what you are talking about you have
>> "demonestrated". You said yourself *was* and not *is* which suggest
>> that those kernels are rewritten in order to support those C programs
>> that can be interlocked. Again you are constructing yourself things
>> here: I haven't said it is impossible to write mulththreaded C
>> application that can use locking.
>
> Each extant Unix system today contains gobs of code derived from the
> Unix kernel developed at BTL in the 1970s.  None of their kernels were
> ever rewritten -- rather, they were subject to iterative refinement that
> eventually allowed them to operate on SMP systems.

The word "rewritten" does not imply any time frame.

>> There are many applicaitons that have been redesigned. Emacs has been
>> redesigned since its first incarnations as TECO editor if I have
>> understand the history. For the very last time: I haven't said Emacs
>> *can not be redesigned*, on the contrary, I said Emacs *should be*
>> redesigned. Emacs core so to say. You are fighting against things I
>> haven't said; I don't know why, if it is lack of English skill, or
>> something else, but we are talking constantly beside each other.
>
> Perhaps you define the word "rewrite" differently, but its customary
> meaning implies a reimplementation from square zero.  My point is that

Perhaps you should concentrate on C coding not on your work to define
English dictionary?

>                                                       My point is that
> doing so is a gratuitous and unnecessary gesture, and we would be better
> served by more realistic assessments and consequently more reasonable
> proposals.

Yes, you have expressed a year or more ago as well I should be forbidden
to talk about Emacs. :). Perhaps you shouldn't have answered; nobody has
forced you.

I discuss gladly any technical aspects; actually that was my
hope; but I am certainly neither amused nor very interested to discuss
neither my character as you implied in another answer in this thread,
nor meaning of words in English language. I have expressed an idea in a
thread I found interesting, if it bothers you for any reason, tough
shit, don't answer.

>> Are you saying that a non-multihtreaded program written in C can
>> suddenly become multithreaded without being re-written to support
>> threading? Nevermind, you are totally, on purpose or lack of
>> understanding, missing the point: you have to rewrite stuff to make it
>> multithreaded regardless of the language if you intention is to have
>> Emacs core multithreaded. Supporting multithreading is not same as
>> having entire Emacs internals be multithreaded.
>
> Since when does interlocking call for a rewrite?
>
>> No, it does not because you have missunderstood that I mean something
>> else.
>
> Then clarify what it is, for the plans you present (rewriting Emacs in a
> different language) sure resemble plans for a complete grounds-up
> reimplementation.
>
>> I propose porting core API to Common Lisp because that would save you
>> implementing all those things that you need to make Emacs
>> multithreaded, better GC etc, because it is not a trivial task.
>
> At the cost of portability and control?  No, thank you.
> Let me ask a question in turn: how many of the popular and often-cited
> Common Lisp implementations are as old as Emacs?  What guarantee is
> there of their continued existence 10 or 20 years into the future?
>
>> Of course you can re-write all that stuff in C too, nobody is denying
>> that it is possible. I am saying there is no need to reduplicate the
>> work, and there are other benefits of having Emacs in Common Lisp.
>
> The work to be duplicated is menial and more-or-less already complete.
> The remaining bulk will need to be tackled irrespective of the language
> used to implement Emacs.  The conclusion as to whether we should
> overcome that bulk as-is, of if we should compound it with the challenge
> of rewriting Emacs in a new language, is left as an exercise to the
> reader.
>
>> Look harder.
>
> Any examples?
>
>>>> Well yes, C is portable and fast, nobody denies that. So are some
>>>> CL
>>>> compilers. 
>>>
>>> Which Common Lisp compiler is capable of linking with Java code
>>> through
>>> the JNI?  (ABCL doesn't work, as the Android JVM can't interpret the
>>> bytecode it generates.)
>>
>> I don't know what you are trying to say; that sound like very
>> uninformed statement based on missunderstanding. Calling Java via
>> native API and generating bytecode that runs Lisp on top of Java as
>> ABCL does are two completely different and separate things. I am quite
>> sure Emacs does not generate Java byte code. But I don't see how is it
>> even relevant, I haven't suggested to run Emacs on JVM. Perhaps it is
>> possible who know, but I have suggested to use sbcl which is a native
>> compiler specialized for compiling Lisp (and runs on Android as well).
>
> It's not possible to load a Common Lisp image into the JVM, because the
> Java linker is only capable of linking compiled C objects that export C
> symbols.  Therefore, SBCL cannot run within any GUI Android program,
> given that they must be started from Java.
>
>> "only" ? :-) I can asure you that Lispers have access to both kernel
>> and user space threads. Search on Bordeaux threads.
>
> That's only a wrapper library for the incoherent threading primitives
> furnished by different Common Lisp implementations.
>
>>> garbage collection strategies vary between machine types.  I'm sure
>>> we
>>
>> Does it?
>
> Yes it does.
>
>> I am also sure everything is possible, it is software, as a wise old
>> grey head once said. It is just how much effort and resource you are
>> pouring into it. SBCL runs on basically all important platforms on
>> which Emacs runs, minus as mentioned DOS and Windows95; I don't know
>> if there is some other. But it is not the point. The point is: there
>> is another community working on the same problems you have or wish to
>> solve. And they have come far away than you. You could re-use their
>> work, and if you miss somethign add those missing parts so everyone
>> would benefit, or you can live in an isolated island and do everything
>> yourself.
>
> C is hardly an "isolated island".  Anyway, we need a portable, fast,
> flexible and ubiquitous language, and Common Lisp doesn't fit the bill:
> if a platform as anodyne as Android poses problems for it, what about
> the next sandboxing contraption for Unix systems?  Or any future system
> whose appearance down the line we cannot anticipate now?  What if our
> requirements outgrow Common Lisp's capabilities?
>
>> I am telling you that sbcl/ccl has already solved those problems you
>> have to solve in order to have multithreading without having to lift
>> your lock.
>
> We have too.  What we have not, they cannot offer either.
>
>>> Instead of denigrating the C language, Emacs's C core, and so many
>>> other
>>> components critical to Emacs that have been subject to unjustified
>>> invective in recent times, why not direct your attention to a more
>>
>> I don't think I understand how I "denigrate the C language" and what
>> "unjustify invective" in this case is, but I don't think it
>> matters. Once you also said I should be forbidden to talk about Emacs.
>
> It does, because such motives drive people to engage in many hours of
> time wasting wild goose chases, all to ascertain which language
> Providence meant for Emacs to be written in.
>
>>>                                    direct your attention to a more
>>> productive task, such as identifying the complex interdependencies
>>> between different pieces of Emacs's global state to establish a
>>> detailed
>>> plan for their interlocking?  For this task, the most important tool
>>> is
>>> a control-flow visualizer such as cflow, and an ample supply of
>>> paper.
>>
>> Can we save nature and our selves?
>
> Parse error, sorry.

You mean sorry but no sorry?

Look; you are always indulging into Twitch/Reddit style trolling which
in my opinion has nothing to do with your English skills as Eli suggests
and warns about.

I am fully aware that your aggressive tone and way you speak to me are
because of your assumptions that I am an idiot, and you were not the
only one on this list. You are completely free to have any opinion about
me, I can't care less.

Consider if it is good for Emacs and GNU projects to alienate people who
are willing to help, and if it is representative for the free world to
tell who should be allow to speak and what about.

>> Nor are you sole Emacs devs, aren't you? I don't think calling names
>> is appropriate, so I want, but I can come up with at least four people
>> who work on Emacs and who are experienced Lispers. How active they are
>> in development recently I don't know, I don't follow the list every
>> day as I am used to, but I certainly haven't targeted Eli nor you with
>> that one.
>
> Names?  Would they be willing to take responsibility for the areas which
> we oversee, in the event a Common Lisp Emacs comes to pass?