guile-devel
[Top][All Lists]
Advanced

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

Re: Anything better for delayed lexical evaluation than (lambda () ...)?


From: David Kastrup
Subject: Re: Anything better for delayed lexical evaluation than (lambda () ...)?
Date: Wed, 14 Dec 2011 15:27:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> skribis:
>
>> But, in the event that David wants to continue with his current
>> strategy, there are other things that can be done.  David, did you know
>> that Guile's evaluator is implemented in Scheme?  That means that if you
>> want an evaluator with different semantics -- for example, something
>> closer to Kernel[0], as David appears to want -- then you can implement
>> an evaluator that provides for fexprs and the like, and it will run
>> about as well as Guile's evaluator.
>
> Indeed.  FWIW, Skribilo [0] has its own input language, which is similar
> to but different from Scheme, so it has its own reader and its own
> evaluator, the latter being mostly a wrapper around ‘eval’.  This
> strategy has worked well, and portably between 1.8 and 2.0.

There is a saying "a real FORTRAN programmer can write FORTRAN programs
in any language".  But one of the principal attractions of implementing
a Scheme-like language in Scheme is that one can _turn_ Scheme into
one's target language instead of merely using it as an implementation
language.

In contrast, you usually don't implement a C-like language by
manipulating your C compiler (some template libraries may come close),
and you usually do not even want to bootstrap a FORTRAN compiler on
FORTRAN.

And in particular for something like Emacs Lisp, it would be quite more
interesting to turn GUILE into Emacs Lisp rather than implement Elisp on
top of it.  I have not actually looked at the respective code bases.
That's just a gut feeling of what would be cool, and also provide a user
experience that is not purely either/or regarding what layer one is
working in.

-- 
David Kastrup




reply via email to

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