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

[Ian Hulin <ian@hulin.org.uk>]

Hi Andy,
On 23/11/11 12:27, Andy Wingo wrote:
> Hi Ian,
> 
> Did it really work in v2.0.2, I wonder?
> 
Apparently not, see below for explanation.

> On Tue 22 Nov 2011 00:02, Andy Wingo <wingo@pobox.com> writes:
>> On Mon 21 Nov 2011 18:25, Ian Hulin <ian@hulin.org.uk> writes:
>>> (define-public (void? x) (eq? x (begin))) This works in V1.8,
>>> and apparently used to work in 2.0.2 (no errors),
>> 
>> Interesting.  If it changed incompatibly in 2.0.x, that is a
>> Guile bug. Sorry about that!  We'll fix it.
> 
> I cannot reproduce this issue with 2.0.2.  I suspect that this code
> has been this way since early 1.9 releases, and is a consequence of
> switching to the new syntax expander.
> 
Looks like the change was already in 2.0.2. Another LilyPond developer
(David Kastrup, dak@gnu.org) noticed the advertised API and decided to
use it in part of an ongoing clean-up of the Lily parser.  Meanwhile I
was working on the Guile V2 migration stuff and it broke.
> 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?

Here's why I ask the question.

We were wanting to use it in Scheme statements embedded in LilyPond
source code, especially where these needed to pass values back to the
LilyPond parser.  Using scm_local_eval/local-eval solved problems with
lots of kludgy things involving parser look-aheads and suchlike.

We are using #{ and #} to delimit LilyPond code within a Scheme block
which is itself embedded in LilyPond code.
$ is typically used to mark variables to be accessed by the inner
LilyPond which are declared in the intermediate Scheme block.

This is a quote from David's LilyPond issue tracker commentary for the
work-around:

> Lambdaize $ and # in #{ ... #} to make Guile V2 happy.
> 
> 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 :-{

Cheers,

Ian Hulin