Re: Problem compiling: music-functions-init.ly

[David Kastrup]

Urs Liska <address@hidden> writes:

> I just checked a few things:
>
> 1) The order of the cars is irrelevant 2) The cars must be exact
> integers 3) If the cdr of a scale step is 0 the pair can be left out.
>
> 4) If a car is present more than once then a sharp will dominate
> regardless of the order in the list.
>
> 5) If a car is < 0 or > 6 a warning "warning: Incomplete
> keyAlterationOrder for key signature" is produced but the
> corresponding alteration is set => (9 . 1/2) will produce a sharp on
> the third step 6) I don't know how one can produce scales with more or
> less than 7 steps (but I hope this is possible with LilyPond), but I
> assume that in case the behaviour is the same except that the range
> 0..6 will be different.
>
> 7) The cdr of a step may be any number for which there's a key in
> KeySignature.glyph-name-alist. Otherwise a warning "warning: No glyph
> found for alteration: 1/8" is issued

[...]

> I think based on my above observations it would be possible to
> determine a better predicate than "unlikely to trigger with accidental
> input".
>
> A key signature mode must
>
> * be a list of number pairs * each car must be an exact integer >= 0 *
> each car must occur only once
>
> We can ignore the matching of the cdr I think because the warning is
> appropriate and points exactly to the problem.
>
> I'm not sure about the upper range. It's acceptable to ignore the
> warning but it feels going in the wrong direction (it's not that the
> definition is "incomplete", it's rather an invalid step). If it is
> possible to define scales with alternative number of steps it may be
> necessary to check that length.

I think you are overthinking this.  The purpose of predicates in
LilyPond music functions et al is to sort input according to its
intended meaning, not to establish its validity, particularly not for
complex data types.  So we have a lot of "number?" predicates where only
exact numbers of a certain type would actually be acceptable.

If you hand-construct something in Scheme that isn't valid but passes
the syntactic check, then it will likely blow up somewhere in LilyPond's
bowels.  If you hand-constructed something in Scheme, you are expected
to be able to deal with that.  We cannot really move all of the
intelligence into the parser.

So the predicate list? was good enough here (barely, though) until
unrelated changes made it possible to turn the input

    major

into a list.  Which the parser then dutifully did here.

-- 
David Kastrup