Re: preliminary GLISS discussions

[David Kastrup]

Graham Percival <address@hidden> 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