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@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@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




--
http://michaelclemow.com
http://semiotech.org