lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: preliminary GLISS discussions


From: David Kastrup
Subject: Re: preliminary GLISS discussions
Date: Sat, 01 Sep 2012 17:04:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]