[chuck-users] Getting Started with ChucK

[Hans Aberg]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimTest.mid
Type: audio/midi
Size: 2110 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090721/864f2527/attachment.mid>
-------------- next part --------------