lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why no numbers allowed in variables?


From: David Kastrup
Subject: Re: Why no numbers allowed in variables?
Date: Tue, 02 Oct 2018 22:56:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Kieren MacMillan <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]