Re: Scheme doesn't check for missspeeled variable names???

[Aaron Hill]

(Do try to keep the mailing list on all replies, so that threads do not 
get disrupted and to ensure broad visibility and participation.)


On 2021-07-21 9:11 am, James B. Wilkinson wrote:
On Jul 20, 2021, at 11:16 PM, Aaron Hill  
wrote:


On 2021-07-20 8:11 pm, James B. Wilkinson wrote:

I fat-fingered the keyboard on my laptop and got this:
flute-notes = {
 \override BreathingSigh.Y-offset = #2.6  %% also
tried #5.0 and some really big numbers; no effect
 7 bars of music in 4/4
}
AND I never got an error message.


What version are you running?  You should have gotten this output:


Sure enough. I got the latest version, and that’s what happens now.

I had this:   2.22.0-1  on OS X 10.14.6

My use of Lillypond is sporadic. I prolly should start every project
with a fresh download.

thanks for the quick reply.


Well, to be fair, I would expect all versions of LilyPond to have 
produced that error.  As such, the issue was likely more about your 
environment and workflow, checking to see if some other process was 
hiding the error message.



-- Aaron Hill

Re: Scheme doesn't check for missspeeled variable names???

[Aaron Hill]

On 2021-07-20 8:11 pm, James B. Wilkinson wrote:

I fat-fingered the keyboard on my laptop and got this:

flute-notes = {
  \override BreathingSigh.Y-offset = #2.6  %% also
tried #5.0 and some really big numbers; no effect
  7 bars of music in 4/4
}


AND I never got an error message.


What version are you running?  You should have gotten this output:


GNU LilyPond 2.22.0
Processing `grob-paths.ly'
Parsing...
grob-paths.ly:4:13: error: bad grob property path
  \override
BreathingSigh.Y-offset = #2.6
Interpreting music...



-- Aaron Hill

Scheme doesn't check for missspeeled variable names???

[James B. Wilkinson]

I fat-fingered the keyboard on my laptop and got this:

flute-notes = {
  \override BreathingSigh.Y-offset = #2.6  %% also tried 
#5.0 and some really big numbers; no effect
  7 bars of music in 4/4
}


AND I never got an error message. This seems to mean that Scheme has no checks 
for valid identifiers. I’m reminded of a program we had back in the early 
1970’s; it printed an alphabetized list of all the identifiers in a BASIC 
program. If you’d misspelled something it jumped right out at you. Something 
like that would have saved me about two hours tonight.

sigh (as it were)

Re: Workaround for (not-allowed) numbers in variable names?

[Valentin Petzel]

Hello Stefano,

Here’s an improved version that also allows for Markup between the examples.

Cheers,
Valentin#(define (string-replace-substring s substring replacement)
  "Replace every instance of substring in s by replacement."
  (let ((sublen (string-length substring)))
(with-output-to-string
  (lambda ()
(let lp ((start 0))
  (cond
   ((string-contains s substring start)
=> (lambda (end)
 (display (substring/shared s start end))
 (display replacement)
 (lp (+ end sublen
   (else
(display (substring/shared s start)

catScore=
#(define-scheme-function (music title) (ly:music? string?)
   #{
 \score {
   \header {
 piece = \markup { #title }
   }
   #music
   \layout { }
 }
   #})

catMarkup=
#(define-scheme-function (text title) (markup? string?)
   #{
 \markup {
   \column {
 \line { #title }
 \line { #text }
 \vspace #0.5
   }
 }
   #})

addScore = #(define-void-function (score) (ly:score?) (add-score score)) 


% List contains eighter scores, or lists (score title="" count?=#t append?=#t sep="")
% Set title to a string, {idx} is replaced by current count. Set count?=#f to not count
% the current score, e.g. Ex. 2 and Ex. 2b. Set append?=#f to not append title to Ex. {idx},
% but to replace it. If append?=#t you may sep sep as Separator between Ex. {idx} and title
% can also take nested pairs (score title count append . sep)
%
% if score is music it is counted by default, if markup not
% if score is markup we replace the title by default
catScores=
#(define-void-function (listOfScores i) (list? number?)
   (if (not (null? listOfScores))
   (let* (
   (current (car listOfScores))
   (score (if (and (not (markup? current)) (pair? current)) (car current) current))
   (rest1 (if (and (not (markup? current)) (pair? current)) (cdr current) '()))
   (fmt   (if (null? rest1) ""
  (if (pair? rest1) (car rest1)
  rest1)))
   (rest2 (if (pair? rest1) (cdr rest1) '()))
   (count? (if (null? rest2) (ly:music? score)
(if (pair? rest2) (car rest2)
rest2)))
   (rest3 (if (pair? rest2) (cdr rest2) '()))
   (append?  (if (null? rest3) (ly:music? score)
(if (pair? rest3) (car rest3)
rest3)))
   (rest4 (if (pair? rest3) (cdr rest3) '()))
   (sep (if (null? rest4) ""
(if (pair? rest4) (car rest4)
rest4)))
   (fmt-real (if append? (string-join (list "Ex. {idx}" fmt) sep) fmt))
   (title (string-replace-substring fmt-real "{idx}" (if count? (+ 1 i) i)))
   )
 (if (ly:music? score)
 (add-score (catScore score title))
 (add-text (catMarkup score title)))
 (catScores (cdr listOfScores) (if count? (+ 1 i) i)
 

#(define catA (list
   #{ \markup\justify{ This Category contains Examples of very shady nature. Practise
   them with care, or they might eat your furniture! You’ve been warned! Really!
   This is the last chance to turn back!} #}
   #{ c'4 e'8 e' g' f' e'4 #}
   #{ d'4 4 16 16 e'8 g' d' #}
   #{ e'8 8 f' f' d' d' g4 #}
   (markup #:justify ( "This" "example" "has" "two" "unrelated" "subexamples." "Don’t" "ask" "for" "the" "reason ..."))
   (list #{ c'4 e'8 e' g' f' e'4 #} "b" #f) ; do not count and append b
   (list #{ d'4 4 16 16 e'8 g' d' #} "Example {idx}" #t #f) ; count and replace
   (list #{ \markup\justify{ A counted markup with title.} #} "" #t #t)
   (list #{ e'8 8 f' f' d' d' g4 #} "The Title" #t #t ": ") ; count, append, use : as sep
   ))


\markup "Only printing one category this time"

\catScores #catA 0

#(define catB (list
   #{ \time 2/3 \times 2/3 { f'4 g' a' e' } #}
   #{ \new StaffGroup <<
 \new Staff { c'8 d' e' f' e' d' c'4 } 
 \new Staff {\clef bass c4 g f e }
   >> #}
   #{  \new TabStaff { e, g b e' } #}))

printCats=
#(define-void-function (listOfCategories) (list?)
   (if (not (null? listOfCategories))
   (begin
 (add-text
  #{
   \markup\column{\larger\larger\larger\line { Category #(car (car listOfCategories)) } \vspace #0.6 }
  #})
 (catScores (cdr (car listOfCategories)) 0)
 (printCats (cdr listOfCategories)

#(define cats (list (cons "A" catA) (cons "B" catB)))

\bookpart {
\markup "Printing all categories"
\printCats #cats
}

signature.asc
Description: This is a digitally signed message part.

Re: Workaround for (not-allowed) numbers in variable names?

[Valentin Petzel]

Hello Stefano,

Here’s a slightly improved example, offering more control.

Cheers,
Valentin

Am Mittwoch, 10. März 2021, 05:31:07 CET schrieben Sie:
> Thank you for the example Valentin,
> 
> a very interesting approach.  I think I was headed in that direction, in
> fact, although you code will make me jump ahead quite a bit.
> 
> Cheers,
> 
> Stefano
> 
> On Fri, Mar 5, 2021 at 2:49 PM Valentin Petzel  wrote:
> > Hello Stefano,
> > 
> > You might try to keep the whole thing dynamic and leave the numbering and
> > stuff to Lilypond. For example you could have just a list of all Examples
> > in
> > one Category and then have a function to print that out. You could even do
> > a
> > list of Categories and print them all at once. This way you could even
> > manage
> > your Scores anyway you want, and adding Examples to one Group requires
> > just
> > adding it to that list. See the appended File for an example.
> > 
> > Cheers,
> > Valentin#(define (string-replace-substring s substring replacement)
  "Replace every instance of substring in s by replacement."
  (let ((sublen (string-length substring)))
(with-output-to-string
  (lambda ()
(let lp ((start 0))
  (cond
   ((string-contains s substring start)
=> (lambda (end)
 (display (substring/shared s start end))
 (display replacement)
 (lp (+ end sublen
   (else
(display (substring/shared s start)

catScore=
#(define-scheme-function (music title) (ly:music? string?)
   #{
 \score {
   \header {
 piece = \markup { #title }
   }
   #music
   \layout { }
 }
   #})

addScore = #(define-void-function (score) (ly:score?) (add-score score)) 


% List contains eighter scores, or lists (score title="" count?=#t append?=#t sep="")
% Set title to a string, {idx} is replaced by current count. Set count?=#f to not count
% the current score, e.g. Ex. 2 and Ex. 2b. Set append?=#f to not append title to Ex. {idx},
% but to replace it. If append?=#t you may sep sep as Separator between Ex. {idx} and title
% can also take nested pairs (score title count append . sep)
catScores=
#(define-void-function (listOfScores i) (list? number?)
   (if (not (null? listOfScores))
   (let* (
   (current (car listOfScores))
   (score (if (pair? current) (car current) current))
   (rest1 (if (pair? current) (cdr current) '()))
   (fmt   (if (null? rest1) ""
  (if (pair? rest1) (car rest1)
  rest1)))
   (rest2 (if (pair? rest1) (cdr rest1) '()))
   (count? (if (null? rest2) #t
(if (pair? rest2) (car rest2)
rest2)))
   (rest3 (if (pair? rest2) (cdr rest2) '()))
   (append?  (if (null? rest3) #t
(if (pair? rest3) (car rest3)
rest3)))
   (rest4 (if (pair? rest3) (cdr rest3) '()))
   (sep (if (null? rest4) ""
(if (pair? rest4) (car rest4)
rest4)))
   (fmt-real (if append? (string-join (list "Ex. {idx}" fmt) sep) fmt))
   (title (string-replace-substring fmt-real "{idx}" (if count? (+ 1 i) i)))
   )
 (add-score (catScore score title))
 (catScores (cdr listOfScores) (if count? (+ 1 i) i)
 

#(define catA (list
   #{ c'4 e'8 e' g' f' e'4 #}
   #{ d'4 4 16 16 e'8 g' d' #}
   #{ e'8 8 f' f' d' d' g4 #}
   (list #{ c'4 e'8 e' g' f' e'4 #} "b" #f) ; do not count and append b
   (list #{ d'4 4 16 16 e'8 g' d' #} "Example {idx}" #t #f) ; count and replace
   (list #{ e'8 8 f' f' d' d' g4 #} "The Title" #t #t ": ") ; count, append, use : as sep
   ))


\markup "Only printing one category this time"

\catScores #catA 0

#(define catB (list
   #{ \time 2/3 \times 2/3 { f'4 g' a' e' } #}
   #{ \new StaffGroup <<
 \new Staff { c'8 d' e' f' e' d' c'4 } 
 \new Staff {\clef bass c4 g f e }
   >> #}
   #{  \new TabStaff { e, g b e' } #}))

printCats=
#(define-void-function (listOfCategories) (list?)
   (if (not (null? listOfCategories))
   (begin
 (add-text
  #{
   \markup\larger\larger\larger { Category #(car (car listOfCategories)) }
  #})
 (catScores (cdr (car listOfCategories)) 0)
 (printCats (cdr listOfCategories)

#(define cats (list (cons "A" catA) (cons "B" catB)))

\bookpart {
\markup "Printing all categories"
\printCats #cats
}

signature.asc
Description: This is a digitally signed message part.

Re: Workaround for (not-allowed) numbers in variable names?

[David Wright]

On Sun 07 Mar 2021 at 14:48:08 (+), Peter Toye wrote:
> The 2.22 documentation is obviously better here:
> 
> The name of a variable should not contain (ASCII) numbers, multiple 
> underscores, multiple dashes or space characters. All other characters 
> Unicode provides are allowed, for example Latin, Greek, Chinese or Cyrillic. 
> Non-adjacent single underscores and dashes are allowed, too. In other words, 
> variable names like HornIII or ???XII work.

Because Unicode is supported, one can avoid all these syntactic
complications by using any one or more of these number sets:

¹ superscripts
₂ subscripts
③ circled
⑷ parenthesised
⒌ bundled with a period
⓺ double circled

> Any combination of characters is allowed if the variable name is enclosed in 
> double quotation marks. In this case backslashes and double quotation marks 
> need to be escaped with backslashes (not that you actually should use them). 
> Examples: "foo bar", "a-b-c", "Horn 3". 

Cheers,
David.

Re: Workaround for (not-allowed) numbers in variable names?

[Peter Toye]

The 2.22 documentation is obviously better here:

The name of a variable should not contain (ASCII) numbers, multiple 
underscores, multiple dashes or space characters. All other characters Unicode 
provides are allowed, for example Latin, Greek, Chinese or Cyrillic. 
Non-adjacent single underscores and dashes are allowed, too. In other words, 
variable names like HornIII or ???XII work.

Any combination of characters is allowed if the variable name is enclosed in 
double quotation marks. In this case backslashes and double quotation marks 
need to be escaped with backslashes (not that you actually should use them). 
Examples: "foo bar", "a-b-c", "Horn 3". 

 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Re: Workaround for (not-allowed) numbers in variable names?

[Silvain Dupertuis]

Hello,

Browsing the documentation,
I did not find anything about variable names with allowing non-alphabetic 
characters.
Did I miss something?

Here are extracts the 2.20 documentation

==


 3.1.1 Introduction to the LilyPond file structure <3.1.1 Introduction to 
the
 LilyPond file structure>

Remember that you can use almost any name you like as long _/as it contains just 
alphabetic characters/_ and is distinct from LilyPond command names. For more details, see 
Saving typing with variables and functions 
<http://lilypond.org/doc/v2.20/Documentation/learning/saving-typing-with-variables-and-functions>. 
The exact limitations on variable names are detailed in File structure 
<http://lilypond.org/doc/v2.20/Documentation/notation/file-structure>.



 3.4.4 Saving typing with variables and functions
 
<http://lilypond.org/doc/v2.20/Documentation/learning/saving-typing-with-variables-and-functions.html>

does not give any indication


 3.1.5 File structure
 <http://lilypond.org/doc/v2.20/Documentation/notation/file-structure.html>

_The name of a variable should have alphabetic characters only; no numbers, underscores or 
dashes_.



 Additional note :

It's a bit difficult for me to navigate through the English documentation for me... in a 
French language environment, as I can only get it by clicking at the bottom (why not at 
the top...), and links bring me back to French (which is also nice...). But anyhow, for 
this matter, the indications are the same.


Best regards
/Silvain/

Le 07.03.21 à 12:50, Peter Toye a écrit :
Re: Workaround for (not-allowed) numbers in variable names? Yes, it's documented in the 
Notation Reference Manual section 3.1.5 File Structure. It doesn't seem the obvious 
place to put the syntax of variable names.


Best regards,

Peter
mailto:lilyp...@ptoye.com <mailto:lilyp...@ptoye.com>
www.ptoye.com <http://www.ptoye.com>

-

> Message: 4
> Date: Sat, 6 Mar 2021 21:30:56 +0900
> From: 田村淳 mailto:j.tam...@me.com>>
> To: "lilypond-user@gnu.org" mailto:lilypond-user@gnu.org>>
> Subject: Re: Workaround for (not-allowed) numbers in variable names?
> Message-ID: <mailto:a9ba3c0b-fa05-4070-9927-ea24d559e...@me.com>>

> Content-Type: text/plain; charset="utf-8"

> Wow! This is something I’ve been looking for for a long time. Is this documented 
somewhere?


> Best regards,

> Jun
> https://imslp.org/wiki/User:Jun_T 
<https://imslp.org/wiki/User:Jun_T> <https://imslp.org/wiki/User:Jun_T 
<https://imslp.org/wiki/User:Jun_T>>


>> 2021/03/06 18:09、Richard Shann mailto:rich...@rshann.plus.com>>のメール:

>> On Fri, 2021-03-05 at 10:15 -0800, Mogens Lemvig Hansen wrote:
>>> I believe it was David K who made this magic work:
>>>
>>> \version "2.20.0"
>>>
>>> mus.1 = { c d e }
>>>
>>> \score {
>>>   \new Staff { \mus.1 }
>>> }
>>>

>> This can be extended to cover the case where a variable has two numbers
>> associated with it:

>> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
>> \version "2.20.0"
>>
>> Movement.1.Staff.1 = { c d e }
>> Movement.1.Staff.2 = { c' d' e' }
>> Movement.2.Staff.1 = { f g a }
>> Movement.2.Staff.2 = { f' g' a' }
>> \score {
>>   <<
>>     \new Staff { \Movement.1.Staff.1 }
>>     \new Staff { \Movement.1.Staff.2 }
>>   >>

>> }
>> \score {
>>   <<
>>   \new Staff { \Movement.2.Staff.1 }
>>     \new Staff { \Movement.2.Staff.2 }
>>   >>

>> }

>> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

>> (cautionary note: I haven't examined the code or docs on this, but it
>> seems a dot before and after will do the trick mid-word and a single
>> dot at end of word)

>> A decade or so ago I resorted to converting all the numbers to Roman
>> numerals using a C routine that's knocking around on the interweb...
>> time I upgraded that.

>> Richard Shann



>>> Regards,
>>> Mogens
>>>
>>> From: Silvain Dupertuis
>>> Sent: March 5, 2021 10:12
>>> To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>>> Subject: Re: Workaround for (not-allowed) numbers in variable names?
>>>
>>> I also wondered why numbers are not allowed in variables.
>>> As for me, I used things like A, B, C instead... but it is less
>>> practical.
>>

Re: Workaround for (not-allowed) numbers in variable names?

[David Kastrup]

Peter Toye  writes:

> Thanks for putting me right yet again. I'm not quite sure what you
> mean by 'resized'.  q4 is surely legal?

Sure, but it's two chords, not one.

-- 
David Kastrup

Re: Workaround for (not-allowed) numbers in variable names?

[Peter Toye]

Thanks for putting me right yet again. I'm not quite sure what you mean by 
'resized'.  q4 is surely legal?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, March 7, 2021, 12:09:30 PM, David Kastrup wrote:

> Peter Toye  writes:

>> I asked this question some time ago, and David Kastrup was kind enough
>> to put me right.

>> The problem , as you mentioned, is in the way that numbers are used
>> for durations. Consider the following code:

>> chord = 
>> chord2= 

>> c1 \chord2

>> Should the second element be interpreted as 2 or 1? I
>> imagine this would confuse the lexer horribly.

> The lexer follows rules.  It's never confused.  The user is something
> different.  Incidentally, chords cannot be resized, so \chord2 would be
> interpreted as

>  2

> due to how isolated durations in music are interpreted.

>> No doubt some rules could be written to resolve this, but it would
>> need some recoding.

> Durations generally don't require space separation, like with a4 and so
> on.  Balancing conflicting desires and requirements and consistency is
> always tricky.  TeX has also chosen not to admit numbers into
> identifiers and people tend to complain it cramps their style.

Re: Workaround for (not-allowed) numbers in variable names?

[Peter Toye]

My personal view is that variables are important concepts and deserve a 
separate section somewhere - possibly 3.1.6 as a separate part of 'File 
Structure'. I note that the preceding section on markup text does not contain 
any detailed syntax definition - not even a link to the relevant section.

I'd do the mods myself, and tried to do some earlier, but  had difficulty in 
getting a Linux to work under a VM on my Windows machine. Unfortunately my 
health is a bit precarious and I can't take on any long-term projects.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, March 7, 2021, 12:34:45 PM, Werner LEMBERG wrote:


>> Yes, it's documented in the Notation Reference Manual section 3.1.5
>> File Structure.  It doesn't seem the obvious place to put the syntax
>> of variable names.

> Well, there is a proper index entry...  However, documentation for the
> 'foo.1.bar.2' trick is still missing.

> Do you have a better suggestion where this information should be
> presented in the Notation Reference?


> Werner

Re: Workaround for (not-allowed) numbers in variable names?

[Werner LEMBERG]

> Yes, it's documented in the Notation Reference Manual section 3.1.5
> File Structure.  It doesn't seem the obvious place to put the syntax
> of variable names.

Well, there is a proper index entry...  However, documentation for the
'foo.1.bar.2' trick is still missing.

Do you have a better suggestion where this information should be
presented in the Notation Reference?


Werner

Re: Workaround for (not-allowed) numbers in variable names?

[David Kastrup]

Peter Toye  writes:

> I asked this question some time ago, and David Kastrup was kind enough
> to put me right.
>
> The problem , as you mentioned, is in the way that numbers are used
> for durations. Consider the following code:
>
> chord = 
> chord2= 
>
> c1 \chord2
>
> Should the second element be interpreted as 2 or 1? I
> imagine this would confuse the lexer horribly.

The lexer follows rules.  It's never confused.  The user is something
different.  Incidentally, chords cannot be resized, so \chord2 would be
interpreted as

 2

due to how isolated durations in music are interpreted.

> No doubt some rules could be written to resolve this, but it would
> need some recoding.

Durations generally don't require space separation, like with a4 and so
on.  Balancing conflicting desires and requirements and consistency is
always tricky.  TeX has also chosen not to admit numbers into
identifiers and people tend to complain it cramps their style.

-- 
David Kastrup

Re: Workaround for (not-allowed) numbers in variable names?

[Peter Toye]

Yes, it's documented in the Notation Reference Manual section 3.1.5 File 
Structure. It doesn't seem the obvious place to put the syntax of variable 
names.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-

> Message: 4
> Date: Sat, 6 Mar 2021 21:30:56 +0900
> From: 田村淳 
> To: "lilypond-user@gnu.org" 
> Subject: Re: Workaround for (not-allowed) numbers in variable names?
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"

> Wow! This is something I’ve been looking for for a long time. Is this 
> documented somewhere?

> Best regards,

> Jun
> https://imslp.org/wiki/User:Jun_T <https://imslp.org/wiki/User:Jun_T>

>> 2021/03/06 18:09、Richard Shann のメール:

>> On Fri, 2021-03-05 at 10:15 -0800, Mogens Lemvig Hansen wrote:
>>> I believe it was David K who made this magic work:
>>>  
>>> \version "2.20.0"
>>>  
>>> mus.1 = { c d e }
>>>  
>>> \score {
>>>   \new Staff { \mus.1 }
>>> }
>>>  

>> This can be extended to cover the case where a variable has two numbers
>> associated with it:

>> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
>> \version "2.20.0"
>>  
>> Movement.1.Staff.1 = { c d e }
>> Movement.1.Staff.2 = { c' d' e' }
>> Movement.2.Staff.1 = { f g a } 
>> Movement.2.Staff.2 = { f' g' a' } 
>> \score {
>>   <<
>> \new Staff { \Movement.1.Staff.1 }
>> \new Staff { \Movement.1.Staff.2 }
>>   >>

>> }
>> \score {
>>   <<
>>   \new Staff { \Movement.2.Staff.1 }
>> \new Staff { \Movement.2.Staff.2 }
>>   >>

>> }

>> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

>> (cautionary note: I haven't examined the code or docs on this, but it
>> seems a dot before and after will do the trick mid-word and a single
>> dot at end of word)

>> A decade or so ago I resorted to converting all the numbers to Roman
>> numerals using a C routine that's knocking around on the interweb...
>> time I upgraded that.

>> Richard Shann



>>> Regards,
>>> Mogens
>>>  
>>> From: Silvain Dupertuis
>>> Sent: March 5, 2021 10:12
>>> To: lilypond-user@gnu.org
>>> Subject: Re: Workaround for (not-allowed) numbers in variable names?
>>>  
>>> I also wondered why numbers are not allowed in variables.
>>> As for me, I used things like A, B, C instead... but it is less
>>> practical.
>>>  
>>> My guess is that it may be linked to the way numbers are used in
>>> notes and chords to indicate duration, otherwise it would be real
>>> nice to be able to use digits in variable names...!
>>>  
>>> Le 05.03.21 à 17:37, stefano franchi a écrit :
>>> Here is a question for anyone who may have been using lilypond for
>>> projects involving text and many, many, short and similar musical
>>> snippets.
>>>  
>>> I am putting together a book that will contain many (very brief) 
>>> exercises, grouped thematically. I had thought a convenient and
>>> flexible way to organize the material and keep future maintenance
>>> under control would be to create top level variables names for the
>>> main musical categories and sub-categories and then assign each score
>>> snippet to progressively numbered variable. So I would have, CategA-1 
>>> = {"code for one exercise"} , CategB-2 = "code for another
>>> exercise"}, and so on. Clean structure, easy to maintain and
>>> rearrange, etc.
>>>  
>>> Then I discovered that lilypond does not allow numbers in variable
>>> names :-(
>>>  
>>> I'd be willing to bet my use case is not particularly weird---there
>>> must have been other people encountering the same problem.
>>>  
>>> How have you guys managed it?
>>>  
>>> Cheers,
>>>  
>>> S.
>>>  

>>> --
>>> __
>>> Stefano Franchi

>>> stefano.fran...@gmail.com
>>> https://www.researchgate.net/profile/Stefano_Franchi
>>>  
>>> -- 
>>> Silvain Dupertuis
>>> Route de Lausanne 335
>>> 1293 Bellevue (Switzerland)
>>> tél. +41-(0)22-774.20.67
>>> portable +41-(0)79-604.87.52
>>> web: silvain-dupertuis.org
>>>  


> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/lilypond-user/attachments/20210306/5ed2846d/attachment.html>

> --

Re: Workaround for (not-allowed) numbers in variable names?

[Peter Toye]

I asked this question some time ago, and David Kastrup was kind enough to put 
me right.

The problem , as you mentioned, is in the way that numbers are used for 
durations. Consider the following code:

chord = 
chord2= 

c1 \chord2

Should the second element be interpreted as 2 or 1? I imagine 
this would confuse the lexer horribly. No doubt some rules could be written to 
resolve this, but it would need some recoding. Easier to stick with using 
quotes.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-

> Message: 2
> Date: Fri, 5 Mar 2021 18:17:02 +0100
> From: Silvain Dupertuis 
> To: lilypond-user@gnu.org
> Subject: Re: Workaround for (not-allowed) numbers in variable names?
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"

> I also wondered why numbers are not allowed in variables.
> As for me, I used things like A, B, C instead... but it is less practical.

> My guess is that it may be linked to the way numbers are used in notes and 
> chords to 
> indicate duration, otherwise it would be real nice to be able to use digits 
> in variable 
> names...!

> Le 05.03.21 à 17:37, stefano franchi a écrit :
>> Here is a question for anyone who may have been using lilypond for projects 
>> involving 
>> text and many, many, short and similar musical snippets.

>> I am putting together a book that will contain many (very brief)  exercises, 
>> grouped 
>> thematically. I had thought a convenient and flexible way to organize the 
>> material and 
>> keep future maintenance under control would be to create top level variables 
>> names for 
>> the main musical categories and sub-categories and then assign each score 
>> snippet to 
>> progressively numbered variable. So I would have, CategA-1 = {"code for one 
>> exercise"} , 
>> CategB-2 = "code for another exercise"}, and so on. Clean structure, easy to 
>> maintain 
>> and rearrange, etc.

>> Then I discovered that lilypond does not allow numbers in variable names 
>> :-(

>> I'd be willing to bet my use case is not particularly weird---there must 
>> have been other 
>> people encountering the same problem.

>> How have you guys managed it?

>> Cheers,

>> S.


>> -- 
>> __
>> Stefano Franchi

>> stefano.fran...@gmail.com <mailto:stef...@tamu.edu>
>> /https://www.researchgate.net/profile/Stefano_Franchi/ 
>> <https://www.researchgate.net/profile/Stefano_Franchi>


> -- 
> Silvain Dupertuis
> Route de Lausanne 335
> 1293 Bellevue (Switzerland)
> tél. +41-(0)22-774.20.67
> portable +41-(0)79-604.87.52
> web: silvain-dupertuis.org <http://perso.silvain-dupertuis.org>
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/lilypond-user/attachments/20210305/88659feb/attachment.html>

> --

Re: Workaround for (not-allowed) numbers in variable names?

[David Kastrup]

田村淳  writes:

> Thank you!
>
> Now I understand that keys separated by periods, for example,
> StaffGrouper.staff-staff-spacing.basic-distance = #7
> is a way to access a nested alist easily.

Yes, and it has been like that a long time.  Being able to access it
with

\StaffGrouper.staff-staff-spacing.basic-distance

is a newer development and I am not really sure that (for this alist) it
works in contexts where you could make use of it.  For music
expressions, it does work in the basic use case.

-- 
David Kastrup

Re: Workaround for (not-allowed) numbers in variable names?

[田村淳]

Thank you!

Now I understand that keys separated by periods, for example,
StaffGrouper.staff-staff-spacing.basic-distance = #7
is a way to access a nested alist easily.

Jun

> 2021/03/07 17:26、Jean Abou Samra のメール:
> 
> Le 07/03/2021 à 03:03, 田村淳 a écrit :
> 
>> Hello David,
>> 
>>> gamme.1 is not a variable name.  It takes gamme to be an alist, and the
>>> entry under key 1 is what is addressed here.
>> Since you showed the Scheme equivalent below, I guess the above is a part of 
>> LilyPond syntax, or something the LilyPond parser does. Is that documented 
>> elsewhere? I’d like to know a bit more details.
>> 
>> Best regards,
>> 
>> Jun
> 
> Not really in an obvious place, but there is some text here:
> 
> https://lilypond.org/doc/v2.22/Documentation/notation/modifying-alists
> 
> Best,
> Jean
> 

Re: Workaround for (not-allowed) numbers in variable names?

[Jean Abou Samra]

Le 07/03/2021 à 03:03, 田村淳 a écrit :


Hello David,


gamme.1 is not a variable name.  It takes gamme to be an alist, and the
entry under key 1 is what is addressed here.

Since you showed the Scheme equivalent below, I guess the above is a part of 
LilyPond syntax, or something the LilyPond parser does. Is that documented 
elsewhere? I’d like to know a bit more details.

Best regards,

Jun


Not really in an obvious place, but there is some text here:

https://lilypond.org/doc/v2.22/Documentation/notation/modifying-alists

Best,
Jean

Re: Workaround for (not-allowed) numbers in variable names?

[田村淳]

Hello David,

> gamme.1 is not a variable name.  It takes gamme to be an alist, and the
> entry under key 1 is what is addressed here.

Since you showed the Scheme equivalent below, I guess the above is a part of 
LilyPond syntax, or something the LilyPond parser does. Is that documented 
elsewhere? I’d like to know a bit more details.

Best regards,

Jun

> 2021/03/06 23:29、David Kastrup のメール:
> 
> Silvain Dupertuis  writes:
> 
>> I still checked this use of variable with numbers.
>> *Wonderful to see that it works.*
>> 
>> One important note, though:
>> If you use a numbered variable, _you cannot use the same variable
>> without an additional number_.
> 
> gamme.1 is not a variable name.  It takes gamme to be an alist, and the
> entry under key 1 is what is addressed here.
> 
> You can equivalently write gamme . #(- 3 2) for example.
> 
> In contrast, "gamme1" (referenced as \"gamme1") _is_ a single variable
> name.
> 
> As to converting numbers to roman numerals: what is wrong with
> 
> #(format #f "~@r" 547)
> 
> ?
> 
> -- 
> David Kastrup
> 

Re: Workaround for (not-allowed) numbers in variable names?

[David Kastrup]

Silvain Dupertuis  writes:

> I still checked this use of variable with numbers.
> *Wonderful to see that it works.*
>
> One important note, though:
> If you use a numbered variable, _you cannot use the same variable
> without an additional number_.

gamme.1 is not a variable name.  It takes gamme to be an alist, and the
entry under key 1 is what is addressed here.

You can equivalently write gamme . #(- 3 2) for example.

In contrast, "gamme1" (referenced as \"gamme1") _is_ a single variable
name.

As to converting numbers to roman numerals: what is wrong with

#(format #f "~@r" 547)

?

-- 
David Kastrup

Re: Workaround for (not-allowed) numbers in variable names?

[Silvain Dupertuis]

I still checked this use of variable with numbers.
*Wonderful to see that it works.*

One important note, though:
If you use a numbered variable, _you cannot use the same variable without an additional 
number_.


*This should be added somewhere in the documentation!*


   Here is a snippet.

\version "2.20.0"

\paper { indent = 0 }

global = {
  \key g \major
}

% --- Definition of variables ---
gamme.1 = \relative c'' { r4^\markup { "major" } g4 a b c d e fis g1 }
gamme.2 = \relative c'' { r2^\markup { "minor" } g a bes c d ees fis g1 }

\markup "Numbered variables : gamme.1 and gamme.2"
\markup "Trying to define a variable named \"gamme\" will throw an error"
\score {
  {
    \global \gamme.1 \gamme.2
  }
}



Wow! This is something I’ve been looking for for a long time. Is this 
documented somewhere?


Best regards,

Jun
https://imslp.org/wiki/User:Jun_T <https://imslp.org/wiki/User:Jun_T>

2021/03/06 18:09、Richard Shann <mailto:rich...@rshann.plus.com>>のメール:


On Fri, 2021-03-05 at 10:15 -0800, Mogens Lemvig Hansen wrote:

I believe it was David K who made this magic work:

\version "2.20.0"

mus.1 = { c d e }

\score {
  \new Staff { \mus.1 }
}



This can be extended to cover the case where a variable has two numbers
associated with it:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
\version "2.20.0"

Movement.1.Staff.1 = { c d e }
Movement.1.Staff.2 = { c' d' e' }
Movement.2.Staff.1 = { f g a }
Movement.2.Staff.2 = { f' g' a' }
\score {
  <<
\new Staff { \Movement.1.Staff.1 }
\new Staff { \Movement.1.Staff.2 }
  >>

}
\score {
  <<
  \new Staff { \Movement.2.Staff.1 }
\new Staff { \Movement.2.Staff.2 }
  >>

}

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

(cautionary note: I haven't examined the code or docs on this, but it
seems a dot before and after will do the trick mid-word and a single
dot at end of word)

A decade or so ago I resorted to converting all the numbers to Roman
numerals using a C routine that's knocking around on the interweb...
time I upgraded that.

Richard Shann




Regards,
Mogens

From: Silvain Dupertuis
Sent: March 5, 2021 10:12
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
Subject: Re: Workaround for (not-allowed) numbers in variable names?

I also wondered why numbers are not allowed in variables.
As for me, I used things like A, B, C instead... but it is less
practical.

My guess is that it may be linked to the way numbers are used in
notes and chords to indicate duration, otherwise it would be real
nice to be able to use digits in variable names...!

Le 05.03.21 à 17:37, stefano franchi a écrit :
Here is a question for anyone who may have been using lilypond for
projects involving text and many, many, short and similar musical
snippets.

I am putting together a book that will contain many (very brief)
exercises, grouped thematically. I had thought a convenient and
flexible way to organize the material and keep future maintenance
under control would be to create top level variables names for the
main musical categories and sub-categories and then assign each score
snippet to progressively numbered variable. So I would have, CategA-1
= {"code for one exercise"} , CategB-2 = "code for another
exercise"}, and so on. Clean structure, easy to maintain and
rearrange, etc.

Then I discovered that lilypond does not allow numbers in variable
names :-(

I'd be willing to bet my use case is not particularly weird---there
must have been other people encountering the same problem.

How have you guys managed it?

Cheers,

S.


--
__
Stefano Franchi

stefano.fran...@gmail.com <mailto:stefano.fran...@gmail.com>
https://www.researchgate.net/profile/Stefano_Franchi

--
Silvain Dupertuis
Route de Lausanne 335
1293 Bellevue (Switzerland)
tél. +41-(0)22-774.20.67
portable +41-(0)79-604.87.52
web: silvain-dupertuis.org

Re: Workaround for (not-allowed) numbers in variable names?

[田村淳]

Wow! This is something I’ve been looking for for a long time. Is this 
documented somewhere?

Best regards,

Jun
https://imslp.org/wiki/User:Jun_T <https://imslp.org/wiki/User:Jun_T>

> 2021/03/06 18:09、Richard Shann のメール:
> 
> On Fri, 2021-03-05 at 10:15 -0800, Mogens Lemvig Hansen wrote:
>> I believe it was David K who made this magic work:
>>  
>> \version "2.20.0"
>>  
>> mus.1 = { c d e }
>>  
>> \score {
>>   \new Staff { \mus.1 }
>> }
>>  
> 
> This can be extended to cover the case where a variable has two numbers
> associated with it:
> 
> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> \version "2.20.0"
>  
> Movement.1.Staff.1 = { c d e }
> Movement.1.Staff.2 = { c' d' e' }
> Movement.2.Staff.1 = { f g a } 
> Movement.2.Staff.2 = { f' g' a' } 
> \score {
>   <<
> \new Staff { \Movement.1.Staff.1 }
> \new Staff { \Movement.1.Staff.2 }
>   >>
> 
> }
> \score {
>   <<
>   \new Staff { \Movement.2.Staff.1 }
> \new Staff { \Movement.2.Staff.2 }
>   >>
> 
> }
> 
> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> 
> (cautionary note: I haven't examined the code or docs on this, but it
> seems a dot before and after will do the trick mid-word and a single
> dot at end of word)
> 
> A decade or so ago I resorted to converting all the numbers to Roman
> numerals using a C routine that's knocking around on the interweb...
> time I upgraded that.
> 
> Richard Shann
> 
> 
> 
>> Regards,
>> Mogens
>>  
>> From: Silvain Dupertuis
>> Sent: March 5, 2021 10:12
>> To: lilypond-user@gnu.org
>> Subject: Re: Workaround for (not-allowed) numbers in variable names?
>>  
>> I also wondered why numbers are not allowed in variables.
>> As for me, I used things like A, B, C instead... but it is less
>> practical.
>>  
>> My guess is that it may be linked to the way numbers are used in
>> notes and chords to indicate duration, otherwise it would be real
>> nice to be able to use digits in variable names...!
>>  
>> Le 05.03.21 à 17:37, stefano franchi a écrit :
>> Here is a question for anyone who may have been using lilypond for
>> projects involving text and many, many, short and similar musical
>> snippets.
>>  
>> I am putting together a book that will contain many (very brief) 
>> exercises, grouped thematically. I had thought a convenient and
>> flexible way to organize the material and keep future maintenance
>> under control would be to create top level variables names for the
>> main musical categories and sub-categories and then assign each score
>> snippet to progressively numbered variable. So I would have, CategA-1 
>> = {"code for one exercise"} , CategB-2 = "code for another
>> exercise"}, and so on. Clean structure, easy to maintain and
>> rearrange, etc.
>>  
>> Then I discovered that lilypond does not allow numbers in variable
>> names :-(
>>  
>> I'd be willing to bet my use case is not particularly weird---there
>> must have been other people encountering the same problem.
>>  
>> How have you guys managed it?
>>  
>> Cheers,
>>  
>> S.
>>  
>> 
>> --
>> __
>> Stefano Franchi
>> 
>> stefano.fran...@gmail.com
>> https://www.researchgate.net/profile/Stefano_Franchi
>>  
>> -- 
>> Silvain Dupertuis
>> Route de Lausanne 335
>> 1293 Bellevue (Switzerland)
>> tél. +41-(0)22-774.20.67
>> portable +41-(0)79-604.87.52
>> web: silvain-dupertuis.org
>>  
> 

Re: Workaround for (not-allowed) numbers in variable names?

[Richard Shann]

On Fri, 2021-03-05 at 10:15 -0800, Mogens Lemvig Hansen wrote:
> I believe it was David K who made this magic work:
>  
> \version "2.20.0"
>  
> mus.1 = { c d e }
>  
> \score {
>   \new Staff { \mus.1 }
> }
>  

This can be extended to cover the case where a variable has two numbers
associated with it:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
\version "2.20.0"
 
Movement.1.Staff.1 = { c d e }
Movement.1.Staff.2 = { c' d' e' }
Movement.2.Staff.1 = { f g a } 
Movement.2.Staff.2 = { f' g' a' } 
\score {
  <<
\new Staff { \Movement.1.Staff.1 }
\new Staff { \Movement.1.Staff.2 }
  >>

}
\score {
  <<
  \new Staff { \Movement.2.Staff.1 }
\new Staff { \Movement.2.Staff.2 }
  >>

}

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

(cautionary note: I haven't examined the code or docs on this, but it
seems a dot before and after will do the trick mid-word and a single
dot at end of word)

A decade or so ago I resorted to converting all the numbers to Roman
numerals using a C routine that's knocking around on the interweb...
time I upgraded that.

Richard Shann



> Regards,
> Mogens
>  
> From: Silvain Dupertuis
> Sent: March 5, 2021 10:12
> To: lilypond-user@gnu.org
> Subject: Re: Workaround for (not-allowed) numbers in variable names?
>  
> I also wondered why numbers are not allowed in variables.
> As for me, I used things like A, B, C instead... but it is less
> practical.
>  
> My guess is that it may be linked to the way numbers are used in
> notes and chords to indicate duration, otherwise it would be real
> nice to be able to use digits in variable names...!
>  
> Le 05.03.21 à 17:37, stefano franchi a écrit :
> Here is a question for anyone who may have been using lilypond for
> projects involving text and many, many, short and similar musical
> snippets.
>  
> I am putting together a book that will contain many (very brief) 
> exercises, grouped thematically. I had thought a convenient and
> flexible way to organize the material and keep future maintenance
> under control would be to create top level variables names for the
> main musical categories and sub-categories and then assign each score
> snippet to progressively numbered variable. So I would have, CategA-1 
> = {"code for one exercise"} , CategB-2 = "code for another
> exercise"}, and so on. Clean structure, easy to maintain and
> rearrange, etc.
>  
> Then I discovered that lilypond does not allow numbers in variable
> names :-(
>  
> I'd be willing to bet my use case is not particularly weird---there
> must have been other people encountering the same problem.
>  
> How have you guys managed it?
>  
> Cheers,
>  
> S.
>  
> 
> --
> __
> Stefano Franchi
> 
> stefano.fran...@gmail.com
> https://www.researchgate.net/profile/Stefano_Franchi
>  
> -- 
> Silvain Dupertuis
> Route de Lausanne 335
> 1293 Bellevue (Switzerland)
> tél. +41-(0)22-774.20.67
> portable +41-(0)79-604.87.52
> web: silvain-dupertuis.org
>  

Re: Workaround for (not-allowed) numbers in variable names?

[Silvain Dupertuis]

Yes, it works with quotes in the variable definition as well as in the call :

/Exemple/
"gamme1" = \relative c' { g a b c d e f g }
\score { \"gamme1" }

Nice !!

Le 05.03.21 à 18:13, Kenneth Wolcott a écrit :

Thank you for asking (and answering) this question! I always wondered
about this. Now I have a solution which is better than spelling out
numbers.

Ken

On Fri, Mar 5, 2021 at 8:44 AM stefano franchi
 wrote:

Right, so I'm stupid. All it takes is to enclose the variable_with_number names 
in quotes

On Fri, Mar 5, 2021 at 10:37 AM stefano franchi  
wrote:

Here is a question for anyone who may have been using lilypond for projects 
involving text and many, many, short and similar musical snippets.

I am putting together a book that will contain many (very brief)  exercises, grouped thematically. 
I had thought a convenient and flexible way to organize the material and keep future maintenance 
under control would be to create top level variables names for the main musical categories and 
sub-categories and then assign each score snippet to progressively numbered variable. So I would 
have, CategA-1 = {"code for one exercise"} , CategB-2 = "code for another 
exercise"}, and so on. Clean structure, easy to maintain and rearrange, etc.

Then I discovered that lilypond does not allow numbers in variable names :-(

I'd be willing to bet my use case is not particularly weird---there must have 
been other people encountering the same problem.

How have you guys managed it?

Cheers,

S.


--
__
Stefano Franchi

stefano.fran...@gmail.com
https://www.researchgate.net/profile/Stefano_Franchi



--
__
Stefano Franchi

stefano.fran...@gmail.com
https://www.researchgate.net/profile/Stefano_Franchi



--
Silvain Dupertuis
Route de Lausanne 335
1293 Bellevue (Switzerland)
tél. +41-(0)22-774.20.67
portable +41-(0)79-604.87.52
web: silvain-dupertuis.org <http://perso.silvain-dupertuis.org>

Re: Workaround for (not-allowed) numbers in variable names?

[Valentin Petzel]

Hello Stefano,

You might try to keep the whole thing dynamic and leave the numbering and 
stuff to Lilypond. For example you could have just a list of all Examples in 
one Category and then have a function to print that out. You could even do a 
list of Categories and print them all at once. This way you could even manage 
your Scores anyway you want, and adding Examples to one Group requires just 
adding it to that list. See the appended File for an example.

Cheers,
ValentincatScore=
#(define-scheme-function (music number) (ly:music? number?)
   #{
 \score {
   \header {
 piece = \markup { Ex. #(number->string number) }
   }
   #music
   \layout { }
 }
   #})

addScore = #(define-void-function (score) (ly:score?) (add-score score)) 

catScores=
#(define-void-function (listOfScores i) (ly:music-list? number?)
   (if (not (null? listOfScores))
   (begin
 (add-score (catScore (car listOfScores) i))
 (catScores (cdr listOfScores) (+ i 1)
 

#(define catA (list
   #{ c'4 e'8 e' g' f' e'4 #}
   #{ d'4 4 16 16 e'8 g' d' #}
   #{ e'8 8 f' f' d' d' g4 #}))


\markup "Only printing one category this time"

\catScores #catA 1

#(define catB (list
   #{ \time 2/3 \times 2/3 { f'4 g' a' e' } #}
   #{ \new StaffGroup <<
 \new Staff { c'8 d' e' f' e' d' c'4 } 
 \new Staff {\clef bass c4 g f e }
   >> #}
   #{  \new TabStaff { e, g b e' } #}))

printCats=
#(define-void-function (listOfCategories) (list?)
   (if (not (null? listOfCategories))
   (begin
 (add-text
  #{
   \markup\larger\larger\larger { Category #(car (car listOfCategories)) }
  #})
 (catScores (cdr (car listOfCategories)) 1)
 (printCats (cdr listOfCategories)

#(define cats (list (cons "A" catA) (cons "B" catB)))

\markup "Printing all categories"

\printCats #cats

testm =\markup "test"
#(display testm)

signature.asc
Description: This is a digitally signed message part.

Re: Workaround for (not-allowed) numbers in variable names?

[Tom Brennan]

That's neat. I checked to see that unicode as well as whitespace seems to
work via quoting, too.

\version "2.22"
"rødgrød med fløde 123
和毛泽东 <<重上井冈山>>. 严永欣, 一九八八年.

久有归天愿
终过鬼门关
千里来寻归宿
春华变苍颜
到处群魔乱舞
更有妖雾盘绕
暗道入阴间
过了阎王殿
险处不须看

风雷动
旌旗奋
忆人寰
八十三年过去
弹指一挥间
中原千军逐蒋
城楼万众检阅
褒贬满载还
世上无难事
只怕我癫痫
" = { a b c }

clarinet = \new Voice {
\"rødgrød med fløde 123
和毛泽东 <<重上井冈山>>. 严永欣, 一九八八年.

久有归天愿
终过鬼门关
千里来寻归宿
春华变苍颜
到处群魔乱舞
更有妖雾盘绕
暗道入阴间
过了阎王殿
险处不须看

风雷动
旌旗奋
忆人寰
八十三年过去
弹指一挥间
中原千军逐蒋
城楼万众检阅
褒贬满载还
世上无难事
只怕我癫痫
"
}



On Fri, Mar 5, 2021, 11:45 stefano franchi 
wrote:
>
> Right, so I'm stupid. All it takes is to enclose the variable_with_number
names in quotes
>
> On Fri, Mar 5, 2021 at 10:37 AM stefano franchi 
wrote:
>>
>> Here is a question for anyone who may have been using lilypond for
projects involving text and many, many, short and similar musical snippets.
>>
>> I am putting together a book that will contain many (very brief)
 exercises, grouped thematically. I had thought a convenient and flexible
way to organize the material and keep future maintenance under control
would be to create top level variables names for the main musical
categories and sub-categories and then assign each score snippet to
progressively numbered variable. So I would have, CategA-1 = {"code for one
exercise"} , CategB-2 = "code for another exercise"}, and so on. Clean
structure, easy to maintain and rearrange, etc.
>>
>> Then I discovered that lilypond does not allow numbers in variable
names :-(
>>
>> I'd be willing to bet my use case is not particularly weird---there must
have been other people encountering the same problem.
>>
>> How have you guys managed it?
>>
>> Cheers,
>>
>> S.
>>
>>
>> --
>> __
>> Stefano Franchi
>>
>> stefano.fran...@gmail.com
>> https://www.researchgate.net/profile/Stefano_Franchi
>
>
>
> --
> __
> Stefano Franchi
>
> stefano.fran...@gmail.com
> https://www.researchgate.net/profile/Stefano_Franchi

>

RE: Workaround for (not-allowed) numbers in variable names?

[Mogens Lemvig Hansen]

I believe it was David K who made this magic work:

\version "2.20.0"

mus.1 = { c d e }

\score {
  \new Staff { \mus.1 }
}

Regards,
Mogens

From: Silvain Dupertuis
Sent: March 5, 2021 10:12
To: lilypond-user@gnu.org
Subject: Re: Workaround for (not-allowed) numbers in variable names?

I also wondered why numbers are not allowed in variables.
As for me, I used things like A, B, C instead... but it is less practical.

My guess is that it may be linked to the way numbers are used in notes and 
chords to indicate duration, otherwise it would be real nice to be able to use 
digits in variable names...!

Le 05.03.21 à 17:37, stefano franchi a écrit :
Here is a question for anyone who may have been using lilypond for projects 
involving text and many, many, short and similar musical snippets.

I am putting together a book that will contain many (very brief)  exercises, 
grouped thematically. I had thought a convenient and flexible way to organize 
the material and keep future maintenance under control would be to create top 
level variables names for the main musical categories and sub-categories and 
then assign each score snippet to progressively numbered variable. So I would 
have, CategA-1 = {"code for one exercise"} , CategB-2 = "code for another 
exercise"}, and so on. Clean structure, easy to maintain and rearrange, etc.

Then I discovered that lilypond does not allow numbers in variable names :-(

I'd be willing to bet my use case is not particularly weird---there must have 
been other people encountering the same problem.

How have you guys managed it?

Cheers,

S.


-- 
__
Stefano Franchi

stefano.fran...@gmail.com
https://www.researchgate.net/profile/Stefano_Franchi

-- 
Silvain Dupertuis
Route de Lausanne 335
1293 Bellevue (Switzerland)
tél. +41-(0)22-774.20.67
portable +41-(0)79-604.87.52
web: silvain-dupertuis.org

Re: Workaround for (not-allowed) numbers in variable names?

[Silvain Dupertuis]

I also wondered why numbers are not allowed in variables.
As for me, I used things like A, B, C instead... but it is less practical.

My guess is that it may be linked to the way numbers are used in notes and chords to 
indicate duration, otherwise it would be real nice to be able to use digits in variable 
names...!


Le 05.03.21 à 17:37, stefano franchi a écrit :
Here is a question for anyone who may have been using lilypond for projects involving 
text and many, many, short and similar musical snippets.


I am putting together a book that will contain many (very brief)  exercises, grouped 
thematically. I had thought a convenient and flexible way to organize the material and 
keep future maintenance under control would be to create top level variables names for 
the main musical categories and sub-categories and then assign each score snippet to 
progressively numbered variable. So I would have, CategA-1 = {"code for one exercise"} , 
CategB-2 = "code for another exercise"}, and so on. Clean structure, easy to maintain 
and rearrange, etc.


Then I discovered that lilypond does not allow numbers in variable names :-(

I'd be willing to bet my use case is not particularly weird---there must have been other 
people encountering the same problem.


How have you guys managed it?

Cheers,

S.


--
__
Stefano Franchi

stefano.fran...@gmail.com <mailto:stef...@tamu.edu>
/https://www.researchgate.net/profile/Stefano_Franchi/ 
<https://www.researchgate.net/profile/Stefano_Franchi>



--
Silvain Dupertuis
Route de Lausanne 335
1293 Bellevue (Switzerland)
tél. +41-(0)22-774.20.67
portable +41-(0)79-604.87.52
web: silvain-dupertuis.org <http://perso.silvain-dupertuis.org>

Re: Workaround for (not-allowed) numbers in variable names?

[Kenneth Wolcott]

Thank you for asking (and answering) this question! I always wondered
about this. Now I have a solution which is better than spelling out
numbers.

Ken

On Fri, Mar 5, 2021 at 8:44 AM stefano franchi
 wrote:
>
> Right, so I'm stupid. All it takes is to enclose the variable_with_number 
> names in quotes
>
> On Fri, Mar 5, 2021 at 10:37 AM stefano franchi  
> wrote:
>>
>> Here is a question for anyone who may have been using lilypond for projects 
>> involving text and many, many, short and similar musical snippets.
>>
>> I am putting together a book that will contain many (very brief)  exercises, 
>> grouped thematically. I had thought a convenient and flexible way to 
>> organize the material and keep future maintenance under control would be to 
>> create top level variables names for the main musical categories and 
>> sub-categories and then assign each score snippet to progressively numbered 
>> variable. So I would have, CategA-1 = {"code for one exercise"} , CategB-2 = 
>> "code for another exercise"}, and so on. Clean structure, easy to maintain 
>> and rearrange, etc.
>>
>> Then I discovered that lilypond does not allow numbers in variable names 
>> :-(
>>
>> I'd be willing to bet my use case is not particularly weird---there must 
>> have been other people encountering the same problem.
>>
>> How have you guys managed it?
>>
>> Cheers,
>>
>> S.
>>
>>
>> --
>> __
>> Stefano Franchi
>>
>> stefano.fran...@gmail.com
>> https://www.researchgate.net/profile/Stefano_Franchi
>
>
>
> --
> __
> Stefano Franchi
>
> stefano.fran...@gmail.com
> https://www.researchgate.net/profile/Stefano_Franchi

Re: Workaround for (not-allowed) numbers in variable names?

[stefano franchi]

Right, so I'm stupid. All it takes is to enclose the variable_with_number
names in quotes

On Fri, Mar 5, 2021 at 10:37 AM stefano franchi 
wrote:

> Here is a question for anyone who may have been using lilypond for
> projects involving text and many, many, short and similar musical snippets.
>
> I am putting together a book that will contain many (very brief)
> exercises, grouped thematically. I had thought a convenient and flexible
> way to organize the material and keep future maintenance under control
> would be to create top level variables names for the main musical
> categories and sub-categories and then assign each score snippet to
> progressively numbered variable. So I would have, CategA-1 = {"code for one
> exercise"} , CategB-2 = "code for another exercise"}, and so on. Clean
> structure, easy to maintain and rearrange, etc.
>
> Then I discovered that lilypond does not allow numbers in variable
> names :-(
>
> I'd be willing to bet my use case is not particularly weird---there must
> have been other people encountering the same problem.
>
> How have you guys managed it?
>
> Cheers,
>
> S.
>
>
> --
> __
> Stefano Franchi
>
> stefano.fran...@gmail.com 
> *https://www.researchgate.net/profile/Stefano_Franchi*
> <https://www.researchgate.net/profile/Stefano_Franchi>
>


-- 
__
Stefano Franchi

stefano.fran...@gmail.com 
*https://www.researchgate.net/profile/Stefano_Franchi*
<https://www.researchgate.net/profile/Stefano_Franchi>

Workaround for (not-allowed) numbers in variable names?

[stefano franchi]

Here is a question for anyone who may have been using lilypond for projects
involving text and many, many, short and similar musical snippets.

I am putting together a book that will contain many (very brief)
exercises, grouped thematically. I had thought a convenient and flexible
way to organize the material and keep future maintenance under control
would be to create top level variables names for the main musical
categories and sub-categories and then assign each score snippet to
progressively numbered variable. So I would have, CategA-1 = {"code for one
exercise"} , CategB-2 = "code for another exercise"}, and so on. Clean
structure, easy to maintain and rearrange, etc.

Then I discovered that lilypond does not allow numbers in variable
names :-(

I'd be willing to bet my use case is not particularly weird---there must
have been other people encountering the same problem.

How have you guys managed it?

Cheers,

S.


-- 
__
Stefano Franchi

stefano.fran...@gmail.com 
*https://www.researchgate.net/profile/Stefano_Franchi*
<https://www.researchgate.net/profile/Stefano_Franchi>

Re: Understanding symbol-list? variable names

[Simon Albrecht]

On 09.06.2018 01:51, Aaron Hill wrote:
By the by, I noticed a little inconsistency with the support for 
commas within symbol lists.



  \version "2.19.81"
  foo,bar = { c'4 }
  {
    \foo.bar % works
    \foo,bar % error: syntax error, unexpected ','
  }


I would have expected the original assignment to fail, but the parser 
at that point seems fine with the comma as an alternative to a period 
for defining a symbol list.  However, then, at the point of 
referencing the variable, the parser is not able to form a symbol list 
in the same manner. 


I’d be fine with that. There are two ways that symbol (or key?) lists 
are used: in a hierarchically vertical or horizontal way.

Referencing an alist value as in
\foo.bar
definitely falls into the ‘vertical’ category, while
\tagGroup score,part,vocal-score
is definitely in the ‘horizontal’ category.
The comma-separated syntax is only intended for ‘horizontal’ uses, IIUC.

Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Understanding symbol-list? variable names

[Aaron Hill]

On 2018-06-08 04:35, Urs Liska wrote:

Am 08.06.2018 um 12:43 schrieb David Kastrup:

Urs Liska  writes:

But I can do

 {
   #(#{ \my.function #})
 }

Or $#{ \my.function #} but ugh.


Could $ be extended to support something like `$\my.function` as an 
abbreviation of the above?  Granted, it would not be nearly as 
convenient as having `\my.function` work as intended.


I would like to find a smoother syntax to invoking functions like 
this

because I'd like to explore the possibility to create a namespace of
functions like \mylib.function-one, \mylib.function-two etc. But it
would only make sense if there's a really easy end-user syntax, and 
to

get there I'd have to first understand what is actually happening (in
the parser?) when \my.function is encountered.


From just the perspective of naming things, it would seem the easiest 
option is to just stick with hyphens.  Underscores appear to be valid 
for naming as well, though the potential of adding snake case to 
LilyPond's mixed world of kebab and camel might be too much for folks.


That said, the bigger idea of namespaces would be very interesting.  If 
we had some form of aliasing or prefixing of names, we could abbreviate 
the longer names needed by libraries to avoid collisions:



  \version "future"
  reallylonglibraryname-thing-one = ...
  reallylonglibraryname-thing-two = ...

  {
\namespace reallylonglibraryname {
  \thing-one ...
  \thing-two ...
}
  }


Of note, the usage above omits the hyphen as part of the prefix.  So, 
LilyPond would have to potentially insert a hyphen (or underscore) when 
resolving identifier names.  That would mean, within the scope of 
`\namespace foo`, `\xyz` would resolve as either `\fooxyz`, `\foo-xyz`, 
or `\foo_xyz`, falling back to `\xyz` should none of the alternatives be 
defined.  This could be simplified such that only hyphens are supported 
but would force a particular naming convention.


By the by, I noticed a little inconsistency with the support for commas 
within symbol lists.



  \version "2.19.81"
  foo,bar = { c'4 }
  {
\foo.bar % works
\foo,bar % error: syntax error, unexpected ','
  }


I would have expected the original assignment to fail, but the parser at 
that point seems fine with the comma as an alternative to a period for 
defining a symbol list.  However, then, at the point of referencing the 
variable, the parser is not able to form a symbol list in the same 
manner.


-- Aaron Hill

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Understanding symbol-list? variable names

[David Kastrup]

Urs Liska  writes:

> Am 08.06.2018 um 12:43 schrieb David Kastrup:
>
>> http://lilypond.org/doc/v2.19/Documentation/changes/index.html
>>
>>
>>
>>  Association list elements could previously be assigned values
>>  individually (for example, paper variables like
>>  system-system-spacing.basic-distance). They may now be also
>>  referenced in this manner, as with
>>
>>  \paper {
>>\void \displayScheme \system-system-spacing.basic-distance
>>  }
>>
>>  In combination with the previously mentioned changes, this allows
>>  setting and referencing pseudovariables like violin.1.
>
> Is that also documented *in* the references (as opposed to only in the
> changes)?

I don't think so, but neither is assignment to association list members
I think.  They were some special case once written as

variable #'field #'field = #value

and syntax

variable.field.field = #value

was introduced way before that kind of syntax was used for context
subproperties and was only useful for setting rather than retrieving.

So this is heavily un(der)documented and it doesn't help that it's not
quite clear how much more can sensibly actually be achieved here.  As
you noticed, the currently supported set is not overly consistent.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Understanding symbol-list? variable names

[Urs Liska]

Am 08.06.2018 um 12:43 schrieb David Kastrup:

Urs Liska  writes:


I can store variables with symbol-list? names like so:

\version "2.19.80"

my.note.one = { c'4 }
my.note.two = { d'2 }

{
   \my.note.one
   \my.note.two
   \my.note.one
}

It is also possible to store functions in such variables:

 my.function =
 #(define-music-function ()()
   #{ c'4 #})

However, it is not possible to *call* the function like retrieving the
value above:

 {
   \my.function
 }

yields "warning: ignoring non-music expression".

But I can do

 {
   #(#{ \my.function #})
 }

Or $#{ \my.function #} but ugh.


My impression is that "\my.function" by itself retrieves the value,
i.e. the stored function, rather than applying it, while the last
example goes around some corners to actually doing what I want.

http://lilypond.org/doc/v2.19/Documentation/changes/index.html



 Association list elements could previously be assigned values
 individually (for example, paper variables like
 system-system-spacing.basic-distance). They may now be also
 referenced in this manner, as with

 \paper {
   \void \displayScheme \system-system-spacing.basic-distance
 }

 In combination with the previously mentioned changes, this allows
 setting and referencing pseudovariables like violin.1.


Is that also documented *in* the references (as opposed to only in the 
changes)?





I would like to find a smoother syntax to invoking functions like this
because I'd like to explore the possibility to create a namespace of
functions like \mylib.function-one, \mylib.function-two etc. But it
would only make sense if there's a really easy end-user syntax, and to
get there I'd have to first understand what is actually happening (in
the parser?) when \my.function is encountered.

I'd not expect it to be.  Functions require some lookahead for being
differentiated properly in the parser (which is why we have music,
event, and scheme functions in the parser represented separately) and
the dotted syntax already burns that lookahead for its own parsing.

So don't expect it to work for invoking stuff.


OK, I see. Somehow I was afraid of that answer. And I thought I had 
found a cool thing for creating library interfaces.
However, I expect it to be (fairly easily) possible to do something 
similar with one base function and the "path" given as a separate argument:


\function path.to.stored.function { c' } "Something"

with a function stored in a regular tree structure and (in this case) 
taking a ly:music? and a string? argument.


Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Understanding symbol-list? variable names

[David Kastrup]

Urs Liska  writes:

> I can store variables with symbol-list? names like so:
>
>\version "2.19.80"
>
>my.note.one = { c'4 }
>my.note.two = { d'2 }
>
>{
>   \my.note.one
>   \my.note.two
>   \my.note.one
>}
>
> It is also possible to store functions in such variables:
>
> my.function =
> #(define-music-function ()()
>   #{ c'4 #})
>
> However, it is not possible to *call* the function like retrieving the
> value above:
>
> {
>   \my.function
> }
>
> yields "warning: ignoring non-music expression".
>
> But I can do
>
> {
>   #(#{ \my.function #})
> }

Or $#{ \my.function #} but ugh.

> My impression is that "\my.function" by itself retrieves the value,
> i.e. the stored function, rather than applying it, while the last
> example goes around some corners to actually doing what I want.

http://lilypond.org/doc/v2.19/Documentation/changes/index.html



Association list elements could previously be assigned values
individually (for example, paper variables like
system-system-spacing.basic-distance). They may now be also
referenced in this manner, as with

\paper {
  \void \displayScheme \system-system-spacing.basic-distance
}

In combination with the previously mentioned changes, this allows
setting and referencing pseudovariables like violin.1.


> I would like to find a smoother syntax to invoking functions like this
> because I'd like to explore the possibility to create a namespace of
> functions like \mylib.function-one, \mylib.function-two etc. But it
> would only make sense if there's a really easy end-user syntax, and to
> get there I'd have to first understand what is actually happening (in
> the parser?) when \my.function is encountered.

I'd not expect it to be.  Functions require some lookahead for being
differentiated properly in the parser (which is why we have music,
event, and scheme functions in the parser represented separately) and
the dotted syntax already burns that lookahead for its own parsing.

So don't expect it to work for invoking stuff.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Understanding symbol-list? variable names

[Urs Liska]

I can store variables with symbol-list? names like so:

   \version "2.19.80"

   my.note.one = { c'4 }
   my.note.two = { d'2 }

   {
  \my.note.one
  \my.note.two
  \my.note.one
   }

It is also possible to store functions in such variables:

my.function =
#(define-music-function ()()
  #{ c'4 #})

However, it is not possible to *call* the function like retrieving the 
value above:


{
  \my.function
}

yields "warning: ignoring non-music expression".

But I can do

{
  #(#{ \my.function #})
}

My impression is that "\my.function" by itself retrieves the value, i.e. 
the stored function, rather than applying it, while the last example 
goes around some corners to actually doing what I want.


I would like to find a smoother syntax to invoking functions like this 
because I'd like to explore the possibility to create a namespace of 
functions like \mylib.function-one, \mylib.function-two etc. But it 
would only make sense if there's a really easy end-user syntax, and to 
get there I'd have to first understand what is actually happening (in 
the parser?) when \my.function is encountered.


I didn't see where this (rather new) option is documented, so I'd be 
happy about any pointers or even examples.


Thanks
Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names

[David Kastrup]

"H. S. Teoh"  writes:

> On Thu, Jan 07, 2016 at 08:59:22PM +0100, Johan Vromans wrote:
>> I assume there have been discussions on extending the syntax for LP
>> identifiers to include dashes and underscores. My personal opinion is
>> that a non-alpha separator is good to have, but two different
>> separators may quickly become confusing. Is it 'set_variable' or
>> 'set-variable'?
>> 
>> Given the relation between LP and Guile, I'd suggest to only allow the
>> dash and disallow the underscore (by syntax rule, not just by
>> convention).
> [...]
>
> I think extending identifiers to include '-' and '_' is a bad idea. They
> introduce ambiguities in cases like:
>
>   c1\myCustomMarkup_"text"-\pp-\moreCustomMarkup-.

Sigh.  This is an extremely dead horse to beat.  Markups have included -
signs 10 years ago already, engravers have included _ signs 10 years ago
already.  The above is perfectly well interpreted by current LilyPond
which allows - and _ in identifier names even inside of music since
version 2.15.43 in August 2012, as of

commit 70a153b14ba32767e1ecbe680f435bdd533ae819
Author: David Kastrup 
AuthorDate: Sun Jul 29 16:05:10 2012 +0200
Commit: David Kastrup 
CommitDate: Mon Aug 6 01:28:01 2012 +0200

Unify the lexer's idea of words and commands across all modes.

A "word" (a string recognized even when not quoted) and a "command"
(something starting with \ and followed by letters and other folderol,
indicating a Scheme control sequence or similar) get the same syntax
in all modes:

A "word" is a sequence of alphabetic characters possibly containing
single dashes or underlines inside (not at the beginning or end).

A "command" is a "word" preceded by a backslash.


-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Variable names

[Johan Vromans]

I assume there have been discussions on extending the syntax for LP
identifiers to include dashes and underscores. My personal opinion is that
a non-alpha separator is good to have, but two different separators may
quickly become confusing. Is it 'set_variable' or 'set-variable'?

Given the relation between LP and Guile, I'd suggest to only allow the dash
and disallow the underscore (by syntax rule, not just by convention).

-- Johan

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names

[H. S. Teoh]

On Thu, Jan 07, 2016 at 08:59:22PM +0100, Johan Vromans wrote:
> I assume there have been discussions on extending the syntax for LP
> identifiers to include dashes and underscores. My personal opinion is
> that a non-alpha separator is good to have, but two different
> separators may quickly become confusing. Is it 'set_variable' or
> 'set-variable'?
> 
> Given the relation between LP and Guile, I'd suggest to only allow the
> dash and disallow the underscore (by syntax rule, not just by
> convention).
[...]

I think extending identifiers to include '-' and '_' is a bad idea. They
introduce ambiguities in cases like:

c1\myCustomMarkup_"text"-\pp-\moreCustomMarkup-.


T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Josiah Boothby]

Sorry to delve into this a bit late, but an earlier point in this
ongoing thread is relevant to work currently on my desk :)

On Mon, 28 Dec 2015 19:20:28 +0100
David Kastrup <d...@gnu.org> wrote:

> > flute_phrase01 =
> > flute_phrase02 =
> >
> > or similar.
> 
> When would you ever want to do that?

Actually, I've got two use cases for this loaded in my editor right
now. The first (an older, ongoing project) is a set of about 150 simple
etudes. I can use--and am using--Roman numerals. It feels like a little
bit of a cludge, but it works. The second is a bit more involved. 

I'm writing a set of accuracy training exercises that involve
simple permutations of chromatic trichords (e.g., changes of order, and
octave shifts). I'm currently using Roman numerals because there is no
reasonable concise, descriptive name of each permutation that does not
involve enumeration, and Arabic numbers are out of the question. So I
have a legend at the top of each include file describing what my
nomenclature means:

% Trichord Variable Names
% 012: A
% 013: B
% 014: C
% 015: D
% 016: E
% 024: F
% 025: G
% 026: H
% 027: I
% 036: J
% 037: K
% 048: L
% 
% Permutations: 
% Aa, Ab, Ac, Ad, etc.
% 
% Permutation Variations:
% AaI, AaII, AaIII, etc.
% 
% Respellings (enharmonic respelling for legibility):
% AaIi, AaIii, AaIiii, etc.

Now, yes, I'm sure that with a handful of hours of trying to learn
Scheme, I could probably find a way to do this that doesn't involve so
many lines of Lilypond code, but my free time to work on this
particular project is in half-hours here and there: learning enough
scheme to do this is impractical. So in the meantime, I basically have
to give each three-note motive a variable with a coded name that allows
sufficient differentiation and can be searched reasonably easily.
Variables with Arabic numerals would make these far more descriptive
and easier to read! Such as, for instance, trichord (0,1,6), in the
form and ordering of (0,11,5), enharmonic spelling version "c": 

\016_0e5-c

...instead of:

\EbIIiii  

...which is oblique and obnoxious to read. (And which I have to remind
myself not to read as "E-flat...er...major? Minor? Huh?")

Again, programming with scheme is almost definitely the correct--or at
least most efficient and elegant--approach. But for reasons of time
management for a freelance performer with next to zero programming
experience, the preparatory study requirements make this superior
approach non-pragmatic. 

Best,

Josiah

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Josiah Boothby  writes:

> Now, yes, I'm sure that with a handful of hours of trying to learn
> Scheme, I could probably find a way to do this that doesn't involve so
> many lines of Lilypond code, but my free time to work on this
> particular project is in half-hours here and there: learning enough
> scheme to do this is impractical. So in the meantime, I basically have
> to give each three-note motive a variable with a coded name that allows
> sufficient differentiation and can be searched reasonably easily.
> Variables with Arabic numerals would make these far more descriptive
> and easier to read! Such as, for instance, trichord (0,1,6), in the
> form and ordering of (0,11,5), enharmonic spelling version "c": 
>
> \016_0e5-c
>
> ...instead of:
>
> \EbIIiii  
>
> ...which is oblique and obnoxious to read. (And which I have to remind
> myself not to read as "E-flat...er...major? Minor? Huh?")

Ok, here indeed \"016_0e5-c" seems like the lesser evil (it _has_ worked
in that manner since version 2.17.28, it's just not really publicized).

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Sharon Rosner]

> > Using the syntax with quotes is rather ugly, I agree.  But it is
> > nonetheless potentially useful for two reasons:
> > (1) it enables us to use numbers etc. in variable names

> Why would that be desirable?

Suppose you make an edition of the St Matthew Passion, in which you have a
few dozen parts (two orchestras and two choirs), and ~ 70-80 numbers
(depending on how you count). Numbering everything using roman numerals
would be a bit problematic, I'd say.

> But really, \"violin1" is so much more ugly than \violinI or if you must
> \violin_I.

It's a probably a matter of taste, but I think
\"68-choir/orchestra1/violino1" is much more readable and maintainable than
\choirLXVIIIorchestraIviolinoI. Personally I use variables this way and find
it much more natural than pretending we're back to classical Rome. And since
Lilypond supports this already, I don't really get why this should be
discouraged.

Sharon Rosner




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Strings-as-variable-names-tp185113p185535.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Simon Albrecht]

On 04.01.2016 08:02, Johan Vromans wrote:

On Sun, 3 Jan 2016 21:36:30 +0100
Simon Albrecht  wrote:


No, for the simple reasons that a) noone mentioned on the list there was
a tracker item and b) even though I know now, I have been unable to
find it.

May I kindly request mentioning the URL to the list?


You’ll find the link to the Rietveld issue therein.

Ah, thanks.

I was looking in https://code.google.com/p/lilypond/issues/ ...


Yeah, well… the current issue tracker state is quite uncomfortable. We 
intended to have sourceforge only as an interim solution for some weeks’ 
transition time (that’s why it’s not documented except in the CG), but 
it didn’t at all work out to set up our own Allura server (there was 
none to do it), so it’s kind of semi-permanent.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: guileV2 and Lilypond (was: Strings as variable names)

[Menu Jacques]

Hello Paul,

Thanks a lot for the informatin and links, things are much clearer to me now.

JM

> Le 3 janv. 2016 à 20:51, Paul Morris  a écrit :
> 
>> On Jan 3, 2016, at 11:14 AM, Menu Jacques  wrote:
>> 
>> A newbie question: what are the expected benefits and challenges of moving 
>> from guile 1.8.x to guile 2.y?
> 
> As I understand it, guile 2.0 introduced significant performance 
> improvements, mainly for compiled scheme, but since LilyPond interprets 
> scheme, and the scheme interpreter in guile 2.0 is actually slower than in 
> 1.8 (but faster in 2.2 than in 2.0)  …just how much of the performance 
> benefits LilyPond will enjoy remains to be seen.
> 
> One of the immediate benefits is just keeping up with the current guile 
> version distributed with gnu/linux distributions.  They don’t want to keep 
> including guile 1.8 just for LilyPond’s sake, so LilyPond could get dropped 
> from these distributions.
> 
> But the big story is the challenges -- mainly that guile 2.0 still has bugs 
> that need to be fixed for it to work reliably with LilyPond.
> 
> I recently saw this announcement about guile 2.1.1 the "first pre-release in 
> what will become the 2.2 stable series”:
> http://savannah.gnu.org/forum/forum.php?forum_id=8397
> 
> That led me to the redesigned guile website and their mailing list, where I 
> found a post that touches on the need for better LilyPond support in guile:
> http://lists.gnu.org/archive/html/guile-devel/2015-11/msg5.html
> 
> And this follow-up post that clearly lays out the current showstopper bug: 
> http://lists.gnu.org/archive/html/guile-devel/2015-11/msg00031.html
> 
> Maybe that sheds some light on this.  Clarifications and additions welcome.
> 
> -Paul
> 
> 
> 


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Sharon Rosner]

> > And most programming languages have it.
>
> Uh what?  Bourne shells can interpolate variables (written with $ rather
> than \ by the way) into _double_-quoted strings.  Maybe some other
> shells can.

> But what _programming_ languages allow interpolating into quoted strings?

Um, let's see: Ruby, PHP, Javascript (as of ES6), Swift, Scala, C#, Perl. Ah
yes I forgot, Perl is not a _real_ programming language ;-)

Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Strings-as-variable-names-tp185113p185529.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Sun, 03 Jan 2016 21:16:27 +0100
David Kastrup  wrote:

> Johan Vromans  writes:
> > Is this going to be taken seriously or can I spare the efforts?  

> There is a tracker issue for it and some discussion. [..] Have you
> followed the discussion in the tracker?

No, for the simple reasons that a) noone mentioned on the list there was 
a tracker item and b) even though I know now, I have been unable to find it.

May I kindly request mentioning the URL to the list?

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Simon Albrecht]

On 03.01.2016 21:34, Johan Vromans wrote:

On Sun, 03 Jan 2016 21:16:27 +0100
David Kastrup  wrote:


Johan Vromans  writes:

Is this going to be taken seriously or can I spare the efforts?

There is a tracker issue for it and some discussion. [..] Have you
followed the discussion in the tracker?

No, for the simple reasons that a) noone mentioned on the list there was
a tracker item and b) even though I know now, I have been unable to find it.

May I kindly request mentioning the URL to the list?



You’ll find the link to the Rietveld issue therein.

Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Wright]

On Sun 03 Jan 2016 at 16:22:29 (+0100), David Kastrup wrote:
> David Wright  writes:
> 
> > On Mon 28 Dec 2015 at 20:27:22 (+0100), David Kastrup wrote:
> >> 
> >> The strings in Python's regular expression replacements can interpolate
> >> variable values, but those are not part of the string syntax but of the
> >> regexp replacement semantics.
> >
> > Recognising the lack of this construct, python is currently adding string
> > interpolation to the language.
> >
> > https://www.python.org/dev/peps/pep-0498/
> 
> Yes and no: you use an f prefix to such strings (for "formatted", in
> analogy to the r prefix for "raw" strings) to indicate explicitly you
> want to make use of interpolation.

Naturally—this gives you control. One of the difficulties with, for
example, bash's string interpolation ("parameter and variable expansion")
is preventing it happening when you don't want it.

> So there is no interpolation for existing strings.  It's essentially a
> lexical shorthand for Python's % formatting construct.

Existing strings? I don't understand what you mean. Python's strings
are immutable.

> At any rate, its place is in the programming language actually used for
> string manipulation, so if you want to use something like that in
> LilyPond eventually, it makes much more sense asking on the Guile user
> and/or developer list than here.
> 
> And/or try to work on the Guile 2.0 porting task of course, since
> otherwise such changes will not trickle back into LilyPond.

That's not my call.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Sun, 3 Jan 2016 21:36:30 +0100
Simon Albrecht  wrote:

> > No, for the simple reasons that a) noone mentioned on the list there was
> > a tracker item and b) even though I know now, I have been unable to
> > find it.
> >
> > May I kindly request mentioning the URL to the list?  
> 
> 
> You’ll find the link to the Rietveld issue therein.

Ah, thanks.

I was looking in https://code.google.com/p/lilypond/issues/ ...

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Wright]

On Mon 28 Dec 2015 at 20:27:22 (+0100), David Kastrup wrote:
> Johan Vromans  writes:
> 
> > On Mon, 28 Dec 2015 19:01:47 +0100
> > Urs Liska  wrote:
> >
> >> > part = cello
> >> > 
> >> > \score {
> >> >   \"bella_melodia_\part"
> >> > }
> >> 
> >> I think something like this should be achievable using a music function
> >> with two string arguments.
> >
> > Yes, but my suggestion was to have a mechanism for interpolation of
> > variables in strings, which is much more generic, flexible and
> > powerful.
> 
> The above is mainly confused.  Remember that \n in a string stands for
> newline.
> 
> > And most programming languages have it.
> 
> Uh what?  Bourne shells can interpolate variables (written with $ rather
> than \ by the way) into _double_-quoted strings.  Maybe some other
> shells can.
> 
> But what _programming_ languages allow interpolating into quoted
> strings?  The C preprocessor can expand #identifier into a string, and
> juxtaposed with other double-quoted strings they combine into a larger
> string I believe.  But that's only for preprocessor constants, and those
> are not really part of the language proper.
> 
> The strings in Python's regular expression replacements can interpolate
> variable values, but those are not part of the string syntax but of the
> regexp replacement semantics.

Recognising the lack of this construct, python is currently adding string
interpolation to the language.

https://www.python.org/dev/peps/pep-0498/

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

David Wright  writes:

> On Mon 28 Dec 2015 at 20:27:22 (+0100), David Kastrup wrote:
>> 
>> The strings in Python's regular expression replacements can interpolate
>> variable values, but those are not part of the string syntax but of the
>> regexp replacement semantics.
>
> Recognising the lack of this construct, python is currently adding string
> interpolation to the language.
>
> https://www.python.org/dev/peps/pep-0498/

Yes and no: you use an f prefix to such strings (for "formatted", in
analogy to the r prefix for "raw" strings) to indicate explicitly you
want to make use of interpolation.

So there is no interpolation for existing strings.  It's essentially a
lexical shorthand for Python's % formatting construct.

At any rate, its place is in the programming language actually used for
string manipulation, so if you want to use something like that in
LilyPond eventually, it makes much more sense asking on the Guile user
and/or developer list than here.

And/or try to work on the Guile 2.0 porting task of course, since
otherwise such changes will not trickle back into LilyPond.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Paul Morris]

> On Jan 3, 2016, at 10:06 AM, David Wright  wrote:
> 
> Recognising the lack of this construct, python is currently adding string 
> interpolation to the language.

Looks like a trend as Javascript also got it in the ECMAscript 2015 
specification:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings

I mention this only for curiosity’s sake.  "I have no dog in this race", as 
they say, and as David mentioned, LilyPond as a language is not comparable to 
Javascript, Python, Perl, etc… that would be the Scheme/Guile department.

Cheers,
-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

guileV2 and Lilypond (was: Strings as variable names)

[Menu Jacques]

Hello folks,

A happy new year 2016 to everybody!

A newbie question: what are the expected benefits and challenges of moving from 
guile 1.8.x to guile 2.y?

JM


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: guileV2 and Lilypond (was: Strings as variable names)

[Paul Morris]

> On Jan 3, 2016, at 11:14 AM, Menu Jacques  wrote:
> 
> A newbie question: what are the expected benefits and challenges of moving 
> from guile 1.8.x to guile 2.y?

As I understand it, guile 2.0 introduced significant performance improvements, 
mainly for compiled scheme, but since LilyPond interprets scheme, and the 
scheme interpreter in guile 2.0 is actually slower than in 1.8 (but faster in 
2.2 than in 2.0)  …just how much of the performance benefits LilyPond will 
enjoy remains to be seen.

One of the immediate benefits is just keeping up with the current guile version 
distributed with gnu/linux distributions.  They don’t want to keep including 
guile 1.8 just for LilyPond’s sake, so LilyPond could get dropped from these 
distributions.

But the big story is the challenges -- mainly that guile 2.0 still has bugs 
that need to be fixed for it to work reliably with LilyPond.

I recently saw this announcement about guile 2.1.1 the "first pre-release in 
what will become the 2.2 stable series”:
http://savannah.gnu.org/forum/forum.php?forum_id=8397

That led me to the redesigned guile website and their mailing list, where I 
found a post that touches on the need for better LilyPond support in guile:
http://lists.gnu.org/archive/html/guile-devel/2015-11/msg5.html

And this follow-up post that clearly lays out the current showstopper bug: 
http://lists.gnu.org/archive/html/guile-devel/2015-11/msg00031.html

Maybe that sheds some light on this.  Clarifications and additions welcome.

-Paul




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 20:28:58 +0100
Johan Vromans  wrote:

> NR refers to
> http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
> which does not mention the quoted syntax, and explicitly disallows dashes
> and underscores.
> 
> === Suggested replacement text ===
> ...
> === end of suggestion ===

Is this going to be taken seriously or can I spare the efforts?

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 20:28:58 +0100
> Johan Vromans  wrote:
>
>> NR refers to
>> http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
>> which does not mention the quoted syntax, and explicitly disallows dashes
>> and underscores.
>> 
>> === Suggested replacement text ===
>> ...
>> === end of suggestion ===
>
> Is this going to be taken seriously or can I spare the efforts?

There is a tracker issue for it and some discussion.  The current state
is somewhat misleading as well as inconsistent, so change is desirable.
There does not seem to be a high level of excitement for fixing this
among those who discussed it.  That makes it likely that any action will
take a while before the topic reaches the top of the importance list for
any of the usual suspects.  Have you followed the discussion in the
tracker?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Kieren MacMillan]

Hi David,

> the name define-music-function renders the "Extending LilyPond”
> guide ineligible for the Nobel Prize in Literature.

Oh, is *that* what’s keeping us out of the running??  :)

Thanks for the giggle!
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: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 23:04:37 +0100
> David Kastrup  wrote:
>
>> You conveniently snipped shells so that you could mention them again.
>
> You can find a lot more on
> https://en.wikipedia.org/wiki/String_interpolation

About a third of the examples are not even string interpolation but
format-like functions.  Probably because people wanted to see their
favorite programming language mentioned in spite of it not qualifying.
Of course Guile/LilyPond can work with format.

> The point is, is it something we would want (i.e., is useful) in
> LilyPond?

We already have `format' and other string operations.  I don't see that
it makes sense to try outdoing Scheme in matters that are not really in
LilyPond's domain.  We have deprecated/undocumented/removed several of
LilyPond's "native" constructs for forming expressions from ordinary
Scheme data because there is no point in having everything twice.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Simon Albrecht  writes:

