What about this:<br><br>normal function def -<br><br>fun int addOne(int x)<br>{<br> return x+1;<br>}<br><br>I think that what would make a functional paradigm possible is that "fun <type>" is a type definition. The goal is something like -<br>
<br>fun void run(fun void f)<br>{<br> f();<br>}<br><br>this is weird, but valid...<br><br>fun fun void combine( fun void f, fun void g )<br>{<br> fun void h()<br> {<br> f();<br> g();<br> }<br><br>
return h;<br>}<br><br>we could do anonymous functions in a way that SClang does, using just curly braces -<br><br>{<br> int x, y;<br> return x + y;<br>}<br><br>then we can overload the @=> operator to allow (with added keyword "arg" to define arguments) -<br>
<br>{<br> arg int x, y;<br>
return x + y;<br>
} @=> fun int f;<br><br><<< f(4, 5) >>>; // prints "9"<br>
<br>and then we can add (i'm just ranting now) default/optional arguments from Python -<br><br>fun int f(int x=5, int y=9)<br>{<br> return x+y;<br>}<br><br><<< f(1,2) >>>; // prints "3"<br>
<<< f() >>>; // prints "14"<br>
<<< f(6) >>>; // prints "15", I guess...<br><br><br>imaginary syntax is fun (void).<br><br>-Mike<br><br><br><div class="gmail_quote">2010/1/6 Kassen <span dir="ltr"><<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Atte;<br><br><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<font color="#888888"><br></font></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>
<br>_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://michaelclemow.com">http://michaelclemow.com</a><br><a href="http://semiotech.org">http://semiotech.org</a><br><br>