Re: Emacs Lisp's future

[Taylan Ulrich Bayirli/Kammer]

David Kastrup <address@hidden> writes:

> Well, as I said: the solution is to declare the algorithm not
> well-written.

Yes, this relatively rare algorithm with a trivially modified
well-written (for Guile) variant is considered not-well-written.

> That is under the premise that Emacs will not be extended in _any_
> language except Elisp.
>
> So that leaves us with one of two conclusions: the advertisement of
> ultimately being able to extend Emacs in multiple languages possibly
> including Scheme, JavaScript and Lua is not going anywhere, or existing
> Elisp code will generally need to be revised in order to work in an
> Emacs running extensions written in other languages.

Note that I myself haven't shown much enthusiasm towards the idea of
using any non-Elisp languages, other than Scheme, and I don't intend to
force Scheme on anyone either.  Nobody does.

Probably, sooner or later the amount of Scheme extensions for Emacs will
grow.  Core Emacs need not support these if they really lead to
problems, but I suspect that will be an exceedingly rare situation.
Emacs users who use others' Scheme extensions might have to deal with
issues in them, but that in turn is a problem with said extensions; an
Elisp extension can also have any number of limitations or warts imposed
on the user, by say using defadvice or failing to follow some
conventions.

> For example, GUILE prouds itself of including an LALR(1) parser
> generator running native Scheme code.  Using it for semantic parsing
> in Emacs will not be feasible if its "Scheme data model" is
> incompatible with the "Elisp data model".

I would expect it to use neither an Elisp nor a Scheme data model, but a
language-independent one served to you in the form of procedures and
macros working on said model.  Taking a quick peek into the source, that
seems to be the case indeed; it uses `define-record-type'.

And if it did use one of the usual Elisp or Scheme types (not a disjoint
type created with `define-record-type'), then they would still be
uniform between the languages as I previously mentioned: an Elisp vector
is a Scheme vector, an Elisp cons is a Scheme pair, etc.  The one and
only wart is removing the "lists all end with the same object" guarantee
as mentioned previously, which will rarely be an issue and has a trivial
fix.

> But the whole point of the exercise was to enable messing with Scheme.

No, it was not.  For Emacsers, the benefits will be, in decreasing order
of "immediate benefit": 1) make Elisp perform better, 2) make Guile
libraries available to Elisp regardless of the language they're
implemented in, 3) make it possible to extend Emacs in Scheme.

Lists are used gratiously in Emacs/Elisp, but not as central types in
specific-purpose Guile libraries, so the nil vs. '() problem mainly hits
point 3, and point 2 to a lesser extent.  (And then the whole "problem"
is barely limited to "lists not guaranteed to terminate in the same (as
in eq) object anymore," on which code relying should be exceedingly
rare.)


To repeat: I see no fundamental issues in basing Emacs/Elisp on Guile.
There are practical issues only, like how to fix string representation.
It would be great if we started working on them. :-)

Taylan