[chuck-users] assignment (BUG?)

[Kassen]

Rob;

[2] For "immediate" data types (ints, float), => and @=> are identical: they
> move the data, not the pointer.  This is why
>        int foo;
>        int bar;
>        foo @=> bar;  // assigns 0 to bar
>        1 => foo;
> doesn't modify bar -- bar will still have a value of zero.
>
> Any disagreements?
>  <https://lists.cs.princeton.edu/mailman/listinfo/chuck-users>


Yes, sorry but I have to disagree. I don't see why I shouldn't be allowed to
have primitives reference each other; I don't see any use in two operators
accomplishing the same thing and when we'd want another type of behaviour
we'd need to encapsulate the variable in a array.

Sadly the online language specification doesn't have a great deal to say on
this but the manual states; "similarly, reference assignment duplicates a
reference to an object and assigns the reference to a reference variable.
The object itself is not duplicated. All ChucK object assignments are
reference assignments."

Sadly (for me) the ChucK parser disagrees with me and feels integers aren't
objects, to demonstrate;

Object foo;
int bar @=> foo; //this fails

True; the manual exclusively covers objects but it doesn't actually define
what should happen in this case at all. It's my opinion that either @=> and
=> should do something different  when applied to primitives or the
assignment should at the very least cause a warning. I'm leaning towards the
first option as I can see uses for it. I might have a shred that
periodically sends "float foo"  to the frequency of my instrument. I might
then later want to assign some other variable to foo so that this shred will
then send whatever that variable holds to this frequency.

The chuck operator "=>" is "masively overloaded" and that's a good thing
(hopefully) but it makes no sense to me to also overload "@=>" to also mean
"=>" under certain conditions. To address Hans's point, the chuck operator
can indeed be used on types that can be assigned as well; for example to
connect UGens or to chuck Events to now. These things aren't mutually
exclusive; Events and UGens can both be assigned and chucked to eachother.

Clearly there is no issue with dis-allowing certain operators on certain
objects, we can't use "%=>" on a Gain, for example. It's not clear to me why
@=> as applied to primitives is a exception here and is instead overloaded
to mean "=>". It's no huge issue but I would like to understand why it is
like it is.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090531/4ac2dcb7/attachment.html>