Strike 1 music functionization...

[David Kastrup]

Hi,

I've tried reworking the syntax such that \mark can become a syntax
function.  What a nuisance.

Here is the short breakdown: \mark has an argument of syntax class
scalar.

Likely unbeknown to most people, a scalar can include oddities like
"A"+"B" (string concatenation).  Trying to rework the syntax to
accommodate that eventually failed.  I'll spare you most of the folderol
and decisions I made.  What finally made Lilypond barf when I finished
was something like

\language "italian"
sol

Why would that be a problem?  \language would have become similar to
\mark regarding the parser, taking one argument accommodating, for
example, "italian"+"".  So the parser needs to look ahead to see whether
there is a + coming up in order to augment "italian".  Of course, when
it looks ahead, the next token sol is not recognizable at all, since the
language is still in the old state. @address@hidden

When I fixed that, scalar become similar enough with embedded_scm that I
got 87 reduce/reduce conflicts and frankly, that was enough of a pest.

Why do I distinguish those?  I can't accept a scalar anywhere sensibly
except at the end of an argument list, because a scalar can also be
something like either 5, or \cm, or 5\cm.  If I except this anywhere
except at the end of the argument list, I can't reliably tell whether
this is one scalar or two.

Lilypond syntax sucks.  I've decided to boil down scalars enough that
they don't need lookahead (frankly, who used the string concatenation
feature or even knew about it?).

But a scalar can also be markup, and in connection with optional
arguments (and with typechecking) you soon get into a situation where it
is hard to find optional arguments when a scalar can be used anywhere
but it end position.

So what I'll likely do is smother most distinctions in the parser that
can be uniquely identified by predicate anyway, and figure out how I can
make the parser skip optional arguments if the predicate turns out
false, rather than just doing the predicate check as a verification of
an already made choice.

That will at least conflate Scheme arguments, markup arguments, markup
lists, numbers and strings in the parser, obliterating the drawbacks
from the markup-list-in-the-parser changes from Reinhold (that exploded
in somebody's face recently).  Of course, pitches, durations, and music
expressions will still need to be told apart by the parser itself.

But at least you'll be able to cook up predicates "markup-or-string"
(pretty redundant since currently every string _is_ a markup) yourself
and have them work fine.

I don't think I'll allow actual multiterm expressions (including 3\cm)
anywhere except in assignments and similar explicitly parsed constructs
(property setters and so).  Possibly there will be a way to get them
elsewhere, if somebody really complains loudly, if you enclose them in
braces or parentheses or something like that.

I am pretty annoyed, having spent over a week cooking down reduce/reduce
and shift/reduce conflicts in the fight for a somewhat more powerful
syntax and finding that the results are not really all that useful.

Of course, this change of design is bad news for the impending markup
workshop: the changed design will make it even more convenient that
strings, numbers(?) and other stuff can be swapped rather freely with
markup.

-- 
David Kastrup