Re: Yet Another music macro proposal

[Erik Sandberg]

On Friday 12 May 2006 10:27, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > 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).
>
> I think it's a nice cleanup to go through such a layer of scheme,
> although I'd recommend to use Nicolas' make-music functions instead.
>
> I'm not yet convinced that this will be useful. The arity of each
> syntical expression (\relative, \repeat), will have to be specified in
> advance anyway, which limits flexibility. Otherwise the parser can't
> parse it, which means that the options of overriding each part of the
> expression is limited.

The problem with hard-coded commands will however be isolated to parser.yy, 
which will shrink (and IIRC, backward compatibility is pretty often the 
reason for variable-arity commands). It will also be easy to write 
alternative fixed-arity syntaxes for any hard-coded command (e.g. create a 
4-ary music function \repeat-alternative, which returns (repeat "volta" n 
body alts))

AFAICS, all variable-arity commands must be hardcoded into the parser in any 
case; with my suggestion the only thing that's hardcoded will be the grammar 
rules, not the behaviour.

In the case of \relative, I'd like to split up the commands into two macros, 
an unary \rel and a binary \relative; with that change, relative would become 
soft-codable. 

> > - 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.
>
> I doubt that. The problem with the programming extension: is 2 fold
>
>   - the docs aren't good enough
>
>   - people don't want to learn 'complicated' things

What I meant was that when someone says "I want to have a syntactical 
construct XXX", then we can say "then do it", previously we could only 
say "you can achieve similar functionality using a different construct YYY". 
So we save some typing.

In any case, that argument was the weakest of my 3 arguments, so never mind. 

> the feature requests are extensions that just look easy to the person
> requesting it, but always are always horrible syntax kludges. I think
> we'd get more of those, as the role of the 'scary' Scheme interpreter is
> further extended with your proposal.

We are in disagreement here, I believe that the syntactic sugar could lower 
the threshold for writing music functions. Or rather, it would introduce an 
intermediate threshold: it's a rather small step to write a couple of simple 
statements in lily-style syntax; once you're used to that you might realise 
that Scheme isn't that scary after all. However, I don't know, so we'll see.

-- 
Erik