[Top][All Lists]
[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
- Re: preliminary GLISS discussions, (continued)
Re: preliminary GLISS discussions, Jan Nieuwenhuizen, 2012/09/01
Re: preliminary GLISS discussions, Graham Percival, 2012/09/01
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/01
- Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/01
- Re: preliminary GLISS discussions,
David Kastrup <=
- Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/01
- Re: preliminary GLISS discussions, David Kastrup, 2012/09/01
- Re: preliminary GLISS discussions, Keith OHara, 2012/09/01
Re: preliminary GLISS discussions, Han-Wen Nienhuys, 2012/09/01
Re: preliminary GLISS discussions, David Kastrup, 2012/09/01
Re: preliminary GLISS discussions, David Kastrup, 2012/09/01
Re: preliminary GLISS discussions, Trevor Daniels, 2012/09/01