David Kastrup <d...@gnu.org> writes: > Ian Hulin <i...@hulin.org.uk> 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: >> lily/mensural-ligature.cc >> lily/system.cc >> scm/c++.scm >> scm/define-event-classes.scm >> scm/music-functions.scm > > 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. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
