Re: Emacs rewrite in a maintainable language

[Taylan Ulrich Bayırlı/Kammer]

David Kastrup <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> I haven't followed the whole discussion but I'd like to remind that
>> GuileEmacs already runs currently, and from what I know none of the
>> problems it faces are related to string handling.  It just lets Elisp
>> strings be a separate data type.
>>
>> I guess the discussion was about rewriting bigger parts of Emacs in
>> Guile-Scheme, which might be one possible way to go forward but not
>> necessary.
>>
>> Most of the benefits in e.g. http://www.emacswiki.org/emacs/GuileEmacs
>> apply without having to solve the string problem.  Specifically, from
>> the overview section, the first two points and half of the third should
>> apply I think.
>
> The first two points concern efficiency.  Emacs is _all_ about working
> with strings, and the last report of GuileEmacs stated something like
> GuileEmacs being about an order of magnitude slower specifically because
> of having to special-case Emacs strings and buffers.
>
> Emacs is first and foremost an editor.  Substantial increases of
> efficiency in most general programming areas at the cost of abysmal
> performance in text processing are not going to make the race.

I think you're misremembering.

It might be that you have strings in mind because not being able to
serialize Elisp strings means having to compile everything at each
startup, making startup slow.  And maybe you have buffers in mind
because buffer-local variables and other weird binding semantics of
Elisp need special handling.

Neither is related to the run-time performance of string handling, of
course.

Hmm, what would be a good benchmark of Elisp string handling that won't
be affected by the performance of dynamic binding of variables or other
such things?  I'd like to just test it instead of hypothesize.

Taylan