David Kastrup <[email protected]> writes: > David Kastrup <[email protected]> writes: > >> Thomas Morley <[email protected]> writes: >> >>> It was an observation, not a proposal. >>> Speaking only for myself, I can perfectly life without the >>> comma-syntax in definitions and their calls. >> >> It feels weird in definitions. Don't remember whether there was some >> original rationale for it (like consistency, possibly connected with >> convenience in reusing parser rules). > > Ah, the way "property_path" is defined via "symbol_list_rev" and symbol > lists also in function arguments are defined as being able to contain > either '.' or ',' means that even if one forces the first separator to > be a '.', the following separators are hard to avoid being also > permissable as ','. > > So navigating around that inconsistency is pretty ugly: it will > sometimes work and sometimes not. But maybe definition and call of > those kind of separated variables should at least be identical and > consequently require a first dot even if for technical reasons the > following separators may happen to admit commata.
I've taken a look, and the original admission of ',' to assignments was as part of commit 2a9bcb103d9fbe58c998c8c81761985da8bded2a Author: David Kastrup <[email protected]> Date: Tue Mar 8 11:47:28 2016 +0100 Issue 4790: 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''' } so it's been a "consistency" thing as of the first commit. The bug tracker does not contain any discussion about that bit, so it's likely that any chosen tradeoffs were the result of "internal dialog" rather than a discussion with more than one participant. I sort of lean towards not allowing mixed lists at all but that would lead to a lot of duplicated code in the grammar (once for '.' and once for ',') with the end result that the parser pretends not to be able to guess what it is supposed to do. And if we add an error path where it does the right thing after all, things get even more complex. Also, parts.1,1 = ... will do something imaginably useful while parts.1.1 = ... will bomb out horribly since 1.1 is a floating point number. And parts.1. 1 = ... does not look quite the same. Still, it's not possible to write 1,1 = ... and the incentive for allowing parts,1,1 = ... is not all that high. So I somewhat lean towards at least enforcing the first dot in assignments/recalls. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
