[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: plists, alists, and hashtables

From: Pascal J. Bourguignon
Subject: Re: plists, alists, and hashtables
Date: Fri, 07 Aug 2015 13:47:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Fri, 07 Aug 2015 09:53:05 +0200 "Pascal J. Bourguignon" <address@hidden> 
> wrote: 
> PJB> And this is why we feel the lack of reader macros, since that would
> PJB> clearly allow you to write a new syntax in a user library, instead of
> PJB> having to beg it from the emacs lisp language itself.
>>> Is this work already planned?
> PJB> Well, once emacs got to git, I cloned it to do that, add CL packages and
> PJB> reader macros to emacs.  But unfortunately I've not worked on it since.
> PJB> But I'm planing a take over :-)  I'm writing a C parser in CL, so that I
> PJB> may read the C sources of CL, and then translate them into maintainable
> PJB> CL.  Then I will be able to compile a CL GNU emacs core, that would be
> PJB> 100% bug-for-bug compatible with GNU emacs, and on which you could run
> PJB> all the .el (and even .elc) you'd want.
> PJB> But since the core would be written in CL, I could now provide features
> PJB> found in CL and in CL implementations, such as FFI, threads, packages,
> PJB> readtables, etc, by merely providing access to the underlying CL API.
> Let me rephrase my question: is the work of reader macros already
> planned for the Emacs core as an incremental feature?  I'm not saying
> your project is not valuable, but it seems a bit far in the future.

AFAIK, not by the emacs maintainers.
But this is free software, you are free to do it yourself!

__Pascal Bourguignon__       
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]