lilypond-user
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strings as variable names

From: Simon Albrecht
Subject: Re: Strings as variable names
Date: Tue, 29 Dec 2015 15:16:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 
On 28.12.2015 23:35, David Kastrup wrote:

Simon Albrecht <address@hidden> 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 – <https://github.com/wbsoft/frescobaldi/issues/790>). 
The other is the inconsistency between

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

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

(define (foo arg) <body>)
(define-music-function (foo arg) (arg-type?) <body>)
[&c.]
(define-markup-command (foo arg) (arg-type?) <body>)
(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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]