[chuck-users] ChucK Inconsistencies...

[Mike McGonagle]

This is a list of something that I find to be a little difficult when
learning ChucK.

Language inconsistencies - I am point these things out, more from a
'linguistic' point of view, not so much as 'bugs'. One syntax about
ChucK that I like is that data can come before the function calls that
use that data. It just seems to make reading the code much easier.
While this
can be good for some things, others do suffer. One of those "troubles" is:

0.0 => myFunc;
0.0 => myFloat;

it is hard to tell which one of these is really a function call, and
which one is an assignment statement, without knowing the full
program. And when you start to deal with objects, this might get to be
trouble. When using Ugen objects, this is also kind of confusing, as
when you are retrieving a value from the object, you use

last() => myFloat;

but when setting it, you use:

myFloat => next;

Now onto the specifics...

*************************
1. not all function calls are created equal

fun float myFunc0() { return 0.0; }
fun float myFunc1(float x) { return 0.0; }
fun float myFunc2(float x, float y) { return 0.0; }

0.0 => float x => float y => float z => float a;

() => myFunc0;		// does not compile, () is not valid in this context
x => myFunc1;		// valid
(x) => myFunc1;		// valid
(x, y) => myFunc2;  // valid

*************************
2. invalid cast to int from function

x => myFunc1 $ int => y;	// does not compile
(x => myFunc1) $ int => y;  // does compile

*************************
3. cannot perform '-' on object references...

x => myFunc1 - z => a;	// does not compile
(x => myFunc1) - z => a;	// does compile

*************************
4. Library inconsistencies
	There are many functions in the 'std' library that would fit better
(IMHO) in the 'math' library. Is there a particular reason why these
functions are in 'std' and not 'math'? Could this be changed (without
breaking the world of ChucK)? Any objections?

*************************
5. doesn't work, but no compiler error

null @=> Object v;
(v == null) ? true : false => int val;
<<< v, val >>>;
(v == null) ? false : true => val;
<<< v, val >>>;

*************************
6. Why would this compile, and not produce an error? What does ChucK
do with it internally? Cause trouble? While this is a mistake, ChucKy
eats it up like breakfast. I found this will testing something, and
mistakenly entered 'public' instead of 'fun'. When I tried to use
'at()', ChucK said "undefined variable/member 'at' in class/namespace
'MyClass'..." 'at()' was defined outside of the class.

public float at(time n) { return n / 1::ms; }

*************************
7. You can't use the "ChucK" form when sporking a shred...

fun void doit(float s) { }

(0.0) => spork ~ doit;	// not valid
spork ~ (0.0) => doit;	// not valid
spork ~ doit(0.0);

*************************

While some of these are important, I don't expect everything to be addressed.

Thanks again to everyone who is working on this, it is wonderful,
dispite my "complaints"...

Mike