Re: Emacs Lisp's future

[David Kastrup]

Taylan Ulrich Bayirli/Kammer <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>> Interoperability between languages is *hard*.  Doing it so the result
>> is lightweight and elegant (and moderately efficient) is rarely
>> possible.
>
> Well, the Elisp and Scheme integration is pretty great.
>
> Maybe you know all of the following, but for those who didn't:
>
> - 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.

> - A convenient `import-guile-module' syntax in Elisp could be
>   implemented relatively trivially, which would walk a module and put
>   procedure bindings into the function namespace and other bindings into
>   the variable namespace of Elisp (both with a user-provided prefix).
>   So you can have the API of any Guile module in Elisp as if it were
>   just an Elisp library.

See?

> - 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.  The data structures are also not compatible: Lisp lists end
with a value that serves as a _false_ boolean, Scheme lists end with a
value that serves as a _true_ boolean.

> And here some issues, maybe-issues, and non-issues we have:

[...]

> - 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.

> - 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.

> - Conceptually, Scheme macros can work in Elisp.  Might need some work
>   to actually make this work, or it might be trivial; I don't know.
>
> - 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.

> 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.

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.

> 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.

-- 
David Kastrup