On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup <d...@gnu.org> wrote: > Graham Percival <gra...@percival-music.ca> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel