Re: Why no numbers allowed in variables?
David Kastrup writes:
> David Kastrup writes:
>
>> Thomas Morley 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
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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Maarten Deen writes: > On 2018-10-03 10:13, David Kastrup wrote: >> Maarten Deen writes: > >>> But the solution offered by Kieren did not work in 2.16.2 (didn't test >>> other versions). >> >> 2.16.2 is, like, really old. Released more than 5 years ago. If you >> are doing typesetting of new scores, there is really not much of a >> point >> of fighting the constraints of software as old as that. > > Don't get me wrong, I'm not complaining it isn't possible there. It's > just that I have that version installed on my Ubuntu system as it is > the one in apt and it was the first one I tested with so my first idea > was "why doesn't this work with me". That's likely a rather old Ubuntu. Certainly not the latest stable. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
On 2018-10-03 10:13, David Kastrup wrote: Maarten Deen writes: But the solution offered by Kieren did not work in 2.16.2 (didn't test other versions). 2.16.2 is, like, really old. Released more than 5 years ago. If you are doing typesetting of new scores, there is really not much of a point of fighting the constraints of software as old as that. Don't get me wrong, I'm not complaining it isn't possible there. It's just that I have that version installed on my Ubuntu system as it is the one in apt and it was the first one I tested with so my first idea was "why doesn't this work with me". It is perfectly fine that it works in 2.18.2 because I do most of my typesetting with that version anyway (installed on my Windows system), but I do again want to express that I hope this wasn't some side effect of some other change that may or may not disappear in a future version. Since if this would be a documented feature, there does not need to be an annual discussion about it ;) Regards, Maarten ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Maarten Deen writes:
> On 2018-10-02 22:56, David Kastrup wrote:
>> Kieren MacMillan writes:
>>
>>> Hi Harm,
>>>
val = "foo"
<<
\new Staff \repeat unfold 4 c'4
\new Lyrics \lyricmode { \val4 \val2 \val4 }
\new Lyrics \lyricmode { \val4 \val4 \val2 }
>>
Your proposal would make it impossible.
>
> Thanks for the examples. Obviously I'm not such a hard core user to
> see all the problems that are associated with my lament.
>
>> It's not like we don't have this discussion pretty much every year.
>
> But the solution offered by Kieren did not work in 2.16.2 (didn't test
> other versions).
2.16.2 is, like, really old. Released more than 5 years ago. If you
are doing typesetting of new scores, there is really not much of a point
of fighting the constraints of software as old as that.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
On 2018-10-02 22:56, David Kastrup wrote:
Kieren MacMillan writes:
Hi Harm,
val = "foo"
<<
\new Staff \repeat unfold 4 c'4
\new Lyrics \lyricmode { \val4 \val2 \val4 }
\new Lyrics \lyricmode { \val4 \val4 \val2 }
Your proposal would make it impossible.
Thanks for the examples. Obviously I'm not such a hard core user to see
all the problems that are associated with my lament.
It's not like we don't have this discussion pretty much every year.
But the solution offered by Kieren did not work in 2.16.2 (didn't test
other versions). No idea if the possibility to use quoted variables was
added consciously but I also can't find a reference to this in the
documentation (while instrumentOne and instrumentTwo are used as
examples).
Maybe this needs to be documented. And if it is a happy side effect of
some other change, it might be good to realise it's there and users
probably like it (hate to see this disappear in a next version).
Regards,
Maarten
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
On 2018-10-02 18:31, Kieren MacMillan wrote:
Hi Maarten,
Why are there no numbers allowed in variable names?
\version "2.18.2"
"part1" = { c''4 4 4 4 }
\score {
\new Staff \"part1"
}
As for why you need the quotes… well, I’ll leave the explanation up to
more knowledgeable people than I.
Thanks, that works (well, "part1" = { c''4 c c c } does ;) ).
This does not work in 2.16.2 though, that version can not cope with
quoted variables.
Regards,
Maarten
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
David Kastrup writes: > Thomas Morley 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. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Thomas Morley 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). > The dot feels more natural for me anyway. Yup. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Am Mi., 3. Okt. 2018 um 00:38 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
> >
> >> So what is wrong with using \"var2" or \var.2 ?
> >
> > As a side note.
> >
> > I wasn't aware a comma works as well
> > qwerty,2 = "bar"
>
> That's likely a side effect of comma-separated lists having been made
> identical to dot-separated ones in most respects so that you can write
> stuff like
>
> \keepWithTag violI,violII ...
>
> where a dot looks awkward. Feels like "don't go there" syntax, really.
>
> > Although, while calling it, you _must_ use the dot
> > \new Lyrics \lyricmode { \qwerty.2 }
>
> That's sort of ugly, indeed. Probably because , can be an octave
> marker, so if the identifier is a pitch... But of course a similar
> reasoning would hold when the identifier is a duration followed by a
> dot.
>
> And admittedly, with the _current_ grammar, treating '.' and ',' equal
> in that context does not trigger a warning. However, here clearly the
> "hierarchical" interpretation is given rather than the "list of equals"
> and so I am queasy about fudging this option into the grammar when I
> don't have a good feeling about what price may be to pay for it in
> future and I don't see a real use case where that grammar would be the
> preferred one.
>
> --
> David Kastrup
It was an observation, not a proposal.
Speaking only for myself, I can perfectly life without the
comma-syntax in definitions and their calls.
The dot feels more natural for me anyway.
But again, that's only me.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Thomas Morley writes:
> Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
>
>> So what is wrong with using \"var2" or \var.2 ?
>
> As a side note.
>
> I wasn't aware a comma works as well
> qwerty,2 = "bar"
That's likely a side effect of comma-separated lists having been made
identical to dot-separated ones in most respects so that you can write
stuff like
\keepWithTag violI,violII ...
where a dot looks awkward. Feels like "don't go there" syntax, really.
> Although, while calling it, you _must_ use the dot
> \new Lyrics \lyricmode { \qwerty.2 }
That's sort of ugly, indeed. Probably because , can be an octave
marker, so if the identifier is a pitch... But of course a similar
reasoning would hold when the identifier is a duration followed by a
dot.
And admittedly, with the _current_ grammar, treating '.' and ',' equal
in that context does not trigger a warning. However, here clearly the
"hierarchical" interpretation is given rather than the "list of equals"
and so I am queasy about fudging this option into the grammar when I
don't have a good feeling about what price may be to pay for it in
future and I don't see a real use case where that grammar would be the
preferred one.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
On 02/10/18 23:25, David Kastrup wrote: > J Martin Rushton writes: > >> This discussion is strangely familiar. As one who learnt on FORTRAN IV >> many years ago, I'm used to seeing that: >> >> READ INPUT TAPE 5, 501, IA, IB, IC >> and >> READINPUTTAPE5,501,IA,IB,IC >> or even >> RE ADIN PUTTA PE5,5 01,I A,I B,I C >> >> are the same. I'm sure there were those back in the late '50s arguing >> over the use of spaces and numbers within variables. >> >> (OT) I've even seen code which intentionally mangled FORTRAN source to >> make it unreadable, like the third example above. > > That's more like making spaces not have any lexical meaning, ever. > Basically, if it cannot be part of an identifier, it also cannot > separate them. Also you have to be aware that a fresh punch card is > both empty and contains 80 spaces. Basically spaces are not even > recognizable characters in the original typical Fortran input medium. > > For TeX it was more the decision to be able to write things like > > \count5=7 > > and LilyPond input is very very loosely modeled after that (via MusicTeX > and MPP). > Quite correct. Early FORTRAN compilers eliminated all spaces (other than those in Hollerith strings) and then parsed the resultant mess. -- J Martin Rushton MBCS signature.asc Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
J Martin Rushton writes: > This discussion is strangely familiar. As one who learnt on FORTRAN IV > many years ago, I'm used to seeing that: > > READ INPUT TAPE 5, 501, IA, IB, IC > and > READINPUTTAPE5,501,IA,IB,IC > or even > RE ADIN PUTTA PE5,5 01,I A,I B,I C > > are the same. I'm sure there were those back in the late '50s arguing > over the use of spaces and numbers within variables. > > (OT) I've even seen code which intentionally mangled FORTRAN source to > make it unreadable, like the third example above. That's more like making spaces not have any lexical meaning, ever. Basically, if it cannot be part of an identifier, it also cannot separate them. Also you have to be aware that a fresh punch card is both empty and contains 80 spaces. Basically spaces are not even recognizable characters in the original typical Fortran input medium. For TeX it was more the decision to be able to write things like \count5=7 and LilyPond input is very very loosely modeled after that (via MusicTeX and MPP). -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
I run into this regularly as well, and have been resigned to using rhPartOne, rhPartTwo, rhPartThree or rhPartA, rhPartB, rhPartC I appreciate hearing about "rh1" and \"rh1". That seems reasonable, albeit ugly. Thanks for that. rh.1 would be preferable, but does not work as of 2.18.2. -- Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
> So what is wrong with using \"var2" or \var.2 ?
As a side note.
I wasn't aware a comma works as well
qwerty,2 = "bar"
Although, while calling it, you _must_ use the dot
\new Lyrics \lyricmode { \qwerty.2 }
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes: > Hi all, > > I guess all that’s left is to reiterate my observation that there > appears to be little enthusiasm for pursuing this possible feature. This reminds me a bit of a talk in a "Fuzzy Logic" conference where some speakers basically stated that their approach already managed to reach a quarter of the theoretical maximum performance so they just needed to get a lot more research funding in order to surpass the theoretical maximum. It doesn't really matter how much enthusiasm you manage to drum up here short of managing to convince people that this is worth having to separate _every_ duration with a space from any preceding letter: that would indeed be a game changer. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
This discussion is strangely familiar. As one who learnt on FORTRAN IV
many years ago, I'm used to seeing that:
READ INPUT TAPE 5, 501, IA, IB, IC
and
READINPUTTAPE5,501,IA,IB,IC
or even
RE ADIN PUTTA PE5,5 01,I A,I B,I C
are the same. I'm sure there were those back in the late '50s arguing
over the use of spaces and numbers within variables.
(OT) I've even seen code which intentionally mangled FORTRAN source to
make it unreadable, like the third example above.
On 02/10/18 22:27, Thomas Morley wrote:
> Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
>
>> So what is wrong with using \"var2" or \var.2 ?
>
> Ah, I forgot about var.1 etc
>
> Ofcourse below is a bit ugly I'd say:
>
> val.1 = "foo"
> <<
> \new Staff \repeat unfold 4 c'4
> \new Lyrics \lyricmode { \val.1 4 \val.1 2 \val.1 4 }
>>>
>
> Another possibility is to use superscript like
> val² = ...
> Ofcourse it's soso...
> It works not because it's supported but because it's not disallowed.
> Which may change in the future.
>
>
> Cheers,
> Harm
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
--
J Martin Rushton MBCS
signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes: > Hi David, > >> The logic does not change every time you cheer > > That’s demonstrably false: there have been features which were > requested years ago which were too difficult to implement at the time, > but which became easier to implement later because of other code > improvements (many your own doing). This one is rather fundamentally a consequence of quite engrained syntax decisions. Which may have some roots in the TeX-centric syntax designed for the MPP (?) music preprocessor for MusicTeX: Han-Wen and Jan certainly had a strong TeX background. Once you can no longer write c4 but have to write c 4 instead, it will be easy to make that change. Good luck campaigning for that. The kind of logic that has more of a chance to change is that the like of \violin.2 (which has no problems being written as \violin.#(+ 1 1) by the way) is likely to work in more circumstances than it does now. That's something where gradual improvements are reasonable to be expected. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi all, I guess all that’s left is to reiterate my observation that there appears to be little enthusiasm for pursuing this possible feature. Thanks for the discussion, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi David, > The logic does not change every time you cheer That’s demonstrably false: there have been features which were requested years ago which were too difficult to implement at the time, but which became easier to implement later because of other code improvements (many your own doing). Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Thomas Morley writes:
> Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
>
>> So what is wrong with using \"var2" or \var.2 ?
>
> Ah, I forgot about var.1 etc
>
> Ofcourse below is a bit ugly I'd say:
>
> val.1 = "foo"
> <<
> \new Staff \repeat unfold 4 c'4
> \new Lyrics \lyricmode { \val.1 4 \val.1 2 \val.1 4 }
>>>
>
> Another possibility is to use superscript like
> val² = ...
> Ofcourse it's soso...
> It works not because it's supported but because it's not disallowed.
> Which may change in the future.
It would be pretty unusual to make non-syntactical characters gain
additional meaning.
We did get some puzzlement from people (notably Valentin) when stuff
like c_° became a valid identifier (it previously was equivalent to
c_"°" ). But that was not as much a matter of special-treating ° as it
was of new rules for _ in the formation of identifiers.
It's conceivable that there would be some unicode unification at some
point of time (like some operating systems have for file names) so that
an umlaut written as a letter of its own or formed using a diacritical
combining character would be treated identically. But I don't think we
should go much beyond that.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes: > Hi David, > >> So what is wrong with using \"var2" > > That’s what I generally use — it requires extra typing, looks less > attractive, looks (and is often colourized) Well, that would warrant improving your LilyPond code colorifier. > different from variables without numbers, etc. Oh, you can just use quotes for all of them, then. There is, of course, also \var₂ . > >> or \var.2 ? > > I was under the impression that mechanism has limitations? Yes. For music it should usually work (or be easy to provide a syntactic context where it will). Not for every other type of variable. > In any case, the drawbacks listed above hold here as well. > > I guess I’ll just stick with my standard workarounds. =) I'll assume that as a composer you'll usually have to accept the constraints of your musicians' instruments as well. And showing off a proof-of-concept recorder where you have drilled an additional hole yourself is unlikely to convince your soloist to have a go at his own instrument. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Am Di., 2. Okt. 2018 um 23:17 Uhr schrieb David Kastrup :
> So what is wrong with using \"var2" or \var.2 ?
Ah, I forgot about var.1 etc
Ofcourse below is a bit ugly I'd say:
val.1 = "foo"
<<
\new Staff \repeat unfold 4 c'4
\new Lyrics \lyricmode { \val.1 4 \val.1 2 \val.1 4 }
>>
Another possibility is to use superscript like
val² = ...
Ofcourse it's soso...
It works not because it's supported but because it's not disallowed.
Which may change in the future.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi David, > So what is wrong with using \"var2" That’s what I generally use — it requires extra typing, looks less attractive, looks (and is often colourized) different from variables without numbers, etc. > or \var.2 ? I was under the impression that mechanism has limitations? In any case, the drawbacks listed above hold here as well. I guess I’ll just stick with my standard workarounds. =) Thanks! Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi David,
>
>> I can understand newcomers coming up with this proposal: LilyPond is
>> different to how most languages bar TeX treat numbers. But it does
>> puzzle me to have the old hands cheer them on.
>
> Only because I’ve needed/wanted numbered variables literally thousands
> of times in the past 15 years of using Lilypond, whereas I’ve not even
> once ever needed/wanted
>
>var = "foo"
>\lyricmode { \var2 \var4 \var2 }
>
> So I’m cheering on the newbie-feature-requesters because this feature,
> if implemented, would markedly improve my life as an engraver, whereas
> the limitations that might be introduced would (as far as I can tell)
> have zero effect either way on my engraving needs.
The logic does not change every time you cheer, and you know the
perfectly viable alternatives. So I don't really see the point in
setting up the newbies for disappointment.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi David,
>
>> I can understand newcomers coming up with this proposal: LilyPond is
>> different to how most languages bar TeX treat numbers. But it does
>> puzzle me to have the old hands cheer them on.
>
> Only because I’ve needed/wanted numbered variables literally thousands
> of times in the past 15 years of using Lilypond, whereas I’ve not even
> once ever needed/wanted
>
>var = "foo"
>\lyricmode { \var2 \var4 \var2 }
>
> So I’m cheering on the newbie-feature-requesters because this feature,
> if implemented, would markedly improve my life as an engraver, whereas
> the limitations that might be introduced would (as far as I can tell)
> have zero effect either way on my engraving needs.
So what is wrong with using \"var2" or \var.2 ?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Thomas Morley writes:
> Am Di., 2. Okt. 2018 um 22:37 Uhr schrieb Kieren MacMillan
> :
>>
>> Hi Harm,
>>
>> > val = "foo"
>> > <<
>> > \new Staff \repeat unfold 4 c'4
>> > \new Lyrics \lyricmode { \val4 \val2 \val4 }
>> > \new Lyrics \lyricmode { \val4 \val4 \val2 }
>> >>>
>> >
>> > Your proposal would make it impossible.
>>
>> Another good example — thanks. That being said, putting a syllable
>> in a variable and then adding durations to it seems to me — as
>> someone who engraves a *huge* amount of vocal music, from a wide
>> variety of styles, genres, and eras — like a *much* "fringe-i-er"
>> case than the number of cases that would benefit from restricting
>> \variableName2 to count as a variable name.
>>
>> Regardless, it doesn’t seem like there’s much enthusiasm to pick up
>> the feature request.
>
> Not so hasty ;)
> Though, I second David. We would need a logical coherent method.
> Without having to much drawbacks.
> Honestly, I don't have such a proposal and even if I would have one,
> I'm not able to implement something like that.
I've had a few cases of convincing myself that "this should be doable"
where the parser generator disagreed with me and I had to fire up some
scripts of mine that constructed examples based on the parser's analysis
that were ambiguous.
Of course it's just anecdotal handwaving to bring this up in relation to
a specific proposal.
> Otoh, counting use-cases is not a bad argument either.
This particular use case can be handled by using quotation marks for
both definition and use, using
"violins1" = ...
and calling with \"violins1"
And of course, with somewhat restricted generality,
violins.1 = { e' e' e' e' }
violins.2 = { c' c' c' c' }
\new Staff << \violins.1 \\ \violins.2 >>
will also work. Not for everything, but at least for most music
expressions.
So it's not like "use cases" for people rejecting Roman numberals on
principle are not doable. Stuff just looks uglier.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi David,
>
> Thanks for the examples and explanations.
>
>> You'd probably also think that
>>
>> { c = -3 }
>>
>> is an assignment. It isn't. It is a note c with a relative octave
>> check and a fingering of 3 .
>
> Fair enough. So there would, at the very least, be some sort of new
> assignment syntax for variables with numbers in them. Ugh.
>
>> It isn't "post-fixed". It is a note of its own.
>> partI = { tambourine 4. 8 4 4 }
>> \drums { \rhythm 2 r2 }
>
> Can the compiler not be instructed on how to tell the difference between
>
>\rhythm2
>
> and
>
> \rhythm 2
>
> ? (Honest question: I don’t know the parser / lexer / compiler limitations.)
So spaces before numbers and following letters are to be interpreted
differently when the preceding letters happen to be a pitch name? And
when assigning a pitch to a variable, I need to separate the use of the
variable from the following duration? Also if the duration is something
like \breve ?
At any rate, spaces are _separators_ of some lexical entities but do not
become a lexical entity themselves. Trying to let them interact with
some semantical differences here is really nightmarish stuff. It would
be close to impossible to write coherent reliable manuals describing
that kind of handwaving even if you managed to fudge something meeting
more naive expectations than breaking currently more-or-less consistent
behavior.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi Harm,
>
>> val = "foo"
>> <<
>> \new Staff \repeat unfold 4 c'4
>> \new Lyrics \lyricmode { \val4 \val2 \val4 }
>> \new Lyrics \lyricmode { \val4 \val4 \val2 }
>>
>> Your proposal would make it impossible.
>
> Another good example — thanks. That being said, putting a syllable in
> a variable and then adding durations to it seems to me — as someone
> who engraves a *huge* amount of vocal music, from a wide variety of
> styles, genres, and eras — like a *much* "fringe-i-er" case than the
> number of cases that would benefit from restricting \variableName2 to
> count as a variable name.
>
> Regardless, it doesn’t seem like there’s much enthusiasm to pick up
> the feature request.
It's not like we don't have this discussion pretty much every year.
I can understand newcomers coming up with this proposal: LilyPond is
different to how most languages bar TeX treat numbers. But it does
puzzle me to have the old hands cheer them on.
It's basically a consequence of durations not requiring to be separated
by spaces from note names and consequently not from other letters
either. The = syntax for relative octave checks does not exactly help
squeezing some exceptions in either.
It's a bit dissatisfactory to go the "why don't you believe me" route on
this but there is a reason that the picture of the original "Principles
of Compiler Design" book by Aho&Ullman featured a dragon. "Why don't
you change the compiler yourself" is for one thing a cheap shot, and for
another it is also quite likely to actually lead to superficially
working results of the "well, I saw the parser generator warnings but
the results worked fine" kind where it takes considerable effort to
figure out just what kind of input will get broken by the changes.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi David,
> I can understand newcomers coming up with this proposal: LilyPond is
> different to how most languages bar TeX treat numbers. But it does
> puzzle me to have the old hands cheer them on.
Only because I’ve needed/wanted numbered variables literally thousands of times
in the past 15 years of using Lilypond, whereas I’ve not even once ever
needed/wanted
var = "foo"
\lyricmode { \var2 \var4 \var2 }
So I’m cheering on the newbie-feature-requesters because this feature, if
implemented, would markedly improve my life as an engraver, whereas the
limitations that might be introduced would (as far as I can tell) have zero
effect either way on my engraving needs.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Am Di., 2. Okt. 2018 um 22:37 Uhr schrieb Kieren MacMillan
:
>
> Hi Harm,
>
> > val = "foo"
> > <<
> > \new Staff \repeat unfold 4 c'4
> > \new Lyrics \lyricmode { \val4 \val2 \val4 }
> > \new Lyrics \lyricmode { \val4 \val4 \val2 }
> >>>
> >
> > Your proposal would make it impossible.
>
> Another good example — thanks. That being said, putting a syllable in a
> variable and then adding durations to it seems to me — as someone who
> engraves a *huge* amount of vocal music, from a wide variety of styles,
> genres, and eras — like a *much* "fringe-i-er" case than the number of cases
> that would benefit from restricting \variableName2 to count as a variable
> name.
>
> Regardless, it doesn’t seem like there’s much enthusiasm to pick up the
> feature request.
Not so hasty ;)
Though, I second David. We would need a logical coherent method.
Without having to much drawbacks.
Honestly, I don't have such a proposal and even if I would have one,
I'm not able to implement something like that.
Otoh, counting use-cases is not a bad argument either.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi Harm,
> val = "foo"
> <<
> \new Staff \repeat unfold 4 c'4
> \new Lyrics \lyricmode { \val4 \val2 \val4 }
> \new Lyrics \lyricmode { \val4 \val4 \val2 }
>>>
>
> Your proposal would make it impossible.
Another good example — thanks. That being said, putting a syllable in a
variable and then adding durations to it seems to me — as someone who engraves
a *huge* amount of vocal music, from a wide variety of styles, genres, and eras
— like a *much* "fringe-i-er" case than the number of cases that would benefit
from restricting \variableName2 to count as a variable name.
Regardless, it doesn’t seem like there’s much enthusiasm to pick up the feature
request.
Thanks!
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Am Di., 2. Okt. 2018 um 21:57 Uhr schrieb Kieren MacMillan
:
> If I were developing Lilypond code, I simply wouldn’t allow a note value to
> be post-fixed to a variable, so
>
>\part2
>
> would have only one interpretation (i.e., as the variable "part2"). But
> that’s only because I can’t see a good use case for the alternative.
Well, below is valid code
val = "foo"
<<
\new Staff \repeat unfold 4 c'4
\new Lyrics \lyricmode { \val4 \val2 \val4 }
\new Lyrics \lyricmode { \val4 \val4 \val2 }
>>
Your proposal would make it impossible.
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi David,
>
>> It's easy to tell the developers "make it so". But before you can tell
>> a compiler to "make it so", you need to have a logically coherent
>> proposal.
>
> I wasn’t trying to tell anybody to "make it so" — I was just avoiding
> offering my limited (and almost certainly flawed) understanding of
> Lily’s underpinnings when others (such as yourself) might give a
> detailed, useful, and accurate answer instead.
>
> However, I’m always happy to have a discussion towards a logically
> coherent proposal that would allow a compiler to "make it so" for some
> given feature/request such as this one.
>
> So here are my first offerings:
>
>> Is c4 a note or a variable name?
>
> If I saw
>
>c4 = something
>
> then I would think it’s a variable. If I saw
>
> c4 something
>
> (i.e., without an assignment operator) I would think it’s a note. Is
> that a rule that can be made logically coherent for a compiler?
No. You'd probably also think that
{ c = -3 }
is an assignment. It isn't. It is a note c with a relative octave
check and a fingering of 3 . I am not enthusiastic about all of the
inherited design decisions but there are a lot of scores and score
writers relying on them.
>> Is \part2 the variable "part" followed
>> by a half note, or is it the variable "part2"?
>
> If I were developing Lilypond code, I simply wouldn’t allow a note
> value to be post-fixed to a variable, so
>
>\part2
It isn't "post-fixed". It is a note of its own.
partI = { tambourine 4. 8 4 4 }
\drums { \rhythm 2 r2 }
is valid LilyPond input.
> would have only one interpretation (i.e., as the variable
> "part2"). But that’s only because I can’t see a good use case for the
> alternative. Can anyone suggest a reason to allow
>
>part = { c4 8 8 }
>\part2
>
> where the latter is intended to do something… um… coherent?
See above.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi David,
Thanks for the examples and explanations.
> You'd probably also think that
>
> { c = -3 }
>
> is an assignment. It isn't. It is a note c with a relative octave
> check and a fingering of 3 .
Fair enough. So there would, at the very least, be some sort of new assignment
syntax for variables with numbers in them. Ugh.
> It isn't "post-fixed". It is a note of its own.
> partI = { tambourine 4. 8 4 4 }
> \drums { \rhythm 2 r2 }
Can the compiler not be instructed on how to tell the difference between
\rhythm2
and
\rhythm 2
? (Honest question: I don’t know the parser / lexer / compiler limitations.)
Thanks,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi David,
> It's easy to tell the developers "make it so". But before you can tell
> a compiler to "make it so", you need to have a logically coherent
> proposal.
I wasn’t trying to tell anybody to "make it so" — I was just avoiding offering
my limited (and almost certainly flawed) understanding of Lily’s underpinnings
when others (such as yourself) might give a detailed, useful, and accurate
answer instead.
However, I’m always happy to have a discussion towards a logically coherent
proposal that would allow a compiler to "make it so" for some given
feature/request such as this one.
So here are my first offerings:
> Is c4 a note or a variable name?
If I saw
c4 = something
then I would think it’s a variable. If I saw
c4 something
(i.e., without an assignment operator) I would think it’s a note. Is that a
rule that can be made logically coherent for a compiler?
> Is \part2 the variable "part" followed
> by a half note, or is it the variable "part2"?
If I were developing Lilypond code, I simply wouldn’t allow a note value to be
post-fixed to a variable, so
\part2
would have only one interpretation (i.e., as the variable "part2"). But that’s
only because I can’t see a good use case for the alternative. Can anyone
suggest a reason to allow
part = { c4 8 8 }
\part2
where the latter is intended to do something… um… coherent?
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Kieren MacMillan writes:
> Hi Maarten,
>
>> Why are there no numbers allowed in variable names?
>
> \version "2.18.2"
>
> "part1" = { c''4 4 4 4 }
>
> \score {
> \new Staff \"part1"
> }
>
> As for why you need the quotes… well, I’ll leave the explanation up to
> more knowledgeable people than I.
Is c4 a note or a variable name? Is \part2 the variable "part" followed
by a half note, or is it the variable "part2"?
It's easy to tell the developers "make it so". But before you can tell
a compiler to "make it so", you need to have a logically coherent
proposal.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
I also miss numbers in variables and some kind of scoping for variables. Immanuel On Tue, Oct 2, 2018 at 5:45 PM Maarten Deen wrote: > Why are there no numbers allowed in variable names? I like to have some > kind of descriptive name for parts of the scores that I make in > Lilypond, and not having the possibility to use numbers in a snippet > name is a bit awkward. I make do with Roman numerals to get partI, > partII, partIII, partIV etc, but now I have Haydn's 104th symphony, > making SCVI-partI etc. > > Regards, > Maarten > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Why no numbers allowed in variables?
Hi Maarten,
> Why are there no numbers allowed in variable names?
\version "2.18.2"
"part1" = { c''4 4 4 4 }
\score {
\new Staff \"part1"
}
As for why you need the quotes… well, I’ll leave the explanation up to more
knowledgeable people than I.
Hope that helps!
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