> To just give my personal opinion, it would be brilliant to have
>
> (define (foo arg) )
> (define-music-function (foo arg) (arg-type?) )
> []
> (define-markup-command (foo arg) (arg-type?) )

I don't share your sentiments here.  Now define-music-function is
arguably misnamed as it is more of a music-lambda rather than something
fitting into the "define" category.  But between define-markup-command
and define-music-function, the latter has by far the cleanest semantics
even if its name does not fit them.

I'm more interested in merging all define-*-function commands
eventually, making them decide their syntactical function based on their
return value type.  However, that's non-trivial mainly because of

\displayMusic c'4 \displayMusic -.

Here LilyPond does not know that the second expression is (as a
post-event) to be a part of the c'4 before it has evaluated it.  So the
\displayMusic expressions would need to be evaluated right from left,
displaying first "-." and then "c'4-.".

But before the right expression is evaluated, its type is unknown, so

\displayMusic c'4 \displayMusic d'4

would also need to be evaluated right to left, displaying first "d'4"
and then "c'4".  Which is clearly less than desirable.

So something has to give.

> Not only would it be more consistent on the surface, it would also
> have less potential for confusion upon learning.

Frankly, I rather doubt those are the showstoppers.  Markup commands are
pretty much a pest.  Joining them with markup list commands would be a
good first step for cleaning up that can of worms.

