Re: Emacs Lisp's future

[Taylan Ulrich Bayirli/Kammer]

David Kastrup <address@hidden> writes:

>> - There's no data type conversion because the same object in memory is
>>   the right type in both languages, including procedures/functions.
>
> Uh, no?  In Lisp, functions are bound to the function cell of a symbol
> which is different from the value cell of a symbol.  In GUILE, nothing
> is bound to a symbol at all.  Modules establish a mapping between
> symbols and values, and functions do not have separate mappings from
> values.

I'm not talking about the language-semantic locations of objects, rather
that for example the same "physical" object in your RAM is at the same
time an Elisp function, and a Scheme procedure.  `functionp' and
`procedure?' both check for the same data type.  (Likewise for other
types.)  No mutation, packing, serialization/deserialization, or any
other things needs to happen to a byte sequence in memory for it to be
usable from either language.

There's probably a simpler way to word what I have in mind and it's
currently escaping me; hope this was clear enough.  :)

>> - There's simply no efficiency issue.  After you import something from
>>   the other language, you just have it; it's indistinguishable from
>>   something you defined in the current language, analogous to how C
>>   implemented functions (subrs) are generally indistinguishable from
>>   Elisp implemented functions; they're now all "libguile procedure
>>   objects."
>
> That's a misrepresentation since an import does not change the state of
> a "libguile procedure object" but rather involves the establishing of
> bindings. [...]

Yes?  I'm just saying that once you put a libguile procedure into the
function slot of an Elisp symbol, it's indistinguishable from an Elisp
function or a subr being in that slot.  There is no overhead while
calling it.  (Elisp functions are compiled into libguile procedures
anyway.)

Actually, this is just a special-case of the first point, regarding the
applicable data type (libguile procedures) being handled in a uniform
way without extra overhead in the case it "comes from the other
language."

>> - The handling of nil vs. Scheme #f and '() is admittedly a wart, but
>>   will probably remain hidden, not causing issues in code you write.
>
> I have problems seeing how it can remain hidden.

Please mention any concrete problematic cases you can think up.

>> - Currently Guile's Elisp implementation is buggy and slow in some
>>   things, but this is unrelated to the interoperation of the
>>   languages.
>
> If it is unrelated to the interoperation of the languages, this would
> imply that GUILE itself is buggy and slow.  You might want to reconsider
> that statement.

It implies Guile's Elisp implementation is buggy and slow.  That is one
unfinished component of Guile.

(The main body of the Elisp implementation that powers Guile-Emacs
resides within Guile itself; I think some key Emacs data types like
buffers and windows are missing if you use it purely from Guile instead
of running Guile-Emacs, but you can use it as a general-purpose
language.)

>> - The biggest long-term issue might be that Elisp macros will not work
>>   in Scheme, and this is relevant only to people who want to use Elisp
>>   APIs in Scheme, not affecting Elisp users.
>
> Huh, this actually is a surprise to me since defmacro works pretty much
> the same in GUILE/Scheme as it would in Elisp.

The problem is that the Elisp macro will just output, say, the symbol
`mapc' into the middle of your Scheme code, where it will not be bound
to the Elisp `mapc' function during subsequent compilation.

Of course, you can otherwise use defmacro in Scheme, though it's highly
discouraged since you have hygienic macros, which guarantee correct
bindings.

>> Yes, a lot of work needs to be done, but I see no fundamental
>> problems.
>
> The main problem I see is that Emacs is a large project regarding its
> code and developer base compared to GUILE and I don't see that GUILE
> can easily scale up.

Matters such as portability and bug-fixing speed which are related to
"manpower" seem open to improvement indeed.  I think that would actually
be a way in which the Guile-Emacs effort would pay back to Guile.

If I'm not mistaken, adopting ECL or some other foreign piece of
software would mean that the upstream developers of it aren't guaranteed
to cooperate, which could be problematic despite the overall maturity of
that piece of software.

Guile on the other hand is GNU software; it's the official GNU extension
language that's being massively revitalized to be worth of its name.
GCC, GDB, and more can be extended in Guile.  It's tied with Guix as
well; the package manager for the upcoming official GNU distribution.
After so many years, things are really getting together in technical
terms in the GNU project, and Guile is what's pulling it all together.
That's why I'm so interested in Guile myself, and think that Emacs just
ought to be a part of this as well.  There is some massive potential
here for the whole of the GNU system getting a lot more attention, and
Emacs itself will benefit from it greatly.

One needs to give it time of course, but I think it's the right
direction, and is what will be most beneficial to Emacs individually as
well in the long term, in case one doesn't care about GNU.

And of course, a large portion of the work is already done here.
Another option would mean starting from scratch.

> The priorities of Elispers and Schemers regarding language features and
> focuses are different, and I don't see overrolling GUILE with the
> requirements, code, interests, and developers of Emacs going smoothly.

The priorities of Elispers seem extremely diverse.  People hacked up web
servers with Elisp and seem motivated to do crazier things.  All the
Guile libraries should be welcome.

>> If some Emacs developers gave Guile-Emacs some love, it might land in
>> a couple years I'd guess, and by then Guile will possibly have some
>> form of just-in-time and/or ahead-of-time native compilation for Elisp
>> as well as Scheme...
>
> Elisp is not really a special case here since stuff like native
> compilation would happen at a decidedly lower layer than the
> Elisp/Scheme distinction.  GUILE has a rather impressive number of
> compiler layers and it is probably only the top layer that would make
> a difference between Elisp and Scheme while something like the two
> bottom layers would distinguish between native compilation and
> bytecode.

Precisely.  I just meant to stress out that whatever nifty low-level
features Guile will improve on, Elisp, Scheme, and other languages on
Guile will benefit from them automatically.

Taylan