[Top][All Lists]

[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: Thu, 18 Sep 2014 18:44:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Taylan Ulrich Bayirli/Kammer <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>> Brad's status report in contrast was rather to the point, and the web
>> page at <URL:http://www.emacswiki.org/emacs/GuileEmacsTodo> paints a
>> more realistic picture of the current situation as well.
> Do you see any points there that mention incompatibilities between
> Emacs Elisp and Guile Elisp semantics?

My fault: that's actually the Todo list (which is also, uh, diverging
just so slightly from your characterization of the current situation).
The discussion of incompatible semantics and some of the consequences is
at <URL:http://www.emacswiki.org/emacs/GuileEmacs>.

>> At the current point of time, it definitely appears that the
>> marketing department should not fear being overtaken by the
>> engineering department, even though the latter is making solid
>> progress.
> I think the marketing department you have in mind consists of me, who
> is not exactly a Guile developer.  *Hangs head in shame.* Sorry that
> my enthusiasm over Guile-Emacs and a more unified GNU system have
> annoyed you; no reason to accuse Guile of marketing.  Give me all the
> blame.

The problem is not one of enthusiasm, it is one of extemporizing
non-existent information and reinterpreting existing information based
on one's preconceptions.  While how people want things to be is not
completely unrelated to how they will end up, that is much more the case
when they can significantly contribute themselves to the things moving
where they want them to be.

But the main challenges here are of technical nature.  I see a real
problem regarding the #f '() nil situation.  If you take a look, say, at
<URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474>, you'll find
that thinking outside of the Scheme standard box even regarding useful
choices for unspecified behavior is quite unpopular with GUILE.

That's unfortunate for the chances of moving VM behavior and primitives
in manners consciously more friendly towards Lisp semantics.  The
priority of GUILE very much lies with Scheme, with a narrow view towards
filling functionality left open by the Scheme standard with anything
more useful than throwing errors.

David Kastrup

reply via email to

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