Re: fatal error with toplevel-markup-identifier

[David Kastrup]

Thomas Morley <address@hidden> writes:

> the following returns a fatal error (worked fine with 2.16.2):
>
> \version "2.17.24"
>
> mrkp = \markup { "x" }
>
> \mrkp
>
>
> Terminal-output:
>
> GNU LilyPond 2.17.24
> Processing `toplevel-markup-identifier-bug.ly'
> Parsing...
> toplevel-markup-identifier-bug.ly:5:1: error: unknown escaped string: `\mrkp'
>
> \mrkp
> toplevel-markup-identifier-bug.ly:5:6: error: syntax error, unexpected
> end of input, expecting SCM_IDENTIFIER or SCM_TOKEN or STRING or '='
> \mrkp
>
> fatal error: failed files: "toplevel-markup-identifier-bug.ly"

Here is the rub (verified it): \markup and normal strings are no longer
distinguished syntactically (in order to be able to use them
interchangeably, also at top level).

But for strings, there is string addition defined in assignments.  You
can write

xxx = \markup "x" + \markup "y"

as a consequence, and in your example the lookahead for the potential
"+" token pulls in the \mrkp token, and since \whatever can have
arbitrary token types depending on the underlying value, it proceeds to
evaluate it before the assignment has been completed.

I propose that we remove string addition from assignments.  It's
unlikely anybody was aware of it in the last 10 years, and it's not like
it is documented.

If you do the same with music expressions, you'll run into the same kind
of problem (since most music expressions could be followed by things
like \addlyrics ...).  Calling variables with \ immediately after
assigning potentially incomplete expressions to them will not work
satisfactorily.  In contrast, used within #(...) they will not be
problematic usually since first the expression is read and recognized as
SCM_TOKEN which is not combinable with the assignment (usually), then
the assignment is executed, and only then the expression read with
#(...) is evaluated and can already rely on the new value of the
variable.

But since \ needs to make a choice about the syntactic class right away,
that does not work like with #.

-- 
David Kastrup