Han-Wen Nienhuys <hanw...@gmail.com> writes:
> On Fri, Aug 19, 2011 at 6:14 AM, Bertrand Bordage
> <bordage.bertr...@gmail.com> wrote:
>>> It is somewhat amusing, by the way, that Lilypond's to_boolean is
>>> required in order to let '() and #f be interpreted in the same manner.
>>> It would seem that Lisp's conflating them into `nil' is not the worst
>>> idea.
>>
>> This also mislead me a long time ago.
>
> It's a historical artefact of old lilypond code that would add objects
> to lists like
>
> set_property("foo", scm_cons(bla, get_property("foo"))
>
> for this to work, the default value of get_property() must be '().
> For booleans, it's a reasonable default to be off, so we have to
> interpret '() as false.
It is not just an old artifact. If one wants to have a sensible
interpretation for setting a nested property when the corresponding
parent property has not been set yet, the parent property has to be
assumed to default to an empty list, or you would not be able to inject
a nested value.
Since properties can be nested arbitrarily deep and we don't have a
corresponding type system reaching below the top level, we can't infer
different defaults for unset nested properties depending on the type
(say #f for booleans, 0 for integers, '() for lists and alists).
My implementation for nested properties deals with conflicts like
(excuse the simplified syntax, I don't want to look this up all the
time)
\override Voice x.y #7 ; x.y is 7
\override Voice.x ##f ; x.y is nonexistent
\override Voice.x.y.z #3 ; x.y is '((z . 3))
by masking the Voice.x incompatible with nested properties and replacing
it with '() effectively while a nested property is visible. So strictly
speaking a default of '() is not necessary since a '() will introduce
itself magically when it is mandatory. But it still makes things less
strange.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
