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

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

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

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

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

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

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

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

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

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 jus

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

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 names >> Why would that be desirable? >> > > Whenev

Re: Strings as variable names

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

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

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

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

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

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

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 > everywhere. NR refers to http://www.lilyp

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 ___ lilypond-user mailing list

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

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

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 variable names. > That’s true. I just don’t like

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Strings as variable names

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 wrote: > > flute_phrase01 = > > flute_phrase02 = > > > > or similar. > > When would you ever want to do that? Actually,

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

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

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