[Top][All Lists]

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

bug#10099: Null (begin) blocks - V2.0.3 reports error was OK in V2.0.2

From: Andy Wingo
Subject: bug#10099: Null (begin) blocks - V2.0.3 reports error was OK in V2.0.2
Date: Fri, 25 Nov 2011 10:31:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)


On Fri 25 Nov 2011 00:49, Ian Hulin <address@hidden> writes:

>>> On Mon 21 Nov 2011 18:25, Ian Hulin <address@hidden> writes:
>>>> (define-public (void? x) (eq? x (begin)))

>> That said, this change was not mentioned in NEWS, and the
>> documentation has not been updated, so perhaps we should do
>> something.  I would prefer just to leave it as it is, unless you
>> think that adding a compatibility hack could help you somehow.
>> What do you think, Ian?

> My learned colleague is working round it, but at the very least you
> need to deprecate the support for this and document it as such.
> Or is there a way of keeping scm_local_eval and procedure-environment
> in the API for use only when interpreting?

Is local-eval related to `(begin)' in expression context?  I am a bit
confused here.

>> Unfortunately Guile V2 was not happy about the implementation of 
>> closures around #{ ... #} relying on local-eval and 
>> procedure-environment.  This patch abandons this approach and gets 
>> back to a scheme similar like the old one, namely compiling the 
>> expressions inside of #{ ... #} in advance.
> I'm sure David will let me know if I've over-simplified stuff or got
> things wrong here.
> However, it boils down to lousy timing for LilyPond finding a use for
> this bit of the Guile API, which you guys had decided to withdraw
> because no-one apparently had a use for it :-{

Yeah, I'm sorry for the miscommunication here!  Allow me to explain.

Local-eval is a case of "scripting" being in opposition to
general-purpose programming.  For an simple interpreter (as Guile 1.8
was), it's easy to support, but local-eval makes a compiler's job
harder.  No other Scheme besides SCM had it.  By way of comparison, note
that local-eval in JavaScript is now deprecated and removed entirely in
strict mode.

We wanted to remove it because we wanted to make Guile faster.  We were
able to remove it because it was non-standard and not really used.  It
was a tough decision, but I think the right one in this context.

If you really want something like local-eval, you need to implement your
own `eval'.  That sounds like a PITA, but in reality it will be as fast
as Guile's anyway.  I posted one implementation here:


If you are still curious, search the internet for "fexpr", which is
related to the-environment and local-eval.

Finally, I recommend having another look at the NEWS for Guile 2.0.  It
is a long read, but reading it will probably prevent future



reply via email to

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