Han-Wen Nienhuys <hanw...@gmail.com> writes:
> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup <d...@gnu.org> wrote:
>
>> 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.
You can also argue that people that know what a duration is, and how to
use it will be better served by writing Scheme directly. Because a
duration is complex enough in Scheme already.
Or that people who know what a music list is should be writing it in
Scheme. Just because something can be represented in Scheme does not
mean that a mapping to LilyPond does not make sense.
> 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)))
It would be easy enough to let $@ work on arbitrary sequences, not just
lists. You can already write things like
<< $@(map ...) >>
How many people are asking for \violin2 all the time?
>> 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.
I am making good progress on that, actually.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
