Re: Emacs Lisp's future

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Bug report about basic list functionality not working for lists of more
>> than 10009 members:
>>
>> <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17485>
>
> One of our procedures has a scalability problem.  Summarizing this as
> "basic list functionality not working for lists of more than 10009
> members" is a gross misrepresentation.

It's "drop-right" in srfi-1, the basic list processing library. 10009 is
a typo, it's actually somewhere between 1000 and 10000 that GUILE bombs
out.  drop-right is basic enough that it is used in the implementation
of reduce-right, propagating the scalability problem.  I don't see it as
a gross misrepresentation, but haggling about that would be missing the
point anyway.

> I responded within a day or so, and we had a conversation over the next
> few days, but quickly ran into the problem that you wanted to change one
> of our other API procedures in a non-standard way

The "non-standard way" being the exact behavior of the Scheme reference
implementation for srfi-1.

> that conflicts with our existing behavior, and you simply wouldn't
> take "no" for an answer.

I gave up on this problem after pointing out that I saw no sensible
solution within the restrictions you wanted to see implemented and
I pointed that out.

At any rate, all this is missing the point.  The point was that GUILE is
not a vibrant project at a scale that can comfortably absorb the impact
of becoming Emacs' main Lisp engine.

Becoming Emacs' main Lisp engine will require timely answers to
limitations in the VM, compilers, library routines, and Scheme standard
interpretation that turn out to affect Emacs operations and Lisp
implementations.  In particular, it will not be an option to flag errors
for every operation that has no well-defined semantics in Scheme when
the corresponding operation in Common Lisp or Elisp happens to be
well-defined and needed.

And parting ways again in case the cooperation turns out bad is entirely
different from parting ways with Bazaar, since we are talking about
replacing Emacs' internals here rather than an external tool.

So the situation with GUILE-Emacs more or less can be characterized as:
you can check it in any time you want but you can never leave it.

>> <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13101> is an
>> example for the inability to compile large expressions on Guile-2.0.
>> The basic resume for this bug is "large expressions like that will
>> only work with Guile-2.2+"
>
> Is it really a show-stopper that Guile 2.0 has limitations in the
> sizes of some expression types?

Semantic compiles grammars into code.  "some expression types" in that
bug report is a large "cond" statement, exactly the kind of thing a
typical action-annotated grammar will be compiled into by a parser
generator.  GUILE compiles a cond statement into nested if statements.
The VM does not offer any other renditions of conditionals, so _every_
way of expressing this function in terms of an open-coded block of code
rather than, say, tables containing closures, will fail compilation.

Yes, this can turn into sort of a scalability problem in my book.  And
Emacs is big.

> Even C has similar limitations, and yet somehow it seems to be
> successful.

C restricts the number of cases in a switch statement (which would be
the rough equivalent here)?  That's news to me.

-- 
David Kastrup