Use of null (begin) blocks is deprecated in Guile stable V2.0, use unspecified? and/or *unspecified* instead.

[Ian Hulin]

This is forwarded from the Guile bug list.  Bug-squad please create a
LilyPond issue for this - we need to change our code:

Files affected appear (according to git grep) to be:
lily/mensural-ligature.cc
lily/system.cc
scm/c++.scm
scm/define-event-classes.scm
scm/music-functions.scm

Cheers,
Ian Hulin

-------- Original Message --------
Subject: Re: Null (begin) blocks - V2.0.3 reports error was OK in V2.0.2
Date: Tue, 22 Nov 2011 00:02:35 +0100
From: Andy Wingo <address@hidden>
To: Ian Hulin <address@hidden>
CC: bug-guile <address@hidden>, Ludovic Courtès <address@hidden>,
guile-user <address@hidden>, Han-Wen Nienhuys <address@hidden>
Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.bugs
References: <address@hidden>

Hi Ian!

In the future, please include address@hidden in bug reports.  It
creates a ticket so we don't forget.  The system changed a bit recently,
but we hope that it works OK for you.  It's certainly working better for
us.

Anyway:

On Mon 21 Nov 2011 18:25, Ian Hulin <address@hidden> writes:

> (define-public (void? x) (eq? x (begin)))

This is really not right, if I understand what you are checking for.
These will work:

  (define-public (void? x) (unspecified? x))
  (define-public (void? x) (eq? x *unspecified*))
  (define-public (void? x) (eqv? x *unspecified*))
  (define-public (void? x) (eq? x (if #f #f))

> This works in V1.8, and apparently used to work in 2.0.2 (no
> errors), but in 2.0.3 (begin) is OK at the repl, (with readline
> enabled and activated), but in any sort of procedure using it
> causes a diagnostic, reporting either at the repl or in .scm
> files,
> 
> xxx: source expression failed to match any pattern in form
> (begin).

Interesting.  If it changed incompatibly in 2.0.x, that is a Guile bug.
Sorry about that!  We'll fix it.

That said, though, you have a few misunderstandings here.

> 6.13.1 Evaluating a series of expressions <snip> — syntax: begin
> expr1 expr2 ...

First of all, this documentation is not quite correct.  Since R5RS there
have been *two* kinds of begins: one that splices and one that
sequences.

I know that sounds complicated, but let me explain.  It's not widely
known, and many Schemers consider it to be something of a bug that they
both share the same name.

Scheme has two contexts: definition context and expression context.
Like, you can only put nested definitions at the top of a function,
before the expressions, and a function has to end with an expression.

`Begin' in definition context "splices" its subforms into its containing
form.  This is to allow macros to expand to multiple definitions.
In definition context, `begin' is just syntactic.

`Begin' in expression context evaluates its subforms in order.  It is
used for its semantic property of sequencing effects.

It is possible for a `begin' in definition context to have no subforms.
But in expression context, you need an expression, and if there are no
expressions to evaluate, the result is a syntactic error.  That is what
you are running into.

> Guile also allows the expression (begin), a begin with no 
> sub-expressions. Such an expression returns the `unspecified'
> value.

So, I guess we have to fix this in 2.0.x.  This behavior will probably
not be available in 2.2, however, so it's best to change your code now,
at the same time that we fix Guile to have the old behavior (and fix the
docs).

Finally, we are considering having expressions that produce unspecified
values actually produce 0 values.  So, for example, (if #f #f) would be
the same as (values).  Of course it's not something we can do in 2.0,
and we would try to publicise it well, but do keep it in mind.

Regards,

Andy
-- 
http://wingolog.org/