Music functions are rather easy to work with in comparison, even if the
name define-music-function renders the "Extending LilyPond" guide
ineligible for the Nobel Prize in Literature.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Simon Albrecht]

On 28.12.2015 23:35, David Kastrup wrote:

Simon Albrecht  writes:


On 28.12.2015 20:28, Johan Vromans wrote:

NR refers to
http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
which does not mention the quoted syntax, and explicitly disallows dashes

Ugh, that’s bad.
Especially since it’s an important feature in interlocking Scheme and
LilyPond code. Mind you, I’ve even think it might be better to use the
scheme naming convention lowercase-with-dashes everywhere in LilyPond
code.

Nope.  Far too large collision potential with preexisting Scheme
identifiers.  Often the underlying Scheme functions for some music
function are named the same, just with dashes instead of CamelCase.


I’m not saying we should introduce this the day after tomorrow, nor that 
it would be easy.





To be discussed when GLISS finally will get on the table again…

To me, the main motivation for changes in syntax is making things work
better or more consistently.


Another motivation might be to make it easier to use and/or understand.


   Unifying LilyPond's idea of valid
identifier syntax across modes made a number of things work more
reliably and removed strange errors and quirks.  But that the
conventions are no longer brutally enforced by LilyPond does not render
them useless.


True. Once again I have been to rash in my conclusions. Two things 
started my reasoning:

