[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:


> 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

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.



More information about the chuck mailing list