#4798 Admit lists starting with UNSIGNED as music function arguments

[David Kastrup]

Admit lists starting with UNSIGNED as music function arguments

This builds upon a variety of other commits:

Use key-list? for several music command predicates

This is sort of arbitrary currently but matches the kind of syntax
accepted by \override/\revert due to their definition in the parser.

Parser work for key lists including numbers

This admits key lists containing non-negative numbers into various
syntactic constructs previously using symbol lists.

Define key?, key-list?, key-list-or-music?, key-list-or-symbol?

A key (previously a symbol) can be either a non-negative
integer (obeying the predicate index?) or a symbol. When used for
overrides/reverts, the first elements of a path may not actually be
numbers but they are flagged as an error by other means: since a full
override path can be the concatenation of several key lists, the leading
elements are not treated differently by the list predicates.

Strictly speaking this should not be the case for key-list-or-music? or
key-list-or-symbol? predicates, but making them behave differently seems
unwarranted. Arguably key-list-or-symbol? should possibly be
key-list-or-key? instead.

Prepare override/revert to deal with numeric subkeys

Those are fairly cosmetic changes (partly comments) to prepare for the
possibility of using override/revert with numeric subkeys while
retaining the necessity of using a symbol as the main property in a
Context.Grob.property.subproperties... n-tuple since the organization of
an "nalist" (an alist stack containing reversible subproperty overrides)
relies on a few special key values: currently pairs and booleans are
specially interpreted while the current implementation requires an
eq?-comparable first index for efficiency reasons.

Make alist routines use equal? key comparisons

This affects evict_from_alist and nested_property_alist

Optimize assoc_tail for various key types

Add assv_tail function

http://codereview.appspot.com/291190043

[Anonymous]

Passes make, make check and a full make doc.

[Anonymous]

Patch on countdown for March 19th.

[Anonymous]

Patch counted down - please push.

[David Kastrup]

Pushed to staging as
commit 34917fefd1167f963c44fbcf47ab7f4184fc4cdc
Author: David Kastrup dak@gnu.org
Date: Thu Mar 10 18:23:48 2016 +0100

Issue 4798/6: Admit lists starting with UNSIGNED as music function arguments

commit 0453c1df927617386bfd63f22965a72f43b192a8
Author: David Kastrup dak@gnu.org
Date: Sun Mar 13 20:49:49 2016 +0100

Issue 4798/5: Use key-list? for several music command predicates

This is sort of arbitrary currently but matches the kind of syntax
accepted by \override/\revert due to their definition in the parser.

commit 77cf1054ff5aeb20978a1586a44f5b95fb365585
Author: David Kastrup dak@gnu.org
Date: Wed Feb 3 19:38:29 2016 +0100

Issue 4798/4: Parser work for key lists including numbers

This admits key lists containing non-negative numbers into various
syntactic constructs previously using symbol lists.

commit a2f0f4f890e4dbc3062a86f4d6e1e9bf65dcac98
Author: David Kastrup dak@gnu.org
Date: Fri Feb 12 18:02:10 2016 +0100

Issue 4798/3: Define key?, key-list?, key-list-or-music?, key-list-or-symbol?

A key (previously a symbol) can be either a non-negative
integer (obeying the predicate index?) or a symbol.  When used for
overrides/reverts, the first elements of a path may not actually be
numbers but they are flagged as an error by other means: since a full
override path can be the concatenation of several key lists, the leading
elements are not treated differently by the list predicates.

Strictly speaking this should not be the case for key-list-or-music? or
key-list-or-symbol? predicates, but making them behave differently seems
unwarranted.  Arguably key-list-or-symbol? should possibly be
key-list-or-key? instead.

commit 17440eeed8ec9fc6714d5b418387fb162d232003
Author: David Kastrup dak@gnu.org
Date: Mon Mar 7 12:13:06 2016 +0100

Issue 4798/2: Prepare override/revert to deal with numeric subkeys

Those are fairly cosmetic changes (partly comments) to prepare for the
possibility of using override/revert with numeric subkeys while
retaining the necessity of using a symbol as the main property in a
Context.Grob.property.subproperties... n-tuple since the organization of
an "nalist" (an alist stack containing reversible subproperty overrides)
relies on a few special key values: currently pairs and booleans are
specially interpreted while the current implementation requires an
eq?-comparable first index for efficiency reasons.

commit ec91a9a4bdd186d7af88381a10a2923ac949d33c
Author: David Kastrup dak@gnu.org
Date: Fri Mar 4 12:36:13 2016 +0100

Issue 4798/1: Make alist routines use equal? key comparisons

This affects evict_from_alist and nested_property_alist

commit edb75f07f428d68eb2f694445eef60606b7cf64a
Author: David Kastrup dak@gnu.org
Date: Mon Mar 7 12:03:31 2016 +0100

Optimize assoc_tail for various key types

commit 831d149c5240b038667d4973660a63a474605aae
Author: David Kastrup dak@gnu.org
Date: Thu Mar 3 17:38:40 2016 +0100

Add assv_tail function