lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: simple scheme in lilypond


From: David Kastrup
Subject: Re: simple scheme in lilypond
Date: Wed, 28 Nov 2018 10:47:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Gianmaria Lari <address@hidden> writes:

> On Tue, 27 Nov 2018 at 12:12, David Kastrup <address@hidden> wrote:
>>
>> in output and in its effect on the variable.  Basically, $x and \x are
>> the same (apart from the characters allowed in and after x).  The
>> logical thing would be to permit "Test" on its own but it appears rather
>> error-prone.
>
>
> "... but it appears rather error prone" then lilypond forbid it. Is that
> right?
> Wouldn't be better just a warning like when you make an assignment inside a
> conditional statement?

C++ has been designed to be readable to the computer, LilyPond has been
designed to be readable to the user.  A standard compliant compiler is
not allowed to throw errors for things permitted by the standard even if
they are a bad idea.  If there is no conceivable reason to be writing
things in an unreadable manner, LilyPond not rarely makes the choice
just not to permit them.  For example, what do we gain when we allow

   c4 d e c g g c1

to be valid input creating 7 single-note scores one after another?
Consistency, because you can do the same by passing each note through a
music variable.  But if the user actually meant what he stated here, it
would have been easy to explicitly write something like

   { c4 } { d } { e } { c } { g } { g } { c1 }

Now with regard to quoted strings, they can also be used for creating
identifiers.  I can write

"Test" = 7

and that is not supposed to typeset "Test" but assign to a variable
called "Test".

It does not particularly help that something like cis=4 is valid note
input (a quarter note with an octave check to the small octave).  Giving
"Test" specific meaning when not followed by = requires lookahead.
Lookahead always is good for trouble.  We may already have it here for
unrelated reasons: not sure.  Either way, when the compiler requires
lookahead to figure out things, so does the human reader.  The language
becomes harder to understand.

Now where "Test" is supposed to be interpreted as a string, it would
seem surprising that #"Test" in the same location would be ignored and I
already explained the rationale for ignoring #-expressions in places
where assignments are allowed.

Basically you are asking to open a can of worms here not because you
actually want a worm but because you consider closed cans offensive.

In this case, if you go to lily/parser.yy and add the production
STRING | to the front of the definition of toplevel_expression (you'd
also need to add an action, namely the relevant part of the preexisting
action for embedded_scm_active), you can then do

bison -rall -g lily/parser.yy

and check the warnings and log files for conflicts (in this case
actually none).  That often is enough to see why a particular proposal
is a bad idea even if it does indeed not trigger on this particular one.

So when messing with syntax in areas that are already pretty full always
triggers the "what is this actually good for?" question and I haven't
seen an answer so far that would convince me we are doing anybody much
of a favor by filling this in the manner you want.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]