emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Sat, 27 Sep 2014 17:41:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>> Could you move on to some other discussion?
>>> I mean, it's not like this is a problem we need to fix now (if ever).
>> Uh, Pango was an analogy example.  The actual question was whether Emacs
>> can or should delegate its character encoding/decoding processing (not
>> really significantly related to Pango but subject to similar
>> considerations) to GUILE's current mechanisms.  Which seem to be
>> libunistring via libiconv (both GNU libraries it would appear) rather
>> than the ICU mentioned elsewhere.
>
> And, again: it's not like this is a problem we need to fix now (if ever).
>
>> 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.

> AFAIK, Guile-Emacs could perfectly live with having Emacs buffers,
> Emacs strings, and Scheme strings, with no extra cost, except when you
> *want* to convert between them (but as long as you don't run any
> Scheme, you shouldn't need/want to do any such conversion).

GUILE runs on a VM and obviously the native data types known to the VM
will be favored regarding its performance.  It may be that the cost of
processing strings is such that it will dominate the VM code processing,
but since one of the most fundamental data types of both Scheme and Lisp
are interned strings (namely symbols), I'd still expect quite a bit of
unnecessary churn when Emacs strings cannot just use GUILE primitives.
Not least of all maintaining two sets of primitives.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]