Re: Yet Another music macro proposal

[Erik Sandberg]

On 5/12/06, Nicolas Sceaux <address@hidden> wrote:
> Erik Sandberg <address@hidden> writes:
>
> > Hi,
> >
> > I have yet another suggestion for how \relative can be soft-coded in a generic
> > way. It's inspired by criticism of earlier attempts. It's similar, but not
> > identical, to a previous suggestion.
> >
> > Macros is that they operate on syntax, not on music. And the parser spits out
> > music directly. So what I suggest, is to let the parser spit out yet another
> > intermediate format, which is a Scheme expression that more or less
> > corresponds to the the parse tree. So, for example,
> >
> > \repeat volta 2 { c8 d e \foo }
> >
> > would parse into a Scheme expression
> > (repeat 'volta 2 (sequential <c8> <d8> <e8> foo))
> > where <c8> etc. are Music objects (or possibly expressions that evaluate to
> > Music objects).
> >
> > When a top-level expression has been parsed into such scheme expression, it is
> > evaluated in a Scheme module, where repeat, sequential etc. are defined as
> > functions that return music; this evaluation produces the final music
> > expression.
> >
> > Some benefits:
> > - It will be easy to make \relative a music macro, by defining relative as a
> > Scheme macro.
> > - The parser will be reduced to a thin layer of syntactic sugar, so a large
> > portion of parser.yy can be moved to scheme. Application of music functions
> > and dereferencing of variables is completely outsourced to guile.
> > - For those who want to do programming using lily syntax, it will be easy to
> > export Scheme functions and macros to the lily parser at runtime. This will
> > probably reduce the number of feature requests that come to our mailing
> > lists.
>
> What you're describing over-reaches my mental capabilities (I can't
> understand exactly how you'd do that, and if the promised flexibility
> would actually arise). But if the root problem is actually the \relative
> mode, couldn't it be coded as a music function?

The problem is that \relative should behave as a macro, i.e., it
should act before music functions are applied. This makes the
following work:
\relative \partcombine { c d e f}  {g a b c }

I have also written something that partially makes this possible, but
it's not the proper way to do it.

Some stuff will break with with my suggestion: If the parser is
modified inside one top-level expression, then the changes will not be
applied until the next top-level expression. This will break some
(ab)uses of parallelMusic. The problem is that the parser needs to
know for each identifier whether it's a function or a variable.

E.g., the following:
{
 f4
 \parallelMusic #'(foo) { c d e }
 \foo
}
will not work because the parser doesn't know foo when the expression
is parsed. However, any of the following will work:
\parallelMusic #'(foo) { c d e }
{
 f4
 \foo % separate top-level expression, so parser is updated with
declaration of foo.
}
or
foo={}
{
 f4
 \parallelMusic #'(foo) { c d e }
 \foo % we have declared foo in advance, so parser correctly
interprets this as a variable
}

I don't think this is a big problem (it just enforces good coding
practise), but it's a reason to implement the new layer fairly
quickly, before misuse of \parallelMusic starts to generate backward
compatibility problems. It's first on my todo aft

Erik