lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strike 1 music functionization...


From: address@hidden
Subject: Re: Strike 1 music functionization...
Date: Fri, 7 Oct 2011 16:00:44 +0200

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. @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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]