Re: \time vs. \times

[Erik Sandberg]

On Friday 30 September 2005 18.49, Werner LEMBERG wrote:
> While writing scores with LilyPond I've mixed up \time and \times
> again and again.
>
> 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.

I started a thread on 2005-07-20 on this issue; however no conclusion was made 
at that point. I'd be happy to change the parser, if we just can agree on a 
good convention.

I think it would be a good idea to leave out parameter type checking from the 
grammar, and support n-parameter functions in general, for large enough 
values of n (say 10). The parser would use the same grammar rule for each 
parameter, and do type checking after parsing all parameters.

The simplest way to do this, would be to say
parameter = SCM | Music | Markup;
This has the problem that all non-music parameters would need a # before them; 
e.g., \bar would need to be written as
\bar #"|.". We could therefore extend the rule to
parameter = SCM | Music | Markup | String;
but unfortunately, it's impossible to extend the rule to re-implement all 
commands.

When looking at this problem, it's good to look at this set of commands:
\transpose c d {e}
\times 2/3 {c}
\set Voice.foo = bar
\repeat volta 2 {c d e f}
\repeat volta 2 {c d e f} \alternative {{d}{e}}

The main problems are:
- c 4 can either be interpreted as one music expression c4, or as an 
expression c followed by number 4.
- Special characters such as . and = and / are problematic; for example c4*2/3 
could be interpreted either as three parameters c4*2 / 3 or as a single music 
expression.
- repeat uses a variable number of parameters.

I've done some quick thinking again, and one idea is to do the follwoing:
1. Forbid simple music expressions which aren't enclosed in {} or <<>>. This 
has the points that
 - It seems to solve many problems with the grammar.
 - It is a simple rule, easy to remember.
 - It is consistent with e.g. toplevel_music.
 - I don't know about any cases when it makes music much more tedious to 
enter. If you can enter a function name, you can also enter a pair of 
brackets.
Technically, this restriction can be implemented by replacing Music by 
Composite_music everywhere in the grammar, except in Music_list.
2. The function parameter rule can look like:
parameter = pitch | '/' | '.' | '=' | NUMBER | String | Markup | 
Composite_music;
3. Re-implement \times, \transpose, etc. as music functions. This should be 
possible for all commands except \lyricsto (etc) and \repeat.
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).

It would be possible to support functions with any number of parameters, by 
allowing a syntax similar to \func '<' param1 param2 ... '>'. There's 
something inelegant about this IMHO, and it's only needed for functions with 
variable number of arguments. Hence, I don't think we need to add it now.

Han-Wen, do you have any objections against imposing this restriction?

-- 
Erik