– Using camelCase identifiers in Scheme doesn’t look good
– and I’d like if the naming conventions reflected the complete 
interchangeability of variables defined in either LilyPond or Scheme 
syntax, to promote awareness of this useful feature.
For me, lowercase-with-dashes is also more comfortable to type than 
camelcaseWithoutDashes – just a sidenote, and might be different for 
everybody else. But even such radically practical reasons should be 
considered IMO.


There are more things contributing to my unease (excuse going off the 
original topic): one is Frescobaldi’s auto-completion separating 
LilyPond- and Scheme-defined identifiers (which should be fixable – 
).

The other is the inconsistency between

(define (foo arg) )
foo = (define-music-function (arg) (arg-type?) )
[same for scheme, event, and void functions]
(define-markup-command (foo layout props arg) (arg-type?) )

To just give my personal opinion, it would be brilliant to have

(define (foo arg) )
(define-music-function (foo arg) (arg-type?) )
[]
(define-markup-command (foo arg) (arg-type?) )

(The latter would need the like of issue 4422 on markup commands, but 
don’t feel pressed on that matter! Should I open an enhancement request?)


Not only would it be more consistent on the surface, it would also have 
less potential for confusion upon learning.


Interested to hear your opinions,
Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 21:39:05 +0100 (CET)
Werner LEMBERG  wrote:

