Re: Emacs rewrite in a maintainable language

[Eli Zaretskii]

> From: John Wiegley <address@hidden>
> Date: Mon, 12 Oct 2015 13:11:30 -0700
> 
> > 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?
> 
> Picture what we currently write in C, but a Lisp syntax, and all the macros we
> currently use removed. So, the essence of our C, written like it was Lisp.

I did picture that.  That's why I'm asking.

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.

> If that Lisp can get close enough to Emacs Lisp, so that knowing one means
> knowing the other, we've just made it easier for anyone to write what we now
> have to write in C.

Sorry, I came to the conclusion that I don't really understand what
this means in practice.  So I'm asking for examples.

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?

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

> I can imagine that complex things, like type declarations, would be done with
> anti-quoted blocks, or by direct support for inclusion of header files.

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