Menu
▾
▴
#1670 Allow numbers in variable names: violin.1.mvt.2 = c'
nobody
None
abandoned
Enhancement
2016-09-18
2011-05-27
Anonymous
No
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Users often request variable names including numbers or underscores
(http://lists.gnu.org/archive/html/lilypond-user/2011-05/msg00177.html)
1) It is not too hard for the lexer, which breaks input into tokens, to accept backslashed variable names with various characters.
(http://lists.gnu.org/archive/html/lilypond-devel/2004-03/msg00124.html)
We could then use something like:
"violin1" = { c d e }
\new Staff \violin1
but what do we really want to allow in variable names?
I don't think underscores are a good idea, because both human and computer could be confused:
c^\slide_1 % is that slide on the first finger or did somebody define \slide_1 ?
Ending in a number would require we enforce the space after a command (and convert-ly old scores) for cases like \times2/3{c d e}
2) There is considerable difficulty in telling Lilypond to be ready for the definition of a variable that looks somewhat like, because the grammar allows un-braced music expressions and user-defined functions.
\mySpecialAfterGrace do1 re2 mo3 = fa2
Lily would need to know how many arguments \MySpecialAfterGrace takes to know whether she needs to look up 'mo' as the name of a pitch in some language.
Either that, or tentatively read through to the '=' and then back up when she realized 'mo' was not a mis-typed note name.
(2) might be impossible, but maybe users want \violin1 badly enough to use quotes around it in the definition, as I did above?
Originally posted by: k-ohara5...@oco.net
typo correcting in (2):
... considerable difficulty in telling Lilypond to be ready for the definition of a variable that looks somewhat like a music expression, because the grammar allows
violin1 = \mySpecialAfterGrace do1 re2 mo3 = fa2
Originally posted by: Carl.D.S...@gmail.com
Personally, I prefer the current behavior. violinOne is no harder than violin1 to read or type, and it keeps the syntax cleaner.
LilyPond is confusing enough as it is; I think requiring quotes around variable definitions in order to allow numbers would be a mistake.
Originally posted by: percival.music.ca@gmail.com
I agree with Carl. I'm glad that Keith looked into it and clarified the issue, but given the choices he laid out, I think the status quo is better.
If somebody has an alternate solution, then by all means we can discuss this again.
Originally posted by: tdanielsmusic
I agree with Carl too.
Trevor
Originally posted by: k-ohara5...@oco.net
> I think requiring quotes around variable definitions in order to allow numbers would be a mistake.
Just to be clear, only definitions of those variables with numbers need quotes:
timpani = \relative c, { ...
"motif254" = { ...
"violin1" = \relative c'' { ... \motif254
\score {<< \violin1 \timpani >>}
Originally posted by: Carl.D.S...@gmail.com
I understand. But that gives one more special case: "You don't normally need to put quotes around the variable name in a variable definition. But if you want to include a number, you do need to put quotes."
I don't like the special case. And we try (in our examples) to avoid having the user need to understand special cases. So we'd probably need to make a rule for documentation that said "Variables being defined should be surrounded by quotes". And then every variable definition in our manuals would have quotes around it. And it wouldn't be a simple convert-ly rule to write.
All for a minor benefit. Our language has a well-defined rule for variables: letters only. It works just fine, as far as I can see.
Originally posted by: percival.music.ca@gmail.com
there are some interesting ideas here. I've added them to the GLISS list, and we will discuss them in due course.
Originally posted by: j...@sente.ch
To state a user opinion (I'm in jazz). It would be very very helpful to have numbers in variables. I've been missing that since I use lilypond
Not just for section but also for bar numbers. ThemeFromBarsThirtyTwoToSixtyFour versus theme32-64. Numbers are easier to grasp with the eye than words.
Originally posted by: k-ohara5...@oco.net
Accidentally, this leaked into in the draft 2.15.16 user manual:
The previous example could also be written as follows:
"custom-tuning" = \stringTuning <c' g' d'' a''>
It came from automatic conversion of what was formerly Scheme code. The quotes allow the otherwise forbidden hyphen '-' into the variable name.
I make the following modest proposal: Scheme variables used in LilyPond should conform to the rules for LilyPond variables. customHtuning is no harder than custom-tuning to read or type, and it keeps the syntax cleaner.
Originally posted by: dak@gnu.org
Fine modest proposal. But customHtuning is harder to read/type. I'd have chosen a different name, but to be fair: this variable is only used in the context of specifying a _Scheme_ expression not otherwise useful to Lilypond, namely as #custom-tuning. There _is_ a notable difference between #xxx and \xxx right now: if xxx is a music function, #xxx names it, but \xxx _calls_ it. And one needs the difference even when I continue on my quest of autoexporting Scheme expressions in every conceivable context:
zap=#somemusicfunction
zap=\somemusicfunction
need to stay different in meaning.
As another example of identifiers not generally useful as Scheme variables, take a look at scm/define-music-properties.scm. I don't particularly like the various different identifier syntaxes, though.
Originally posted by: dak@gnu.org
And now for a somewhat hilarious side-effect of Issue 2024:
$identifier-in-Scheme-syntax
is pretty much equivalent to what you would want here for calling your variables with strange characters in their name. I would not recommend it, but it should work.
Originally posted by: k-ohara5...@oco.net
Issue 2707 makes some progress on the original request: allowing underscores in users' variable names (but not as the last character in the name, thus avoiding the confusion mentioned above with \slide_1 ).
There is some discussion at issue 2707 on why numbers are a bit more difficult, because violin1 has form similar to csharp2 or lyrics sing4 or chords c2:maj7m5
Of course this is no problem inside music expressions (notes, lyrics, or chords) where the variables are distinguished by their '\': \violin1
The difficulty is in the definition. LilyPond allows (for no good reason I can see) music expressions outside of any braces, where we define our variables. (The lexer starts reading our files in note-mode.) Thus a confusing input file like
cflatflat1 = cisis2 % more sensibly: violin1 = { cisis2 }
\new Staff \cflatflat1
is a bit tricky for the lexer to divide into tokens.
Labels: -Priority-Postponed
Status: Started
Originally posted by: dak@gnu.org
"Status: Started" does not make sense without an owner. Anyway, regarding "for no good reason I can see": LilyPond allows using a music function at top level, like
\relative c' { c d e f }
but music function arguments do not need to be enclosed in braces. In fact, using braces on the last argument of \tweak would render it non-operative:
\tweak NoteHead #'color #red { c' }
would not work since the sequential music does not even have a NoteHead. Should we strip one level of braces in function arguments like #{ ... #} does by now?
That would be actually a rather large incompatible change. What with
\relative c' << \new Staff ... >> ? Strip or not when writing
\relative c' { << \new Staff ... >> } ?
It does not really appear like any small amount of surgery will do here easily. Also, what with
c\f_1
Is \f_1 one command, or several?
Status: Accepted
Originally posted by: k-ohara5...@oco.net
This version allows numbers at the end of names, so we would need to convert-ly
\times2/3 => \time 2/3 and \skip2 => \skip 2
Numbers are not allowed after underscores, nor underscores at the end of a name, so
\f_1 == \f _1
Music with durations must be enclosed in at least one level of {} or <>, so
showFirstLength = [r1]*3 => showFirstLength = { [r1]*3 }
but any enclosing set of braces is enough:
\new Staff { \afterGrace c2 d8 e2 }
The remaining problem is the pitch in \relative c' {c4 d e f }
( \relative <c'> {c4 d e f} is inconvenient.) It might work to have the pitch-names loaded when reading top-level. At the moment I switch to note-reading-mode upon seeing the music function name, so
violin1 = \relative c' {c d} violin2 = {e f}
fails to accept the violin2 as a single-word variable name.
This gives a clean make check, but we will not want to adopt this. It might be useful as a concrete example of the challenges, while we are thinking about syntax.
http://codereview.appspot.com/6493072/
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
Waiting for GLISS discussion
Labels: -Patch-review Patch-waiting
Originally posted by: k-ohara5...@oco.net
Oops, up in comment 12 I mis-typed the link to the closely-related issue that put underscores in identifiers. That should be issue two_thousand_seven_hundred_two.
Originally posted by: janek.li...@gmail.com
A general comment on the idea: while sometimes i miss the ability to use digits in variable names, i believe that adding support for this will increase confusion a lot, as well as make things more complicated.
Thus, i'm generally opposed to the change :(
Originally posted by: k-ohara5...@oco.net
Increase confusion in what cases?
Are these cases all of the type were a new variable immediately follows a music function ?
violin1 = \relative c' {c4 d} violin2 = {e4 f}
% violin2 is read as a possible note name violin with duration 2
Make which things more complicated?
Originally posted by: k-ohara5...@oco.net
After some syntax discussions (GLISS) it appears that LilyPond will continue to allow notes outside of any {} or <> braces, so defining variables containing digits continues to be ambiguous:
links2a = \myFunction recs2a = \otherFunction
(In Spanish, 'recs2' is a note, which could be an argument of \myFunction, and 'a' is a valid variable name.) There is widespread opinion, comments 2--6, that using quotes around things like "recs2a" to resolve this ambiguity, is unwise.
Bernard pointed out that a designated lead-in character before the digits would avoid any ambiguity. He suggested preceding any digits with '0', but in LilyPond the dot character '.' is already familiar as a joining character, as in "\override Staff.BarLine".
Then we can continue to write \skip2 for a \skip of duration 2, but we can also write
violin.1 = \relative f {c'4 d e f}
\new Staff { \violin.1 }
http://codereview.appspot.com/6493072/
Labels: -Patch-waiting Patch-new
Status: Started
Originally posted by: dak@gnu.org
Regarding comment #21: LilyPond does not allow notes at the toplevel itself, but they are allowed as part of toplevel constructs in a manner that does not really facilitate robust mode switching within the constructs.
With regard to name.7 : the current uses of the period as a separating character are not forming lexical units: you can always intersperse blanks and/or create parts of the expression using Scheme expressions or strings. There is, admittedly, one mostly transparent exception in that a.b will become a single string in lyrics mode and will be pulled apart into constituents in the parser during analysis, but this exception is can't be told from the real thing as long as you don't write a. b which then is two words, and not a symbol list. You would turn this exception into the rule.
For better or worse, .3 is already considered a floating point number on its own.
I don't quite see comment #6 as an endorsement of this scheme since it applies to a different situation (we _did_ change identifier syntax after a lot of deliberation in order to unify it across modes) and I don't really see that the complexity it seeks to avoid is in any case reduced by using schemes including dots rather than quotes.
Make no mistake: the exceptions I introduced also are not something I am overly fond of, they just appeared to introduce more advantages than disadvantages. \"violin1", make no mistake, is quite ugly as well, but at least it does not cause significant syntax compromises elsewhere. It delivers this "feature" without messing with existing lexical units.
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
We have worked out a few options that can work, without requiring any changes to existing scores
violin.1.mvt.3 = {...} \new Staff { \violin.1.mvt.3 \section.2a }
violin01_mvt03 = {...} \new Staff { \violin01_mvt03 \section02a }
"violin 1 mvt 3" = {...} \new Staff { \"violin 1 mvt 3" \"section 2a" }
but I don't think it worth the complexity to add any of them, when we have (from comment 11 above) : "violin1mvt3" = { c2 } \new Staff { $violin1mvt3 }
Labels: -Patch-review Patch-abandoned
Status:
Indeed, with issue 4797 and several earlier parser changes, the first of these options (
violin.1) does work, although in a slightly different way by creating an alist. (Which may have side effects, and the corresponding\violin.1cannot be used in all situations where\violincan be used.)Still, I think this issue is reasonably covered by that, and the topic is on the TODO-list for the mythical GLISS, which might still happen one day.
So I vote for closing the issue.
Related
Issues:
#4797