Issue 3498: fatal error with toplevel-markup-identifier

Issue 3498: fatal error with toplevel-markup-identifier

The reported problem

    mrkp = \markup { "x" }

    \mrkp

triggers an error because of markup requiring additional lookahead in
assignments.  This is fixed by sacrificing string addition, an arcane
and undocumented feature that has probably not been used in the last
decade or so.

[janek, 2013-08-18 10:20:07]

LGTM (but i'm not a parser expert)

Sorry for a possibly ignorant question: will this patch also remove the error in
case of
mus = { a }
\mus
?
If not, would there be an easy way to fix that?

Janek

[thomasmorley651, 2013-08-18 10:41:18]

On 2013/08/18 10:20:07, janek wrote:
> LGTM (but i'm not a parser expert)

I've no clue about the parser, from description:
LGTM

> 
> Sorry for a possibly ignorant question: will this patch also remove the error
in
> case of
> mus = { a }
> \mus
> ?

No.

> If not, would there be an easy way to fix that?

Well, we could delete all functionality of \addlyrics etc
(Ok, was a joke)

[janek, 2013-08-18 11:05:39]

2013/8/18  <thomasmorley65@gmail.com>:
> On 2013/08/18 10:20:07, janek wrote:
>> Sorry for a possibly ignorant question: will this patch also remove
>> the error in case of
>> mus = { a }
>> \mus
>> ?
>
> No.
>
>> If not, would there be an easy way to fix that?
>
> Well, we could delete all functionality of \addlyrics etc
> (Ok, was a joke)

Ah, i see the difficulty now, thanks!
Janek

[dak, 2013-08-18 17:21:00]

Janek Warchoł <janek.lilypond@gmail.com> writes:

> 2013/8/18  <thomasmorley65@gmail.com>:
>> On 2013/08/18 10:20:07, janek wrote:
>>> Sorry for a possibly ignorant question: will this patch also remove
>>> the error in case of
>>> mus = { a }
>>> \mus
>>> ?
>>
>> No.
>>
>>> If not, would there be an easy way to fix that?
>>
>> Well, we could delete all functionality of \addlyrics etc
>> (Ok, was a joke)
>
> Ah, i see the difficulty now, thanks!


It's not entirely clear since you can't write

mus = \addlyrics ...

anyway.  The main problem is that \mus differs from #mus in that it
needs to be evaluated _before_ a token can be handed to the parser.
This will only change once every \xxx has the same token category.  The
project of reducing the number of xxx_IDENTIFIER tokens is ongoing (and
has created quite a few more possibilities) but by far not finished.

If \mus returned _two_ tokens, the first without actually evaluating
mus, it is conceivable that the first token already provides enough
information to the parser to know that \addlyrics (and a few similar
commands) are definitely _not_ coming, so that it can evaluate the
assignment before evaluating \mus itself.

But that would be a rather complex change for comparatively little
benefit.  So I prefer focusing on reducing the xxx_IDENTIFIER cases
instead.

-- 
David Kastrup

[janek, 2013-08-18 18:41:20]

2013/8/18 David Kastrup <dak@gnu.org>:
> It's not entirely clear since you can't write
>
> mus = \addlyrics ...
>
> anyway.  The main problem is that \mus differs from #mus in that it
> needs to be evaluated _before_ a token can be handed to the parser.
> This will only change once every \xxx has the same token category.  The
> project of reducing the number of xxx_IDENTIFIER tokens is ongoing (and
> has created quite a few more possibilities) but by far not finished.
>
> If \mus returned _two_ tokens, the first without actually evaluating
> mus, it is conceivable that the first token already provides enough
> information to the parser to know that \addlyrics (and a few similar
> commands) are definitely _not_ coming, so that it can evaluate the
> assignment before evaluating \mus itself.
>
> But that would be a rather complex change for comparatively little
> benefit.  So I prefer focusing on reducing the xxx_IDENTIFIER cases
> instead.

ok.  thanks for explanation!