[chuck-users] wishlist for the new year
mike clemow
michaelclemow at gmail.com
Wed Jan 6 11:16:33 EST 2010
What about this:
normal function def -
fun int addOne(int x)
{
return x+1;
}
I think that what would make a functional paradigm possible is that "fun
<type>" is a type definition. The goal is something like -
fun void run(fun void f)
{
f();
}
this is weird, but valid...
fun fun void combine( fun void f, fun void g )
{
fun void h()
{
f();
g();
}
return h;
}
we could do anonymous functions in a way that SClang does, using just curly
braces -
{
int x, y;
return x + y;
}
then we can overload the @=> operator to allow (with added keyword "arg" to
define arguments) -
{
arg int x, y;
return x + y;
} @=> fun int f;
<<< f(4, 5) >>>; // prints "9"
and then we can add (i'm just ranting now) default/optional arguments from
Python -
fun int f(int x=5, int y=9)
{
return x+y;
}
<<< f(1,2) >>>; // prints "3"
<<< f() >>>; // prints "14"
<<< f(6) >>>; // prints "15", I guess...
imaginary syntax is fun (void).
-Mike
2010/1/6 Kassen <signal.automatique at gmail.com>
> Atte;
>
> And regarding WM (Window manager) I used to chuck in tty, with X killed,
>> but recently it seems that I cannot get more performance (ok maybe <5% at
>> the most) that way. So now I'm usually sticking to gnome with
>> bells/whistles.
>>
>>
> That's roughly what I found too. The bells&whistles run -mostly- on the GPU
> anyway. I think it will only matter at extremely low buffer settings where
> the occasional usage spike of non-ChucK processes may cause a glitch.
>
> We need the context-sensitive block processing as it's our lack of block
> processing that is the main reason ChucK takes a comparatively large amount
> of cpu. The context-sensitive version (as in; no block processing for parts
> of the UGen graph that have feedback) sounds like a very good idea, I think
> it should be possible, in a way it even seems obvious. The one issue is that
> I don;t think anyone else has ever done that.
>
> That one should be a big leap in performance, after that we may have to
> think about multi-core support. Strongly typed multi-core support sounds
> distinctly non-trivial to me. I think Ge was looking into it but the problem
> is notoriously hard and we are smack in the middle of the kind of area where
> it's especially hard, for what I understand of it.
>
> Yours,
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
--
http://michaelclemow.com
http://semiotech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100106/2975b588/attachment-0001.html>
More information about the chuck-users
mailing list