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. @!#$!#@$! 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
