[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of null (begin) blocks is deprecated in Guile stable V2.0, use u
Re: Use of null (begin) blocks is deprecated in Guile stable V2.0, use unspecified? and/or *unspecified* instead.
Tue, 22 Nov 2011 14:53:24 +0100
Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)
David Kastrup <address@hidden> writes:
> Ian Hulin <address@hidden> writes:
>> 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:
> I am responsible for most of those, and will fix them. No issue
> required here.
> For my defense, neither *unspecified* nor unspecified? are documented in
> the Guile-1.8 manual though working at the prompt. So while the 1.8
> branch is still maintained, you should report this as a documentation
> bug. And after all, it _does_ affect upwards-compatibility.
As a meta-issue: I had defined void? as something quite equivalent to
Guile's unspecified?. I am retaining this definition since Guile's
"unspecified?", meaning eq? to the specific value *unspecified*, is a
misleading name. And the context we use it for, namely checking whether
an expression does not return any value, is quite specific.
define-void-function defines a function returning no value, and I would
not want to call this define-unspecified-function instead.
I consider the idea of making *unspecified* equivalent to (values)
eminently sensible. I don't understand why this would need to be
different from a hardwired constant SCM_UNSPECIFIED internally, quite
similar to how '() can be equivalent to a hardwired constant SCM_EOL.