On 21 Jul 2009, at 19:48, Kassen wrote:
One of the questions is that a Lambda operator is typically used in languages that are very different from ChucK and combined with very different constructs.
Even in Haskell, they have written packages that allows one to do essentially imperative programming. This will be wrapped up in complicated underlying constructs, such as monads, so it puts up the question of good language design.
I think that in a strongly typed language it might be much less useful and there are things that are more or less equivalent.
Both Haskell and OCaml are strongly typed functional languages. What do you have in your mind here?
I'm still interested in ideas like operator overloading, particularly of the ChucK operator. I also think functors might be nice ideas.
In Haskell, operator overloading is tied to a construction of polymorphic classes, because it needs to fit with the Hindley-Milner style type inference system. So it exists, but one can't overload functions standing alone. This limitation is eased up by a module system, essentially the same as C++ namespace.
We are talking about syntactic sugar here.
A functional language just adds one object: the lambda operator. It just makes it possible to create functions dynamically and fully treat them as objects.
I do think sugar can make sense and it could work as a double edged sword. We could for example attempt to create a syntax for audio rate modulation that would be more predictable in structure than sporked shreds which we might also try to use behind the scenes to optimise computation; that to me would make loads of sense and it would serve two needs that I think are clearly held without excessively complicating syntax.
This is an independent issue. Chuck needs some components so that the creation of basic units becomes simpler. This might be tied to a multiple timing model. The per-sample timing is only needed when creating a single sound generator, corresponding to a string or pipe in a music instrument. When coordinating those into music instrument, a timing of about 10 millisecond might suffice. A group of music instruments might do with somewhat less. - Just an input.
I'd like to see a example of what you or Tom (or anyone else for that matter) would imagine a Lambda operator would look like in ChucK or what it would solve.
One can write very expressive and compact code. There is a good chance it will help in music, as music often have structures that should be repeated with some variations. The Haskore package had some examples, for example the attached fractal music sample. It does not mean this how the music will sound :-), only that it becomes easier to write it.
I suspect we could do most of that sort of thing in other ways as well...
Strictly speaking, even function stacks are wholly unnecessary in a computer - any program can be expanded to a sequence of jumps. It was added over the years to support the way humans want to program.
...and I fear trouble could well follow. When I started writing my last email to this list it seemed to me like anonymous functions that would write to parameters at audio rate seemed like a fairly innocent thing, I think it's now clear that those aren't as innocent (I went "oops" myself).
It is though difficult to implement a functional language. One needs to deal with the relabeling of variables under substitution. So it might be better to tweak some existing functional language into accepting Chuck's timing concepts. Hans