Re: preliminary GLISS discussions

[Han-Wen Nienhuys]

On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup <address@hidden> wrote:
> 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

Again, I would argue that people that know what a vector is, and how
to use it will be better served by writing scheme directly.

Vectors don't make sense unless you give a mechanism to map/iterate
over them, ie something along the lines of

(make-parallel-music (vector->list
  (map (lambda (x) (add-new-context "Staff" x)) violin)))

> 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.

The type / evaluation dichotomy was something I have struggled with as
well. It might be feasible to construct a real type system inside
lilypond, but at the same time, we want to evaluate scheme function
inline as we parse them. Those two are difficult to reconcile.

> 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.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen