Janek Warchoł <janek.lilyp...@gmail.com> writes: > Hi, > > from what i see there are two concurrent proposals about introducing > digits in variable names: > http://codereview.appspot.com/6778055/ by David > http://codereview.appspot.com/6493072/ by Keith > > i'm a bit confused - i'm not sure wheter these patches are mutually > exclusive or not. > Anyway, here's my general opinion (it's more about the UI than actual > code): > - having to enclose identifiers in quotation marks feels more natural > to me than using some special sign between letters and digits (i.e. i > like \"violin1" better than \violin+1 (or \violin.1)), > - "parser simplicity" is most important to me. In other words, i vote > for a solution that fits smoothly with other syntax constructs, > introduces as few exceptions as possible, doesn't produce > surprising/confusing results, etc. > > Of course it would be great if > > On Tue, Oct 30, 2012 at 7:05 AM, <d...@gnu.org> wrote: >> [...] \violin1, \violin 1, \violin $(1+1) [would] all work, [...] > > however, my impression from previous discussions was that doing so > would mean creating exceptions in the parser,
What do you mean with "exceptions in the parser"? > ambiguous syntax Octave checks contain an equals signs, so if you can have a scheme function on the left side of an assignment that has a music argument, the equals sign can be either part of the music argument or of the assignment. > and making some other interesting stuff impossible. Not really. It's just not possible to do nicely right now since the type of a music function must be known to the parser in advance, and once you get "vector of xxx", the number of different types just explodes. So having this available usefully more or less means getting rid of the "must be known in advance" design of the parser, and I am working on that. It is just slow progress. > So, i'm a bit lost... None of the existing proposals is going forward because the "vector solution" (branch dev/vector contains a proof of concept for just vector-of-music) might obliterate the need of either, so there is no point in establishing something more ugly in advance which one might then have to support in perpetuity. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