> I suggest to use the m4 preprocessor
> [https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,

Yikes. Speaking of overkill...

> say, `violin1' to `violinI'.  Add the line
> 
>   define(`violin1', `violinI')

This will happily change violin12 to violinI2, etc., probably not what you
want.

m4 is not for the faint of the heart.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 12:05:22 +1100
> Andrew Bernard  wrote:
>
>> The name of a variable must have alphabetic characters only, no numbers,
>> underscores, or dashes.
>> 
>> Most lilypond users would write bellaMelodia, conventionally. In terms of
>> readability, it’s clearer to read than the string with quotes, I reckon.
>
> They would write bellaMelodia since there is (was) no alternative to
> separate "words" in a variable name. 2.19.33 seems to accept dashes and
> underscores as well. Maybe the NR needs updating?

The quote character syntax was issue 2931.  The change was for 2.18 but
not mentioned in the Changes file.  Single, in-word occurences of - and
_ were allowed for 2.16 already, issue 2702.  It was mentioned in
Changes at that time.  I think that some other documentation was changed
as well but am not sure how completely.

The quote syntax is a bit of an ugliness which was added for sort-of
consistency reasons.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Andrew Bernard]

Consistency with what actually?

And so the NR should in fact therefore be updated?

Andrew

On 28/12/2015, 20:17, "David Kastrup" 
 wrote:

The quote syntax is a bit of an ugliness which was added for sort-of
consistency reasons.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Andrew Bernard  writes:

>  d...@gnu.org> wrote:
>>
>> The quote syntax is a bit of an ugliness which was added for sort-of
>> consistency reasons.
>
> Consistency with what actually?

After

xxx = ...

you can refer to \xxx.  And

"xxx" = ...

has always been allowed for arbitrary strings.

> And so the NR should in fact therefore be updated?

It's not really making stuff more readable.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 12:51:51 +0100
David Kastrup  wrote:

> "xxx" = ...
> 
> has always been allowed for arbitrary strings.
> 
> > And so the NR should in fact therefore be updated?  
> 
> It's not really making stuff more readable.

Now if only this would work:

\version "2.19.33"

bella_melodia_cello = \relative c' {
   r4- ef\upbow(f) r g |
}

