Re: Shrinking the C core

[Arthur Miller <arthur.miller@live.com>]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think you have missunderstand what I mean; I can try make it clear
>> that I mean parts that considers Emacs core, shared state and so on.
>
> That's what I was referring to, yes.
>
>> You are missing the point: I wasn't talking about *who* changed the
>> Unix; the point here is that it got *changed*.
>
> My point is, Unix has demonstrated many times over that programs written
> in C can be interlocked, and doing so is more productive than a rewrite.

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.

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.

> in C can be interlocked, and doing so is more productive than a rewrite.

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.

>> None. And nobody has suggested that such issues exists either, it is your
>> construction. On contrary, I am saying that Emacs should undergo such
>> transformation :).
>
> That contradicts your assertions below, where you propose returning to

No, it does not because you have missunderstood that I mean something else.

> the drawing board to produce an Emacs written in Common Lisp.  Curiously

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.

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.

> enough, I can't locate any precedent for large and complex Common Lisp
> programs being modified for multi-processor operation.

Look harder.

>> True. MS-DOS and Windows 95 would have to go away. Perhaps some other
>> popular OS from 1980s-1990s? 
>
> They wouldn't have to go away if Emacs remains written in C.

Tough argument indeed.

It is certainly very importnat to keep the development back to
support two ancient non-free OS:s.

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

>> Nobody said it is "panaceas". But sbcl would provide a better lisp
>> machine, in terms of garbagecollector, threading etc; something you will
>> have to develop for Emacs eventually. You heard that one about a guy
>> with name Isaac Newton and standing on shoulders of others? :)
>
> SBCL only supports kernel-based threads on a handful of systems, and its

"only" ? :-) I can asure you that Lispers have access to both kernel and
user space threads. Search on Bordeaux threads.

> garbage collection strategies vary between machine types.  I'm sure we

Does it?

> would be capable of supporting more while remaining portable, and Common
> Lisp leaves much to be desired as a pair of shoulders to stand on.

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.

>> Just reimplementing the C core would not, because you wouldn't use
>> multiple threads. But if you would like to thread Emacs command loop or
>> internals itself, than you would have to reimplement it that way of
>> course. Think of Java Swing; at least 20 years ago when I war
>> programming Java, it was not thread safe, but worker threads were OK.
>
> You're okay with Emacs crashing if threads, wielded incorrectly, trample
> over internal state?  If so, the global lock could be lifted from Emacs
> Lisp in under a week.

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.

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

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

>> I am sure present maintainers are well versed with CL, just not very
>> interested to rewrite Emacs in CL; and I wouldn't expected them to be
>> either :-). 
>
> Two data points: I'm not an adept Common Lisp programmer, nor is Eli.
> I'm not even an Emacs Lisp programmer by vocation.

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.