Let ',' separate symbol lists like '.' does

Let ',' separate symbol lists like '.' does

While the dotted list syntax is natural for hierarchical paths like for
\override and \revert, it is less natural in cases that may now be written as

    \keepWithTag violin,flute,oboe { c''' }

[lemzwerg, 2016-03-08 16:45:10]

Nice idea, thank!  LGTM.

[lemzwerg, 2016-03-08 16:45:20]

Nice idea, thanks!  LGTM.

[simon.albrecht, 2016-03-08 17:52:09]

I also like the idea.
Should this get a regtest?

Best, Simon

[dak, 2016-03-08 18:17:58]

On 2016/03/08 17:52:09, simon.albrecht wrote:
> I also like the idea.
> Should this get a regtest?
> 
> Best, Simon

It certainly should get both regtest and documentation and Changes entry. 
However, it will presumably also fit together with pending documentation for
tags.  And I'm also working on other related changes so I'm somewhat unsure
about the total scope.

So if someone wants to take this from here (or propose tests/docs to include),
he's certainly welcome to do so.

[dan_faithful.be, 2016-03-08 22:42:55]

On Mar 8, 2016, at 13:17 , dak@gnu.org wrote:
> 
> Description:
> Let ',' separate symbol lists like '.' does
> 
> While the dotted list syntax is natural for hierarchical paths like for
> \override and \revert, it is less natural in cases that may now be
> written as
> 
>    \keepWithTag violin,flute,oboe { c''’ }
> 

Based on my hasty scan of this change, it looks like you’ve made comma and dot
interchangeable.  So it would be valid to write

   \keepWithTag violin.flute,oboe …

If that’s the case, it’s weird.

If the problem is that ‘.’ implies hierarchy, then in addition to making it
possible to define a comma-separated symbol list, wouldn’t it be helpful to
require a comma-separated list for non-hierarchical arguments and a
dot-separated list for hierarchical arguments?

And would we ever want to express a non-hierarchical list of hierarchical
lists?
— 
Dan

[dak, 2016-03-08 22:55:51]

On 2016/03/08 22:42:55, dan_faithful.be wrote:
> On Mar 8, 2016, at 13:17 , mailto:dak@gnu.org wrote:
> > 
> > Description:
> > Let ',' separate symbol lists like '.' does
> > 
> > While the dotted list syntax is natural for hierarchical paths like for
> > \override and \revert, it is less natural in cases that may now be
> > written as
> > 
> >    \keepWithTag violin,flute,oboe { c''’ }
> > 
> 
> Based on my hasty scan of this change, it looks like you’ve made comma and dot
> interchangeable.

Correct.

> So it would be valid to write
> 
>    \keepWithTag violin.flute,oboe …
> 
> If that’s the case, it’s weird.

Then don't write it.
 
> If the problem is that ‘.’ implies hierarchy, then in addition to making it
> possible to define a comma-separated symbol list, wouldn’t it be helpful to
> require a comma-separated list for non-hierarchical arguments and a
> dot-separated list for hierarchical arguments?

The resulting Scheme data is the same so you cannot write a music function
predicate distinguishing the two.

> And would we ever want to express a non-hierarchical list of hierarchical
> lists?

Possibly, but then reverting to Scheme and its properly parenthesized
expressions is saner.

My actual secret motivation arose in connection with subproperties that can be
numerical.  So numbers (at least positive integers) can become members of lists,
and entering something like 4.5 is a no-go.  4,5 is fine, in comparison.  That
allows for

    \time 3,2 5/4

which seems nice but also the only function right now taking a number-list?
argument.  So that's not much of a justification.

However, I consider \keepWithTag violin.flute.oboe weird as well, so having a
differently flavored syntactic sugar for it just seems more appropriate.

It's conceivable to _not_ allow , for overrides/reverts only.  But then having
\override forbid , while \propertyOverride allows it: how would you document
that?

[thomasmorley651, 2016-03-08 23:28:37]

On 2016/03/08 22:55:51, dak wrote:
> On 2016/03/08 22:42:55, dan_faithful.be wrote:
> > On Mar 8, 2016, at 13:17 , mailto:dak@gnu.org wrote:
> > > 
> > > Description:
> > > Let ',' separate symbol lists like '.' does
> > > 
> > > While the dotted list syntax is natural for hierarchical paths like for
> > > \override and \revert, it is less natural in cases that may now be
> > > written as
> > > 
> > >    \keepWithTag violin,flute,oboe { c''’ }
> > > 
> > 
> > Based on my hasty scan of this change, it looks like you’ve made comma and
dot
> > interchangeable.
> 
> Correct.
> 
> > So it would be valid to write
> > 
> >    \keepWithTag violin.flute,oboe …
> > 
> > If that’s the case, it’s weird.
> 
> Then don't write it.

I firstly had some concerns about problems arising from people being tempted to
write additional spaces after the comma, though with:

blub = #(define-void-function (arg)(list?) (write (map symbol->string arg)))
\blub foo . bar . buzz

I noticed no problem. Hence I expect no problems with commas as well.

[...]

> 
> My actual secret motivation arose in connection with subproperties that can be
> numerical.  So numbers (at least positive integers) can become members of
lists,
> and entering something like 4.5 is a no-go.  4,5 is fine, in comparison.  That
> allows for
> 
>     \time 3,2 5/4
> 
> which seems nice but also the only function right now taking a number-list?
> argument.  So that's not much of a justification.
> 

A quick scan through my private functions using number-list? offered some hits,
where it could be a nice input-possibility.

Although I can't review parse-code, I vote for it. 
Really nice, especially for number-lists.

[dan_faithful.be, 2016-03-09 02:11:57]

On Mar 8, 2016, at 17:55 , dak@gnu.org wrote:
> 
>> So it would be valid to write
> 
>>    \keepWithTag violin.flute,oboe …
> 
>> If that’s the case, it’s weird.
> 
> Then don't write it.

OK. No further objections.
— 
Dan

[dak, 2016-03-09 09:10:42]

On 2016/03/08 23:28:37, thomasmorley651 wrote:

> 
> I firstly had some concerns about problems arising from people being tempted
to
> write additional spaces after the comma, though with:
> 
> blub = #(define-void-function (arg)(list?) (write (map symbol->string arg)))
> \blub foo . bar . buzz
> 
> I noticed no problem. Hence I expect no problems with commas as well.

Unfortunately, there is in lyricsmode.  As opposed to non-quoted stuff starting
with a '.', ',' is not special.  I considered changing that, but while that
would have allowed \blub foo , bar , buzz or even \blub foo ,bar ,buzz it would
not have helped with the much more important \blub foo, bar, buzz so it is sort
of pointless.  And we definitely do not want to split foo, into two tokens in
lyricsmode.  So in lyricsmode, we'd more or less be stuck with foo,bar,buzz .

So all-in-all, it is a bit of a so-so improvement.  Its main motivation for me
really is not to have to use '.' for grouping numbers since it is already used
inside of numbers.  And it does make tag lists look nicer.  And lyricsmode is
not really overcrowded with music functions so this will likely not become an
issue all too often.

[thomasmorley651, 2016-03-09 22:50:56]

On 2016/03/09 09:10:42, dak wrote:
> On 2016/03/08 23:28:37, thomasmorley651 wrote:
> 
> > 
> > I firstly had some concerns about problems arising from people being tempted
> to
> > write additional spaces after the comma, though with:
> > 
> > blub = #(define-void-function (arg)(list?) (write (map symbol->string arg)))
> > \blub foo . bar . buzz
> > 
> > I noticed no problem. Hence I expect no problems with commas as well.
> 
> Unfortunately, there is in lyricsmode.  As opposed to non-quoted stuff
starting
> with a '.', ',' is not special.  I considered changing that, but while that
> would have allowed \blub foo , bar , buzz or even \blub foo ,bar ,buzz it
would
> not have helped with the much more important \blub foo, bar, buzz so it is
sort
> of pointless.  And we definitely do not want to split foo, into two tokens in
> lyricsmode.  So in lyricsmode, we'd more or less be stuck with foo,bar,buzz .

ok

> So all-in-all, it is a bit of a so-so improvement.  Its main motivation for me
> really is not to have to use '.' for grouping numbers since it is already used
> inside of numbers.  And it does make tag lists look nicer.  And lyricsmode is
> not really overcrowded with music functions so this will likely not become an
> issue all too often.

agreed