part = cello

\score {
  \"bella_melodia_\part"
}

I can think of some use cases for this.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

David Sumbler <da...@aeolia.co.uk> writes:

>> > From: David Kastrup <d...@gnu.org>
>> > To: Andrew Bernard <andrew.bern...@gmail.com>
>> > Cc: lilypond-user@gnu.org
>> > Subject: Re: Strings as variable names
>> > Date: Mon, 28 Dec 2015 12:51:51 +0100
>> > 
>> > Andrew Bernard <andrew.bern...@gmail.com> writes:
>> > 
>> > > <lilypond-user-bounces+andrew.bernard=gmail@gnu.org on
>> > > behalf of d...@gnu.org> wrote:
>> > >>
>> > >> The quote syntax is a bit of an ugliness which was added for sort-of
>> > >> consistency reasons.
>> > >
>> > > Consistency with what actually?
>> > 
>> > After
>> > 
>> > xxx = ...
>> > 
>> > you can refer to \xxx.  And
>> > 
>> > "xxx" = ...
>> > 
>> > has always been allowed for arbitrary strings.
>> > 
>> > > And so the NR should in fact therefore be updated?
>> > 
>> > It's not really making stuff more readable.
>
> I think it would be useful to have it added to the NR.
>
> I have always been frustrated by the fact that I can't (or thought I
> couldn't) use underscores in variable names,

Well, that is hopefully more or less documented though probably not
everywhere.

> and also that numbers are not allowed.

But really, \"violin1" is so much more ugly than \violinI or if you must
\violin_I.

> Using the syntax with quotes is rather ugly, I agree.  But it is
> nonetheless potentially useful for two reasons:
> (1) it enables us to use numbers etc. in variable names

Why would that be desirable?

> (2) the quotes help to distinguish our own defined variables from
> Lilypond's own.

Absolutely not.  The quote marks don't become part of the variables or
identifiers.  \bing is absolutely identical to \"bing".

Reading people's ideas about those things make them appear like
something we would be better without.  They only lead to confusion.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Sumbler]

> > From: David Kastrup <d...@gnu.org>
> > To: Andrew Bernard <andrew.bern...@gmail.com>
> > Cc: lilypond-user@gnu.org
> > Subject: Re: Strings as variable names
> > Date: Mon, 28 Dec 2015 12:51:51 +0100
> > 
> > Andrew Bernard <andrew.bern...@gmail.com> writes:
> > 
> > > <lilypond-user-bounces+andrew.bernard=gmail@gnu.org on behalf of 
> > > d...@gnu.org> wrote:
> > >>
> > >> The quote syntax is a bit of an ugliness which was added for sort-of
> > >> consistency reasons.
> > >
> > > Consistency with what actually?
> > 
> > After
> > 
> > xxx = ...
> > 
> > you can refer to \xxx.  And
> > 
> > "xxx" = ...
> > 
> > has always been allowed for arbitrary strings.
> > 
> > > And so the NR should in fact therefore be updated?
> > 
> > It's not really making stuff more readable.

I think it would be useful to have it added to the NR.

I have always been frustrated by the fact that I can't (or thought I
couldn't) use underscores in variable names, and also that numbers are
not allowed.

Using the syntax with quotes is rather ugly, I agree.  But it is
nonetheless potentially useful for two reasons:
(1) it enables us to use numbers etc. in variable names
(2) the quotes help to distinguish our own defined variables from
Lilypond's own.

David


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Urs Liska]

Am 28.12.2015 um 13:29 schrieb Johan Vromans:
> On Mon, 28 Dec 2015 12:51:51 +0100
> David Kastrup  wrote:
> 
>> "xxx" = ...
>>
>> has always been allowed for arbitrary strings.
>>
>>> And so the NR should in fact therefore be updated?  
>>
>> It's not really making stuff more readable.
> 
> Now if only this would work:
> 
> \version "2.19.33"
> 
> bella_melodia_cello = \relative c' {
>r4- ef\upbow(f) r g |
> }
> 
> part = cello
> 
> \score {
>   \"bella_melodia_\part"
> }
> 
> I can think of some use cases for this.

I think something like this should be achievable using a music function
with two string arguments. It could concatenate them in an arbitrary
fashion and find the appropriate variable through the parser commands.

Urs

> 
> -- Johan
>http://johan.vromans.org/seasons_greetings.html
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


-- 
Urs Liska
www.openlilylib.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Urs Liska <u...@openlilylib.org> writes:

> Am 28.12.2015 um 18:49 schrieb David Kastrup:
>>> Using the syntax with quotes is rather ugly, I agree.  But it is
>>> > nonetheless potentially useful for two reasons:
>>> > (1) it enables us to use numbers etc. in variable names
>> Why would that be desirable?
>> 
>
> Whenever you have variables pointing to indexed parts or to consecutive
> snippets you may want to use variables like
>
> violin1 =
> violin2 =

What's wrong with violinI ?

> or
>
> flute_phrase01 =
> flute_phrase02 =
>
> or similar.

When would you ever want to do that?

> This is expressive as LilyPond code per se, and would be accessible
> for scripting, e.g. to generate stub files with empty varialbes.

Why would violinI not be accessible for scripting?

That's just (format #f "violin~@r" 1).

> The workaround using roman numbers is pretty cumbersome,

What's this with "workaround" anyway?  I have more scores using
"Violin I" and "Violin II" for their parts than otherwise.

Here are the instrument names of literally the first score I found on my
desktop:


> and I think
>
> violin_02_34 would be much more comprehensible to most users than
> violinIIxxxiv

34 separate second violins seem a bit excessive.

-- 
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Urs Liska]

Am 28.12.2015 um 18:49 schrieb David Kastrup:
>> Using the syntax with quotes is rather ugly, I agree.  But it is
>> > nonetheless potentially useful for two reasons:
>> > (1) it enables us to use numbers etc. in variable names
> Why would that be desirable?
> 

Whenever you have variables pointing to indexed parts or to consecutive
snippets you may want to use variables like

violin1 =
violin2 =

or

flute_phrase01 =
flute_phrase02 =

or similar.
This is expressive as LilyPond code per se, and would be accessible for
scripting, e.g. to generate stub files with empty varialbes.

The workaround using roman numbers is pretty cumbersome, and I think

violin_02_34 would be much more comprehensible to most users than
violinIIxxxiv

-- 
Urs Liska
www.openlilylib.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Marc Hohl]

Am 28.12.2015 um 18:49 schrieb David Kastrup:

David Sumbler <da...@aeolia.co.uk> writes:

[...]

Using the syntax with quotes is rather ugly, I agree.  But it is
nonetheless potentially useful for two reasons:
(1) it enables us to use numbers etc. in variable names


Why would that be desirable?


Well, speaking just for myself, I use roman numerals in \textI, \textII, 
... \textVII which is rather clumsy and error-prone

(IV versus VI etc.)

This is just a convenience factor, but \text1 ... \text7 would be
nice, but I see that this leads to major problems in terms of
durations vs. variable calls.

Just my 2 cents,

Marc


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 20:27:22 +0100
> David Kastrup  wrote:
>
>> The above is mainly confused.  Remember that \n in a string stands for
>> newline.
>
> So there's already some kind of processing done. \{varname} would be an
> alternative.
>
> But it is just a suggestion.
>
>> But what _programming_ languages allow interpolating into quoted
>> strings?
>
> Most dynamic languages like Bash, Perl, JavaScript, ...

You conveniently snipped shells so that you could mention them again.
Perl has gobbled up every syntax from all traditional UNIX utilities
anyway so that does not really count.

JavaScript does not appear to do variable interpolation into string
literals

as far as I can see.

That's a far cry from "most programming languages".  It's not even "most
dynamic languages".  It's shells and Perl.  Arguably Cpp though it's not
a programming language of its own.  Make knows $x but does not really
work with quoted strings.  Awk knows $x but not inside quoted strings.
M4 does not work with quoted strings but will expand recognizable
identifiers in at most one level of [...].  But it's not a programming
language.

Maybe Tcl?  Would seem consistent with its history but I don't know it.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Simon Albrecht  writes:

> On 28.12.2015 20:28, Johan Vromans wrote:
>> NR refers to
>> http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
>> which does not mention the quoted syntax, and explicitly disallows dashes
>
> Ugh, that’s bad.
> Especially since it’s an important feature in interlocking Scheme and
> LilyPond code. Mind you, I’ve even think it might be better to use the
> scheme naming convention lowercase-with-dashes everywhere in LilyPond
> code.

Nope.  Far too large collision potential with preexisting Scheme
identifiers.  Often the underlying Scheme functions for some music
function are named the same, just with dashes instead of CamelCase.

> To be discussed when GLISS finally will get on the table again…

To me, the main motivation for changes in syntax is making things work
better or more consistently.  Unifying LilyPond's idea of valid
identifier syntax across modes made a number of things work more
reliably and removed strange errors and quirks.  But that the
conventions are no longer brutally enforced by LilyPond does not render
them useless.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 21:39:05 +0100 (CET)
> Werner LEMBERG  wrote:
>
>> I suggest to use the m4 preprocessor
>> [https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,
>
> Yikes. Speaking of overkill...
>
>> say, `violin1' to `violinI'.  Add the line
>> 
>>   define(`violin1', `violinI')
>
> This will happily change violin12 to violinI2, etc., probably not what you
> want.

File: m4.info,  Node: Names,  Next: Quoted strings,  Up: Syntax

3.1 Macro names
===

A name is any sequence of letters, digits, and the character '_'
(underscore), where the first character is not a digit.  'm4' will use
the longest such sequence found in the input.

So, no.

> m4 is not for the faint of the heart.

It's not as bad as you want to paint it.  It would not be my choice of
tool here nevertheless.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Johan Vromans  writes:

> On Mon, 28 Dec 2015 19:01:47 +0100
> Urs Liska  wrote:
>
>> > part = cello
>> > 
>> > \score {
>> >   \"bella_melodia_\part"
>> > }
>> 
>> I think something like this should be achievable using a music function
>> with two string arguments.
>
> Yes, but my suggestion was to have a mechanism for interpolation of
> variables in strings, which is much more generic, flexible and
> powerful.

The above is mainly confused.  Remember that \n in a string stands for
newline.

> And most programming languages have it.

Uh what?  Bourne shells can interpolate variables (written with $ rather
than \ by the way) into _double_-quoted strings.  Maybe some other
shells can.

But what _programming_ languages allow interpolating into quoted
strings?  The C preprocessor can expand #identifier into a string, and
juxtaposed with other double-quoted strings they combine into a larger
string I believe.  But that's only for preprocessor constants, and those
are not really part of the language proper.

The strings in Python's regular expression replacements can interpolate
variable values, but those are not part of the string syntax but of the
regexp replacement semantics.

And so on.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[David Kastrup]

Malte Meyn <lilyp...@maltemeyn.de> writes:

> Am 28.12.2015 um 19:20 schrieb David Kastrup:
>> What's wrong with violinI ?
>
> lexicographical sorting (of file names) ≠ roman numeral sorting

File names are not variable names.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 17:42:03 +
David Sumbler  wrote:

> > > It's not really making stuff more readable.  
> 
> I think it would be useful to have it added to the NR.

If it's part of the language syntax, it should be documented.
If it's experimental, dangerous, or deprecated, it should be documented as
such.
If it is unwanted, it should be removed from the language syntax.

There's no point in having undocumented language features, because these
will only lead to errors and confusion.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Malte Meyn]

Am 28.12.2015 um 19:20 schrieb David Kastrup:
> What's wrong with violinI ?

lexicographical sorting (of file names) ≠ roman numeral sorting

>> flute_phrase01 =
>> flute_phrase02 =
>>
>> or similar.
> 
> When would you ever want to do that?

Variations (one score per variation):

fluteTheme = …
fluteVar1 = …
…
fluteVar14 = …

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Werner LEMBERG]

> Reading people's ideas about those things make them appear like
> something we would be better without.  They only lead to confusion.

+1


Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Thomas Morley]

2015-12-28 18:49 GMT+01:00 David Kastrup :
[...]
>
> Reading people's ideas about those things make them appear like
> something we would be better without.  They only lead to confusion.
>
> --
> David Kastrup

I rarely use this possibility, but it's very nice to have numbers, etc
in identifiers for things like:

