Re: Emacs Lisp's future

[Taylan Ulrich Bayirli/Kammer]

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.

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

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

- I can trivially import the Elisp function and variable namespaces in
  Scheme code with a pair of different prefixes.  I then have the whole
  Elisp API in my Scheme code, sans Elisp macros.

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

- Currently strings are an exception to the first point.  I hope that
  won't be too difficult to fix.

- The handling of nil vs. Scheme #f and '() is admittedly a wart, but
  will probably remain hidden, not causing issues in code you write.

- Currently Guile's Elisp implementation is buggy and slow in some
  things, but this is unrelated to the interoperation of the languages.

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

If Guile-Emacs succeeds, you really will be able to

(import-guile-module (gl) gl-)  ;`gl-' is the prefix

and write OpenGL code in Elisp.

You can probably already do that in the current state of Guile-Emacs,
except that `import-guile-module' needs to be implemented; for now you
can individually do e.g.:

(defalias 'gl-set-draw-buffer (guile-ref (gl) set-gl-draw-buffer))


I think this is worth pursuing.  It opens Emacs to a whole new world.
Yes, a lot of work needs to be done, but I see no fundamental problems.

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


Taylan