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