On Wed, Sep 12, 2012 at 12:04 PM, David Kastrup <d...@gnu.org> wrote:
> Han-Wen Nienhuys <hanw...@gmail.com> writes:
>
>> On Wed, Sep 12, 2012 at 5:38 AM, David Kastrup <d...@gnu.org> wrote:
>>>
>>> Hi,
>>>
>>> if we write xxx in LilyPond, this is considered to be a string. I want
>>> xxx.yyy.zzz to be a list of strings ("xxx" "yyy" "zzz"). The main
>>> incentive is to be able to have music functions be able to accept both
>>> Stem as well as Staff.TimeSignature as a function argument.
>>
>>> What do you think?
>>
>> doesn't this a different polymorphic annoyances somewhere else, ie.
>>
>> \set "keySignature" = #(..)
>> \set "Staff.keySignature" = #(..)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I don't think the second line was ever permitted.
Right, but
\set Staff.keySignature = #(..)
is, and it will be affected by this change?
>> now, \set gets either a string (keySignature) or list of string. Are
>> music function equipped to deal with this type of polymorphism.
>
> A music function that is only able to deal with a string argument should
> declare its argument type as string? and then it will only ever get a
> string argument.
>
> Music functions will not, in general, be prepared to deal with this sort
> of polymorphism, their argument predicates will have stated this, and
> consequently they will not get to see it.
>
> --
> David Kastrup
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
