Tom;

In ruck, I made all UGen attributes accept lambdas (anonymous
functions), which to me seems a natural extension to ChucK, but I got
the same response, that it wasn't very ChucK-like. What languages
besides SC allow you to do things like this?

Lisp does and most things based on it so that includes Scheme which in turn means Fluxus uses anonymous functions. Fluxus might be a nice system if you want Lambda's and creative programing, it even has a (modest) extension for sound but it's mainly OpenGL.

I too feel a Lambda operator would be pushing it, I'm not sure we need it either.

The main issue as I see it isn't one of syntax, but one of CPU. If you do all modulations at sample rate (as this sort of link implies) and you don't use block processing (we don't) then there will be a big hit on the CPU so like many systems we use rates for modulation, we just allow them to be set in a advanced way (you could also call it a roundabout way, if you wish, but I think there are big strengths to it). Considering that this is a fairly common request I think we might still want to look into it once we get our "context sensitive block processing" in place (meaning we block process except where there are feedback loops involved).

I don't see a issue with anonymous functions in ChucK as such, aside from how a lack of a name will make it harder to later refer to them if/when we get around to editing running code. I could imagine this;

spork ~ {
while(1)
    {
    foo.output() => that.input;
   ms => now;
    }
}

That has been proposed before (I forgot by whom). It's not very useful in how much time/code it saves but it doesn't look incoherent to me. Doesn't look very dangerous either.

More useful to me would be this;

my_ADSR @=> my_filter.freq;

or, more generally;

my_ADSR.last() @=> my_filter.freq; //this is where the danger starts as we'll see below

Or, making it yet more general and getting back to anonymous funtions something like this;

{440 + my_ADSR.last() } @=> my_filter.freq;

or even to pay due to the typesystem to some small degree;

{return 440 + my_ADSR.last(); } @=> my_filter.freq;

This would create a anonymous function that would implicidly be pulled whenever my_filter is ticked. Still seems somewhat coherent to me, syntax-wise, but it's aproaching the edge. While it can be debated whether any of this is "ChucKian" I do think that having the option of having the UGen graph pull values from some type of custom structure when a given UGen is ticked fits very harmoniously into a strongly timed paradigm. This would very quickly lead to very big issues though; when such a structure would be a function and this function would attempt to advance time (as funtions can) we would have a big problem (if I were the VM I'd simply give up at that point). Basically this is inserting code into the UGen graph which is the very last place where we want ChucK code in a normal sense of the word as ChucK code typically does the type of thing that we don't want done there, like change the graph or advance time.

Maybe most coherent and safe would be allowing to extend UGen in our own classes, then allow for assigning UGens to UGen member functions and have those functions tick these UGens. This would mean that a custom class extending UGen would need to have a special type of function of type float called "tick()" and that inside of "tick()" we aren't allowed to advance time. Also; no linking/unlinking of UGens. Probably the only calls that we should be able to make would be to read from variables and maybe from other UGen members because if we allow function calls those functions in turn might try to do Bad Things. This is quite a easy place to do Bad Things in.

Yours,
Kas.