Re: Emacs Lisp's future

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>>> The GUILE bridge is there.  Robin Templeton's status of the port is that
>>>> it is mostly complete, with strings/buffers being the most notable part
>>>> obliterating acceptable performance via thick glue layers between Emacs'
>>>> and GUILE's different implementations of similar concepts.
>>> Do you know this to be a fact?
>> <URL:http://www.emacswiki.org/emacs/GuileEmacs#toc9> is about keeping
>> them separate.
>> <URL:http://www.emacswiki.org/emacs/GuileEmacsTodo> lists "Unify Elisp
>> and Scheme strings".
>> I thought I read something from Robin about buffers/strings being a
>> performance issue, but searching on the respective developer lists
>> points rather to dynamic scopes and/or buffer-local variables.
>
> IOW, you do *not* know for a fact that this lack of unification is
> a current source of performance problems.
> Thought so.

Shrug.  I'm currently working on integrating GUILE 2.0 into LilyPond,
and GUILE 2.0 has Unicode strings which are either UCS-8 or UCS-32 in
the strings and UTF-8 in string ports (which are sort of like Emacs
buffers on steroid withdrawal).  So at the current point of time, Emacs
and GUILE strings would need reencoding/decoding at every call gate
anyway as long as string access is not abstracted well enough in the
Emacs code base that the different internal coding would not require
code changes.  The VM costs would be negligible in comparison with that.

I don't think that having to retain a separate implementation of strings
in Emacs makes much sense in the course of integrating GUILE and Emacs.
"reencode at every call gate" is not feasible for tight interaction, and
tight interaction is desirable for an extension language after all.

In our case, LilyPond has a lot of head-scratching to do in order to
arrive at a state where GUILE and C++ strings can be passed through the
system reasonably efficient since LilyPond _is_ designed to tightly
interact with GUILE.  The basic expediency mechanism is to tell GUILE
"this is all latin-1" which it will then keep in UCS-8.  Whenever there
is an interest in Unicode string processing, we need to reencode.
LilyPond itself is actually talking UTF-8 to its users.  This kind of
"we work with UTF-8, but consider it to be UCS-8 instead since we cannot
or do not want to afford the price you demand for treating it as UTF-8"
is not really a satisfactory solution, and I expect this to become an
issue in other applications.

So I pretty much expect that we'll see GUILE migrating to an UTF-8-based
string representation eventually, with all the head-scratching regarding
indexing and rewriting strings (aset anybody?) that Emacs has seen.
In case that happens, matching Emacs strings would make a lot of sense.

Admittedly, that is more a problem of GUILE than Emacs.

-- 
David Kastrup