Graham Percival <[email protected]> writes:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group function parameters.
>
> I agree; it's a mess. Let's examine David's most hated example:
>
> \version "2.15.0"
> {
> \tempo 4 = 60
> c1 c
> \tempo 4. = 60 ~ 72
> c1 c
> \tempo "Andante"
> c1 c
> \tempo "Allegro" 4 = 120
> c1 c
> \tempo "Allegro" 4 = 120 ~ 144
> c1 c
> \tempo \markup{ Presto } 4. = 172 ~ 188
> c1 c
> }
>
> What are the options here?
> 1) use explicit delimiters for function arguments
> (i.e. \tempo {...})
> 2) add a "non-argument" like \default for all parameters which are
> not needed
> 3) define different function names, i.e. \tempoNumber,
> \tempoNumberRange, \tempoText, \tempoTextNumber...
>
>
> NB: I am not suggesting that all or any of those ideas are good;
> I'm just trying to list the options that I can think of.
It is reasonably easy to state "this will have to go". However, I have
not so far attempted a replacement since I am still fuzzy on
assignments. Basically I want to have the equivalent of procedures with
setters for LilyPond at one point of time, being able to write things
like
(set! (array-ref violin 1) #{ ... #})
as
\violin 2 = ...
In order _not_ to have _syntactical_ categories like "vector of music"
hardwired into the syntax, this requires parsing of functions
essentially independent from the type they end up having: first a
function needs to get evaluated, and its type is determined by the type
ending up as its evaluation.
So there are several steps I need to get done first before it makes
sense for _me_ to take a survey of what kinds of \tempo syntax make
sense and what not. 172 ~ 188 is an abomination anyway. It would be
reasonably straightforward to accept a pair here, like #(172 . 188) or
172/188 which is equivalent.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
