On Oct 7, 2011, at 3:51 PM, David Kastrup wrote: > > 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.
I don't see this being a problem. Most of the work we'll be doing will start on the music stream, well after the parser's finished doing its thing. That said, I don't completely get what you're talking about (not because you're not clear, but because it is over my head and would take me a while to understand), so if you feel that it will get in our way in some way that I'm not anticipating, please send a point-by-point list that is digestible by newbs (it'll be mostly rookies at the event, and I'm more or less a newb to parsing) and I'll explain it to all those who are interested. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel