Re: Emacs rewrite in a maintainable language

[John Wiegley <johnw@newartisans.com>]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> > On second thought, I don't think I understand the idea at all. What does it
>> > mean "a Lispy language, easy to learn"? Is it a Lisp dialect, or is it C
>> > with a set of Lisp-like macros preprocessed into C? What exactly are the C
>> > aspects that we are trying to save the programmer from? And which part(s) of
>> > the core do we expect to be able to rewrite in this "Lispy" language?

> Can we please see a couple of examples, as a kind of concept demonstration,
> just to feel the taste of this? For example, how would you write make_frame
> in this language? (This would be an example of creating a Lisp object which
> is backed up by a large C struct that has members not visible from Lisp.)
> Will we have some kind of 'defstruct' in this "subset"? How will we
> distinguish Lisp objects from C objects?
>
> Also, please try to answer the other questions I asked above. I think they
> are important for us to understand what exactly is being proposed and what
> do we try to accomplish.

I'd like to heartily second these requests from Eli, as I wonder the same
things.

> If this means we will have C code written in Lisp syntax, then are you
> saying the syntax of C is the main difficulty for understanding the C core
> code? E.g., let's imagine that we rewrote the display engine this "Lispy"
> language -- do we really believe it will be easier to understand and
> maintain?

Not the syntax of C itself, but the macros and tests that happen within that C
code. The Lispy language *should* be more transparent as to the intent of the
function. But as you say, we need to see real examples of this before anyone
should believe that.

> Or what about regex.c -- are we going to "lispify" that?

I don't know how much C we should get rid of, actually. At the very least,
we'd need C to bootstrap the Lispy compiler, for portability.

> So we will have a mixture of C and Lisp, or C blocks within Lisp code? How
> will that help readability and maintainability?

I think the idea was just to shrink the surface area of the C code, and get
closer and closer to "everything in Lisp". But as you say, we'd need to see
some experiments first.

The C we have works for us, so this idea is pretty low priority. As you wrote
in another thread, there are several, higher priority items that would win us
more contributors faster (documentation, etc). Even changing from C to a Lisp
would not be a silver bullet: the display code would still be a hard problem
to solve.

John