Re: Shrinking the C core

[Po Lu]

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.

> 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
doing so is a gratuitous and unnecessary gesture, and we would be better
served by more realistic assessments and consequently more reasonable
proposals.

> 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.

> 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?