"des:7.5+.9+" =
\markup {
  \fret-diagram-verbose #`(
(mute 6)
(place-fret 5 7 ,#{ \markup \fontsize #-4 3 #})
(place-fret 4 8 ,#{ \markup \fontsize #-4 \with-flat 7 #})
(place-fret 3 8 ,#{ \markup \fontsize #-4 \with-sharp 9 #})
(place-fret 2 9 ,#{ \markup \fontsize #-4 \with-sharp 5 #})
(mute 1)
  )
}

\with-flat is a custom-markup-command outputting nice formatted "b7"

Wouldn't want to miss it.


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 19:01:47 +0100
Urs Liska  wrote:

> > part = cello
> > 
> > \score {
> >   \"bella_melodia_\part"
> > }
> 
> I think something like this should be achievable using a music function
> with two string arguments.

Yes, but my suggestion was to have a mechanism for interpolation of
variables in strings, which is much more generic, flexible and powerful.
And most programming languages have it.

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 18:49:30 +0100
David Kastrup <d...@gnu.org> wrote:

> > I have always been frustrated by the fact that I can't (or thought I
> > couldn't) use underscores in variable names,  
> 
> Well, that is hopefully more or less documented though probably not
> everywhere.

NR refers to
http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
which does not mention the quoted syntax, and explicitly disallows dashes
and underscores.

=== Suggested replacement text ===

The name of a variable must consist of alphabetic characters, underscores
and dashes. Underscores and dashes must always follow and be followed by an
alphabetic character. Also, the name of a variable may not be one of
LilyPond's predefined keywords.

These are valid variable names:

pieceIV
myMusic
alternate-one
big_loud_part

Examples of invalid names:

piece4 (numbers not allowed)
-my-Music (leading dash)
alternate--one (more than one consecutive dash)
example_ (ends with underscore)

A variable name may be enclosed in double quotes, e.g. "pieceIV" is
the same as pieceIV. When using quotes, the name may consist of any
sequence of characters. For example "My New Music Piece 14²" is a valid
variable but there is no quote-less way to refer to it.

"My New Music Piece 14²" = \new Staff {
  \relative {
a'4 b c b
  }
}

{
  <<
\"My New Music Piece 14²"
  >>
}

=== end of suggestion ===

> But really, \"violin1" is so much more ugly than \violinI or if you must
> \violin_I.

Let's consider this a matter of taste...

BTW, you can use unicode characters including numerals ☺ .

bella_melódia-① = { ... }

-- Johan
   http://johan.vromans.org/seasons_greetings.html


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Werner LEMBERG]

> Whenever you have variables pointing to indexed parts or to
> consecutive snippets you may want to use variables like
>
> violin1 =
> violin2 =
>
> or
>
> flute_phrase01 =
> flute_phrase02 =
>
> or similar.  This is expressive as LilyPond code per se, and would
> be accessible for scripting, e.g. to generate stub files with empty
> varialbes.
>
> The workaround using roman numbers is pretty cumbersome, and I think
>
> violin_02_34 would be much more comprehensible to most users than
> violinIIxxxiv

I suggest to use the m4 preprocessor
[https://en.wikipedia.org/wiki/M4_(computer_language)] to convert,
say, `violin1' to `violinI'.  Add the line

  define(`violin1', `violinI')

at the very beginning of your input file, then run

  m4 < infile > outfile


 Werner

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Kieren MacMillan]

Hi David,

> What's wrong with violinI ?

For one thing, arabic numerals sort more easily than roman numerals.

> When would you ever want to do that?

Unfortunately, I need to do it all the time: until Lilypond handles 
multi-instrumentalist parts better than it does (you may recall us discussing 
the many issues in the past?), I am forced to break up variables and then knit 
them back together later [transposed, or with a new key signature, or whatever].

> What's this with "workaround" anyway?  I have more scores using
> "Violin I" and "Violin II" for their parts than otherwise.

Instrument names [presentation] and variable names [content] are independent… 
or at least should be.

Best regards,
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: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 20:27:22 +0100
David Kastrup  wrote:

> The above is mainly confused.  Remember that \n in a string stands for
> newline.

So there's already some kind of processing done. \{varname} would be an
alternative.

But it is just a suggestion.

> But what _programming_ languages allow interpolating into quoted
> strings?

Most dynamic languages like Bash, Perl, JavaScript, ...

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Simon Albrecht]

On 28.12.2015 20:28, Johan Vromans wrote:

NR refers to
http://www.lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
which does not mention the quoted syntax, and explicitly disallows dashes


Ugh, that’s bad.
Especially since it’s an important feature in interlocking Scheme and 
LilyPond code. Mind you, I’ve even think it might be better to use the 
scheme naming convention lowercase-with-dashes everywhere in LilyPond 
code. To be discussed when GLISS finally will get on the table again…


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Malte Meyn]

Am 28.12.2015 um 20:30 schrieb David Kastrup:
> Malte Meyn <lilyp...@maltemeyn.de> writes:
> 
>> Am 28.12.2015 um 19:20 schrieb David Kastrup:
>>> What's wrong with violinI ?
>>
>> lexicographical sorting (of file names) ≠ roman numeral sorting
> 
> File names are not variable names.
> 

That’s true. I just don’t like to have two different naming schemes
(horn4.pdf contains hornIV) where it’s not really necessary ...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 23:52:27 +0100
David Kastrup  wrote:

> So, no.

I stand corrected.
It's a very long since ago that I stopped using m4.

> It would not be my choice of tool here nevertheless.

Preprocessors in general add the disadvantage of having unmaintainable
sources (you cannot edit the unprocessed source with e.g. frescobaldi
without trickery) and hard to find errors (line/column numbers may change).

For the purpose discussed here (using something better than violinI) it is
definitely not the best tool.

-- Johan

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 23:04:37 +0100
David Kastrup  wrote:

> You conveniently snipped shells so that you could mention them again.

You can find a lot more on
https://en.wikipedia.org/wiki/String_interpolation

But does it really matter?

The point is, is it something we would want (i.e., is useful) in LilyPond?

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Strings as variable names

[Menu Jacques]

Hello folks,

I’ve found that one can write the following:

\version "2.19.33"

"bella melodia" = \relative c' {
   r4- ef\upbow(f) r g |
}

\score {
  \"bella melodia"
}


but I couldn’t find such a possibility in the 2.19.31 Notation Reference, even 
though that may be useful.

Does anyone know more about this?

JM



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Andrew Bernard]

Hi Jacques,

Well, the NR states:

The name of a variable must have alphabetic characters only, no numbers, 
underscores, or dashes.

That excludes spaces explicitly. The fact that you can use a quoted string is 
undocumented and may therefore become unsupported at any time. In Scheme, you 
cannot have strings as variable identifiers. I would be disinclined to move too 
far away from Scheme syntax, even though lilypond may allow it.

Most lilypond users would write bellaMelodia, conventionally. In terms of 
readability, it’s clearer to read than the string with quotes, I reckon.

Andrew



On 27/12/2015, 20:30, "Menu Jacques" 
 wrote:

\score {
  \"bella melodia"
}


but I couldn’t find such a possibility in the 2.19.31 Notation Reference, even 
though that may be useful.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strings as variable names

[Johan Vromans]

On Mon, 28 Dec 2015 12:05:22 +1100
Andrew Bernard  wrote:

> The name of a variable must have alphabetic characters only, no numbers,
> underscores, or dashes.
> 
> Most lilypond users would write bellaMelodia, conventionally. In terms of
> readability, it’s clearer to read than the string with quotes, I reckon.

They would write bellaMelodia since there is (was) no alternative to
separate "words" in a variable name. 2.19.33 seems to accept dashes and
underscores as well. Maybe the NR needs updating?

-- Johan
   http://johan.vromans.org/seasons_greetings.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names?

[Christopher R. Maden]

On 11/18/2012 05:26 PM, David Kastrup wrote:

At the current point of time, the rule is that alphabetic is a-z,
A-Z, and _any_ non-ASCII character.  This is a bit excessive, but
short of a reliable is a letter test, this was easiest to
implement.


Getting off-topic for -user, but...  Most programming languages that can 
process Unicode text have class tests that should simplify letter-ness. 
 (The superscript characters ¹²³ etc. do not have this property.) 
Guile has the char-alphabetic? predicate; see URL: 
https://www.gnu.org/software/guile/manual/html_node/Characters.html , 
at least as of 2.0.


~Chris
--
Chris Maden, text nerd  URL: http://crism.maden.org/ 
 “Always remember where you came from, and honor your ancestry,
  But don’t be afraid to defy anyone who would tell you what to be.”
  — Chris Vaughan, “Freedom”
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names?

[David Kastrup]

Christopher R. Maden cr...@maden.org writes:

 On 11/18/2012 05:26 PM, David Kastrup wrote:
 At the current point of time, the rule is that alphabetic is a-z,
 A-Z, and _any_ non-ASCII character.  This is a bit excessive, but
 short of a reliable is a letter test, this was easiest to
 implement.

 Getting off-topic for -user, but...  Most programming languages that
 can process Unicode text have class tests that should simplify
 letter-ness. (The superscript characters ¹²³ etc. do not have this
 property.) Guile has the char-alphabetic? predicate; see URL:
 https://www.gnu.org/software/guile/manual/html_node/Characters.html ,
 at least as of 2.0.

We are not using Guile 2.0 yet, and I doubt people would be happy about
an undiscussed change once we do.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names?

[Wim van Dommelen]

On 19 Nov 2012, at 22:16 , David Kastrup wrote:


Christopher R. Maden cr...@maden.org writes:


On 11/18/2012 05:26 PM, David Kastrup wrote:

At the current point of time, the rule is that alphabetic is a-z,
A-Z, and _any_ non-ASCII character.  This is a bit excessive, but
short of a reliable is a letter test, this was easiest to
implement.


Getting off-topic for -user, but...  Most programming languages that
can process Unicode text have class tests that should simplify
letter-ness. (The superscript characters ¹²³ etc. do not have this
property.) Guile has the char-alphabetic? predicate; see URL:
https://www.gnu.org/software/guile/manual/html_node/Characters.html  
,

at least as of 2.0.


We are not using Guile 2.0 yet, and I doubt people would be happy  
about

an undiscussed change once we do.



I perfectly understand the concepts of code points and all the  
problems associated with it, have been a systems programmer part of my  
life. And there is a big difference in processing unicode characters  
as data on which the program does its job and a symbol. But towards  
what is accepted as characters to be to compose a variable name (or  
macro, or identifier) should be agreed upon. I don't mind either way,  
but what is stated and documented should in theory be followed.


My suggestions: 1. Document quick-and-dirty that although these  
characters do seem to work, usage is at your own risk, at least at  
this moment in the current (and upcoming) versions, and 2. Let's put  
it on the wishlist to properly support these, test it extensively! and  
upgrade the doc.s correspondingly.


And indeed avoid this kind of changes at once because when something  
breaks down people will be unhappy i.m.h.o.



--
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



Regards,
Wim.




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Variable names? (was: Re: Adding 3-column section to score)

[Wim van Dommelen]

Hi Harm, and others,

I wondered in this discussion what you were exactly trying to achieve,  
so I copied your code and compiled it. Very nice!


And after the copy I saw a weird thing (nothing to do with this  
specific example!): You use non-standard characters and numbers as  
names of the variables. I gasped, I didn't know this was possible at  
all. I always use rather generic names and with multiple instruments  
or pieces I always use things like: trumpetApieceB or similar. Now I  
see, it can also be something like:


H₂O→trumpet¹pieceª = { ... }

(I just tried it and this works). But the learning manual states (v. 
2.16.0, p. 37, the only reference I could find on this): The name of  
a variable must have alphabetic characters only, no numbers,  
underscores, or
dashes. which I always interpreted as: A-Z, a-z and 0-9 from the  
regular ASCII set. Now I see also other characters used.


My question: Is this use of different (utf8) characters supported by  
accident, or on purpose? I would welcome this change but not when it  
can be broken in the future. And if yes can someone update the  
documentation to provide some guideline as what to do and what not to  
do With some examples?


Regards,
Wim.



On 18 Nov 2012, at 02:34 , Thomas Morley wrote:


2012/11/17 Olivier Biot olivier.b...@gmail.com:
Is there a more elegant and less verbose way than the following  
approach to

add a 3-column section for documenting editorial changes to scores?

%% BEGIN
\version 2.16.0

% LSR snippet: http://lsr.dsi.unimi.it/LSR/Snippet?id=464
#(define-markup-command (columns layout props args) (markup-list?)

[...]

Hi Olivier,

I do like this \columns-command and from my point of view it
_is_elegant and _not_ verbose.
I'd recommend to store more stuff in variables.

If you prefer a version without \columns you may want to use this:

\version 2.16.0

txt¹ = \markup {
  \override #'(line-width . 32) {
 \column {
\huge \bold \fill-line { Bemerkungen }
\wordwrap { % Deutsch
   \bold { N° 30. } Crantz Ausgabe T. 11: cis \bold { e }  
gis:

}
 }
  }
}

txt² = \markup {
  \override #'(line-width . 36) {
 \column {
\huge \bold \fill-line \italic { Remarques }
\wordwrap \italic { % Français
   \bold {N° 30.} Édition Crantz, mesure 11: do dièse   
\bold

{ mi } sol dièse:
}
 }
  }
}

txt³ = \markup {
  \override #'(line-width . 36) {
 \column {
\huge \bold \fill-line { Notes }
\wordwrap { % English
   \bold {N° 30.} Crantz Edition, mesure 11: C sharp \bold {
E natural } G sharp:
}
 }
  }
}

mus = \markup {
   % Music annotation
   \score {
 \new Staff \with {
   \override Fingering #'add-stem-support = ##t
   \override Fingering #'avoid-slur = #'outside
   \override TupletBracket #'bracket-visibility = ##t
   fontSize = #-3
   \override StaffSymbol #'staff-space = #(magstep -3)
   \override StaffSymbol #'thickness = #(magstep -3)
   \remove Time_signature_engraver
 } {
   \key fis \minor
   \time 4/4
   \clef bass
   \bar 
   \set Score.currentBarNumber = #11
   cis2 ~ cis8 cis-. e?-. gis-.
 }
 \layout { ragged-right = ##t }
   }
}

\markup
  \override #'(box-padding . 1)
  \rounded-box \center-column {
   \fill-line { \txt¹ \txt² \txt³ }
   \vspace #0.1
   \mus
}


HTH,
 Harm

___
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: Variable names? (was: Re: Adding 3-column section to score)

[Thomas Morley]

2012/11/18 Wim van Dommelen m...@wimvd.nl:
 Hi Harm, and others,

 I wondered in this discussion what you were exactly trying to achieve, so I
 copied your code and compiled it. Very nice!

 And after the copy I saw a weird thing (nothing to do with this specific
 example!): You use non-standard characters and numbers as names of the
 variables. I gasped, I didn't know this was possible at all. I always use
 rather generic names and with multiple instruments or pieces I always use
 things like: trumpetApieceB or similar. Now I see, it can also be something
 like:

 H₂O→trumpet¹pieceª = { ... }

 (I just tried it and this works). But the learning manual states (v.2.16.0,
 p. 37, the only reference I could find on this): The name of a variable
 must have alphabetic characters only, no numbers, underscores, or
 dashes. which I always interpreted as: A-Z, a-z and 0-9 from the regular
 ASCII set. Now I see also other characters used.

 My question: Is this use of different (utf8) characters supported by
 accident, or on purpose? I would welcome this change but not when it can be
 broken in the future. And if yes can someone update the documentation to
 provide some guideline as what to do and what not to do With some
 examples?

 Regards,
 Wim.

Hi Wim,

I've not the knowledge to answer your questions definitely.
David Kastrup could say much more about it. (And there are several
discussions about that topic here on the list and on devel.)

I think/speculate that the problem of using customized variable-names
is located in the way the parser interprets them, p.e.:
numbers as duration
- or _ or ^ as direction-identifier
etc

But I can say that using ¹ ² ³ etc works for 2.12.3 (the oldest
version I've installed) up to the newest devel-version.
And it works for Linux (my OS) and windows (I learned it from a windows-user).


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names?

[David Kastrup]

Thomas Morley thomasmorle...@googlemail.com writes:

 2012/11/18 Wim van Dommelen m...@wimvd.nl:

 My question: Is this use of different (utf8) characters supported by
 accident, or on purpose? I would welcome this change but not when it
 can be broken in the future. And if yes can someone update the
 documentation to provide some guideline as what to do and what not to
 do With some examples?

 I've not the knowledge to answer your questions definitely.  David
 Kastrup could say much more about it. (And there are several
 discussions about that topic here on the list and on devel.)

At the current point of time, the rule is that alphabetic is a-z, A-Z,
and _any_ non-ASCII character.  This is a bit excessive, but short of a
reliable is a letter test, this was easiest to implement.

Personally, I stick to ASCII letters.  There is probably a bit of code
around that relies on some non-ASCII characters, so it is not really
clear that a discussion of what to do when one gets a more reliable
criterion for letter (possibly with Guilev2) will lead to a particular
result.

There is not likely going to be a technical necessity for changing the
current behavior.

However, diverging from common usage will possibly sometimes confuse
convert-ly and other programs different from LilyPond itself.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names

[Keith OHara]

Richard Sabey richardsabey at hotmail.co.uk writes:
 
 Carl Sorensen wrote:
 The core problem is -- how do you distinguish between a2 c (two notes)
 and a2c (you want it to be a variable) - currently it will be two notes.

 I might have missed something here, but: 
 in what circumstances can a pitch-name and a variable-name both be legal?

Adjusting the lexer rules a bit (similarly to what was posted years ago in 
lilypond-devel) allows :
  violin1a = { c d e }
  \new Staff \violin1a
The quotes are required, so far, because the lexer breaks words at
top-level with the same rules as it uses inside music expressions.
The parser, which knows LilyPond syntax, updates the lexer state in 
other situations, and could probably do so here.  Doing so will require
care, especially if we continue to allow single-note music expressions:
  violin1a = cis2_\downbow violin2a = \violin1a
I intend to look deeper, but encourage someone else to write an 
enhancement request for the bug tracker.

Relevant to this mailing list, I found that I do *not* like to allow a number
at the *end* of a variable, because sometimes I type things like
   \times2/3{ 
with no space, and suspect others have similar things in their old scores,
possibly with their custom-defined variables in place of \times.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user