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

(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-fi

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

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 m

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

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 chec

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

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-stri

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

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 ma

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

re 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

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

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

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

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.

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

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?

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 quest

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

ye.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. &

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. Well, there is a proper index entry... However, documentation for the 'foo.1.bar.2' trick is still m

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

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

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 www.ptoye.com - > Message: 4 > Date: Sat, 6 Mar 202

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

: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 i

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

田村淳 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-spaci

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

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

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 parse

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

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

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

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

><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

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

(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 k

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

ord 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:

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

, 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 p

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

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

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

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 maint

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

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 name

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

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

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

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 r

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

d 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 e

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

"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 encounteri

Re: Understanding symbol-list? variable names

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 origi

Re: Understanding symbol-list? variable names

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? Gra

Re: Understanding symbol-list? variable names

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-spacin

Re: Understanding symbol-list? variable names

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

Re: Understanding symbol-list? variable names

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:

Understanding symbol-list? variable names

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-func

Re: Variable names

"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 >>

Re: Variable names

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 becom

Variable names

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 relatio

Re: Strings as variable names

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 enoug

Re: Strings as variable names

ve 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

Re: Strings as variable names

> > 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

Re: Strings as variable names

rings? 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 Us

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

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

Re: Strings as variable names

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 th

Re: Strings as variable names

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? > >

Re: Strings as variable names

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 synt

Re: Strings as variable names

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?

Re: Strings as variable names

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

Re: Strings as variable names

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. >> >>

Re: Strings as variable names

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 ===

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

> 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 inter

guileV2 and Lilypond (was: Strings as variable names)

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

Re: Strings as variable names

> 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/Jav

Re: Strings as variable names

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 o

Re: Strings as variable names

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

Re: Strings as variable names

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.ki

Re: Strings as variable names

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?) ) > [&c.] > (define-markup-command (foo arg) (arg-type?) ) I don't share your sentiments here. Now define-music-function is arguably mi

Re: Strings as variable names

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, tha

Re: Strings as variable names

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 inte

Re: Strings as variable names

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 un

Re: Strings as variable names

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)

Re: Strings as variable names

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 >> >> def

Re: Strings as variable names

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. >

Re: Strings as variable names

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

Re: Strings as variable names

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 h

Re: Strings as variable names

> 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

Re: Strings as variable names

Am 28.12.2015 um 20:30 schrieb David Kastrup: > Malte Meyn 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 variab

Re: Strings as variable names

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

Re: Strings as variable names

> 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

Re: Strings as variable names

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

Re: Strings as variable names

Malte Meyn 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 ___ lilypo

Re: Strings as variable names

On Mon, 28 Dec 2015 18:49:30 +0100 David Kastrup 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 >

Re: Strings as variable names

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 t

Re: Strings as variable names

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 = … fl

Re: Strings as variable names

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 docum

Re: Strings as variable names

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

Re: Strings as variable names

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 fo

Re: Strings as variable names

"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.kie

Re: Strings as variable names

Urs Liska 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

Re: Strings as variable names

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

Re: Strings as variable names

Am 28.12.2015 um 18:49 schrieb David Kastrup: David Sumbler 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

Re: Strings as variable names

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? >

Re: Strings as variable names

David Sumbler writes: >> > From: David Kastrup >> > To: Andrew Bernard >> > Cc: lilypond-user@gnu.org >> > Subject: Re: Strings as variable names >> > Date: Mon, 28 Dec 2015 12:51:51 +0100 >> > >> > Andrew Bernard writes: >&g

Re: Strings as variable names

> > From: David Kastrup > > To: Andrew Bernard > > Cc: lilypond-user@gnu.org > > Subject: Re: Strings as variable names > > Date: Mon, 28 Dec 2015 12:51:51 +0100 > > > > Andrew Bernard writes: > > > > > > > d...@gnu.org> wrote

Re: Strings as variable names

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_c

Re: Strings as variable names

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. >

Re: Strings as variable names

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 mail

Re: Strings as variable names

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 cleare

Re: Strings as variable names

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 quo

Re: Strings as variable names

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

Strings as variable names

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 m

Re: Variable names?

On 19 Nov 2012, at 22:16 , David Kastrup wrote: "Christopher R. Maden" 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"

Re: Variable names?

"Christopher R. Maden" 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. >

Re: Variable names?

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 pro

Re: Variable names?

Thomas Morley writes: > 2012/11/18 Wim van Dommelen : >> >> 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 provid

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

vid 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-ident

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

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 v

Re: Variable names

Richard Sabey 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

  1   2   >