On 28.12.2015 23:35, David Kastrup wrote:
Simon Albrecht <simon.albre...@mail.de> 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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
