Re: Emacs Lisp's future

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> Is it really a show-stopper that Guile 2.0 has limitations in the
>>> sizes of some expression types?
> [...]
>> Yes, this can turn into sort of a scalability problem in my book.  And
>> Emacs is big.
>
> The problem is fixed on the master branch, which is the only branch
> that supports guile-emacs anyway.

Ok, so guile-emacs will not work with the "stable" branch.  If I take a
look at the "master" branch which is the only one supporting
guile-emacs, I see things like

    commit 2c02a21023c946a3d31c43417d440d6babbf2622
    Author: Andy Wingo <address@hidden>
    Date:   Sun Jun 29 14:29:20 2014 +0200

        Remove namesets.

        This was a failed experiment.  It had good space complexity but terrible
        time complexity.

        * module/Makefile.am: Update.
        * module/language/cps/nameset.scm: Remove.

[...]

    commit ec412d75627aeffbd816ac351eabcd1b533540c6
    Author: Andy Wingo <address@hidden>
    Date:   Thu Jun 19 08:49:05 2014 +0200

        Rewrite type inference pass to use namesets

        * module/Makefile.am: Build types.scm early, but don't block the rest of
          the build on it.

        * module/language/cps/types.scm: Rewrite to use namesets.

        * module/language/cps/dce.scm:
        * module/language/cps/type-fold.scm: Adapt to interface changes.

    commit 97ed2e77ab22e1695c5c4df6f5f6cfd98b90636f
    Author: Andy Wingo <address@hidden>
    Date:   Sun Jun 8 18:50:07 2014 +0200

        New module: (language cps nameset)

        * module/language/cps/nameset.scm: New file.
        * module/Makefile.am: Add new file.


which make clear that the master branch in GUILE is _highly_
experimental.  If you take a look at the GUILE developer list archives
at
<URL:http://lists.gnu.org/archive/html/guile-devel/2014-09/threads.html>
and previous months, you'll find that Andy Wingo does not participate in
any discussions there.

So basically GUILE master is his private playground which he works on in
bursts of activity without publicly visible communication.

I don't see that basing Emacs on that kind of setup is remotely
realistic without serious reorganization of how GUILE organizes and
views its development processes.  Emacs is a remarkably _stable_ and
reliable piece of software considering its size and age.

> So, why are limitations in Guile 2.0 relevant for guile-emacs?
>
> Incidentally, the 'drop-right' scalability problem you complain above
> above is also fixed on the master branch, and plenty of others.  The
> reason is that our stacks are now automatically expanded as needed,
> limited only by the available memory, so we can now write recursive
> procedures in a natural way without ugly hacks to make them scalable.

Personally, I don't consider automatically expanding stack size a
"solution" to a routine unnecessarily shoving all elements of an
arbitrarily large data structure interspersed with return addresses onto
a VM stack before processing it.  But then tastes may differ.  I started
programming at a time when I paid the equivalent of €400 for 64kB of
RAM, so throwing RAM at a problem was expensive enough to be habit
forming.

> See http://wingolog.org/archives/2014/03/17/stack-overflow for more.

At any rate, this is again a distraction.  The topic is how suitable
GUILE is for turning into the Lisp foundation of Emacs.

And I think that apart from reestablishing that I am a dishonest
manipulative asshole who does not know what he is talking about, we got
some insights into the current state of GUILE development that may help
in refining goals and obstacles in the process of making GUILE the Lisp
implementation underlying Emacs.

-- 
David Kastrup