[chuck] a toast
Magnus Danielson
cfmd at bredband.net
Sat Jan 22 21:10:52 EST 2005
From: Ge Wang <gewang at CS.Princeton.EDU>
Subject: Re: [chuck] a toast
Date: Sat, 22 Jan 2005 00:44:05 -0500
Message-ID: <A0B3D8B6-6C38-11D9-A97B-000A95E8A85C at cs.princeton.edu>
Hi Ge!
> On Jan 21, 2005, at 8:51 PM, qbxk wrote:
>
> > i would like to propose an idea that might very well have good reasons
> > for not doing. i'm putting this out here - phishing...
> >
> > i want perl and chuck to get married.
>
> (Isn't ChucK a little young to be married (I mean, age difference
> aside)?)
Definitly, I think so at least. Has it got its bachelor degree from Princeton
yeat? No? I didn't think so... ok, definitly too young!
> > chuck & perl what a beautiful couple. yeah, perlish things like
> > @arrays & %hashes i need to throw at music. and map, grep, dothis if
> > something, and the bajillion perl modules that might create a barrage
> > of audio somehow. good idea/bad idea?
>
> Maybe both good and bad? arrays + hashes are good things - going to appear
> shortly (see below) - and extensive string handling is coming soon. the
> bajillion Perl modules are tempting. Perhaps someone with more expertise in
> Perl (i.e. Alex and many other Perl-enthusiasts who are on this list) can
> give a better answer.
All tempting things may not be a good advice. Also, there are other
alternatives available if a marrige is needed.
> I can, however, "articulate" one related aspect:
<SNIP>
> There are certainly a great many things we can learn and take from Perl (like
> it's powerful string/array processing, and the (sometimes ultra-)concise
> spirit of the language). There are other considerations which make tight
> integration difficult
> - for example, Perl is weakly-typed, unlike the ChucK type system, which is
> useful for things like resolving the ChucK operator, doing arithmetic on time
> and duration, and makes larger systems much easier to reason about and debug.
>
> In short, ChucK could learn much from Perl - though they are quite different
> in their "life goals".
Just because there are good languages out there, not all the aspects of them
will really make them usefull for real-time processing and real-time
programming. You really need to think hard about what features you bring in,
since the side-consequences may not be to hard when you do make a misstake and
you also want to ensure that it is easy to do the right thing to start with.
> As for arrays in the next release:
>
> - there are arrays
> - arrays are strongly-typed like the rest of ChucK
> - arrays can be multi-dimensional
> - all arrays are, by default, both integer-indexed and associative:
> - more to come...
>
> // basic example
> { 1, 2, 3, 4 } => int foo[ ];
> // assign to element 0
> 10 => foo[0];
> // assign to value mapped from key: "bar", on same array
> 24 => foo["bar"];
Yeah, that is a step forward... (I looked in the v2 grammar) some time back I
advice a friend on his livecoding software where he was going to add arrays.
His grammar works a bit different (assignments go left and not right) but
strangely enought is the curly brackets left over for vector-constructions. So,
he also had the starting point:
v = {1,2,3,4};
Now he wanted pointers, but I convinced him that this was a *BAD* idea for a
live-coding tool. You don't want to bother debugging pointers in realtime.
Anyway, while at it I also proposed a slightly expanded grammar for the vector
construction, so that not only single values can be added, but a bunch of
values.
a = {1,2}
b = [3,4]
v = {a,5,b}
results in
v = {1,2,5,3,4}
Naturally, you may want to pick values out of a previous vector but not use all
of them.
a = {2,3,5,7}
b = {11,13,17,19}
v = {a[3],a[4],b[2],b[3]}
It's a bit bulky, so introducing range-selection will make things much better:
v = {a[3-4],b[2-3]}
If you are curious, I recommended reference counters for him, with no
destrutor. It took some time to figure out all the side-consequences, but I was
able to close all leaks of references such that the vectors was trown exactly
when they where no longer accessable, and thus avoiding a garbage-collector.
Again, this makes it suitable for a real-time system.
> > if good how? run script thru perl interpreter which emits chuck code
> > fed into chuck? line by line for speed?
>
> This is an interesting idea to try, even for the sheer spectacle alone.
Mmmmm.....
Cheers,
Magnus
More information about the chuck
mailing list