lilypond-devel
[Top][All Lists]
Advanced

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

Re: \time vs. \times


From: Erik Sandberg
Subject: Re: \time vs. \times
Date: Mon, 3 Oct 2005 01:00:52 +0200
User-agent: KMail/1.8.1

On Sunday 02 October 2005 17.19, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> >>Thus I have the following suggestion: Make a new command `\tuplet',
> >>which is an alias of \times and deprecate the latter.
> >
> > If we are going to change this, I suggest that we also make \tuplet a
> > true Scheme function. Lots of commands that now have their own tokens in
> > the grammar could be Schemified, and IMHO, iwbn to do this.
>
> Yes, IWBN, but it also BASOOF (*) in the version that you present here,
> especially if we change \alternative. This is only worth if it really
> cleans up things, both in the syntax and in the internals.

The \alternative thing is independent of the other changes in music functions, 
and it is less important, so I'll just drop that idea for now.

> FWIW, I also think that the parser is a big ugly kludge, but you'd
> better come up with a good reason to gratuitously a syntax change which
> can't be handled with convert-ly.

Given that I drop the \alternative, it shouldn't be such a big basoof; I think 
the change should be convert-ly-able for all sensible cases.

The only remaining problem for convert-ly is to insert { } around parameters 
that need it. Finding those well enough is easy (find \name [^\^{], for all 
known names), so the only remaining problem is to add the } in the right 
place. This should be doable if we assume there is no postfix. This 
assumption isn't true in general, but it should be true for almost-all 
practical cases, at least AFAICS.

Advantages:
- syntactical: There will be less restrictions on the types of user-definable 
functions, and user-defined functions can take immediate strings/numbers as 
parameters, without a leading #.
- internals: Using this, we can convert a great number of commands into music 
functions, possibly all these:
bar,change,clef,key,mark,octave,once,partial,sequential,tag,tempo,transpose,transposition
- future: It is a way to make a clear separation between function/command 
arguments; this is a precondition for inventing a syntax for music functions 
with arbitrary or variable arity. The alternative would be to schemify all 
constants. This would be clean and convert-ly:able, but I don't think it 
would be popular since it means an extra # to type for many rather common 
commands.

> How would you deal with the variable number of parameters in
>
>    \set Foo = #bar
>    \set Bla.Foo = #bar
>
> ?

Ouch, I didn't think about that one. I drop \set from the list.

> > 4. Change the repeat syntax to
> > \repeat volta 2 {c d e f}
> > \repeat volta 2 {c d e f \alternative {{d}{e}}}
> > I.e., alternative is a unary music function, which creates a music
> > subexpression that is recognised only by the \repeat function. This is an
> > ugly hack, but it removes a shift/reduce conflict, and it makes it
> > possible to implement alternatives in the middle of a repeat (which Sven
> > asked for some time ago).
>
> No, it doesn't. It makes it possible to enter them conveniently. That's
> a big difference.

True.

-- 
Erik




reply via email to

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