Fellow ChucKists, Either we have a bug or I don't understand assignment (quite possibly both are the case, I won't rule that out). Consider this; int foo, bar; foo @=> bar; //alternately, this gives the same result //bar @=> foo; 1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>; I was expecting both to be 1 but here bar is 0 (Linux, miniAudicle modified to host 1.2.1.2). The following behaves as I expect it to; int foo, bar; 1 => foo; foo @=> bar; 1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>; Before I start bothering everyone with my ideas on assignment as it applies to UGens I'd like to be clear on what assignment does exactly and whether this is proper behaviour. Yours, Kas.
I'm not the expert, but I thought that the ChucK rules for assignment are: [1] For "reference" data types, (arrays and objects), @=> assigns the pointer, not the data. This is why Object foo; Object @bar; foo @=> bar; creates an "alias" of foo in bar. When you manipulate either one and you are operating on the same object. [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? - r On 31 May 2009, at 13:42, Kassen wrote:
Fellow ChucKists,
Either we have a bug or I don't understand assignment (quite possibly both are the case, I won't rule that out). Consider this;
int foo, bar;
foo @=> bar;
//alternately, this gives the same result //bar @=> foo;
1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>;
I was expecting both to be 1 but here bar is 0 (Linux, miniAudicle modified to host 1.2.1.2). The following behaves as I expect it to;
int foo, bar;
1 => foo; foo @=> bar;
1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>;
Before I start bothering everyone with my ideas on assignment as it applies to UGens I'd like to be clear on what assignment does exactly and whether this is proper behaviour.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
--: Robert Poor e: robert.poor@nbt-ventures.com p: +1 617 818 5115 b: http://blog.nbt-ventures.com --: This message and the information it contains are the proprietary and confidential property of NBT Ventures and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. --:
On 31 May 2009, at 23:11, Robert Poor wrote:
I'm not the expert, but I thought that the ChucK rules for assignment are:
[1] For "reference" data types, (arrays and objects), @=> assigns the pointer, not the data. ... [2] For "immediate" data types (ints, float), => and @=> are identical: they move the data, not the pointer. ... Any disagreements?
I just intended say the same thing, but you were faster :-). Only that I would call the first a reference type, and the second a data type. And I think => is illegal on reference types. Hans
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.
I don't think there are any satisfying reasons for the current behavior. File native type references (int @ x) as a feature request if it's not already. :) I think @=> is an unnecessary operator. I like the description from way back that the "@" means "please." -- Tom Lieber http://AllTom.com/
Tom; I don't think there are any satisfying reasons for the current
behavior. File native type references (int @ x) as a feature request if it's not already. :)
Well, yes. I'm waiting for Ge though, there may be good reasons for this that link to future plans but right now I see no point to the current situation.
I think @=> is an unnecessary operator. I like the description from way back that the "@" means "please."
That was likely my comment. That was mostly related to Mike's attempts to do fairly odd/advanced things. In that code were things (I believe introduced by Spencer?) that went like; fun foo_type ( variable_name @ bar_type) { //code goes here } I still have no idea what that "@" was doing there but I'm quite sure that isn't documented usage. I gave ignoring that a good go. I do think "@=>" has a real uses that can't be had otherwise and I still believe that and some extra casts here&there are symptoms of the current type-system issues. Those needn't be related to the question of whether or not a int is a object and whether we should be able to assign to them. I'm open to opinions on the use of @=> though, we do seem to use it mainly to get around issues and I could imagine more versatile alternatives in some cases. Oh, well, here be dragons and dragons yield lots of XP so this must be good. Kas.
FWIW, I did stumble over an example where => and @=> differ. I typed noisemakers[x] => Noisemaker @ current_noisemaker; which tried to patch noisemakers[x] into a null unit generator, producing some strange runtime error. Of course what I intended was: noisemakers[x] @=> Noisemaker @ current_noisemaker; So sometimes you just have to ask "please" to get ChucK to do the right thing. - Rob On 31 May 2009, at 15:37, Tom Lieber wrote:
I don't think there are any satisfying reasons for the current behavior. File native type references (int @ x) as a feature request if it's not already. :)
I think @=> is an unnecessary operator. I like the description from way back that the "@" means "please."
-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Rob;
So sometimes you just have to ask "please" to get ChucK to do the right thing.
That's not quite the same. In your case here the "@" makes a difference between connecting and assigning in UGens (which I take "noisemaker" to refer to). that's quite different from the distinction between; return my_instance; and; return my_instance @ new My_type; ...or some such construction just to make a function parse. I think I saw this happen fairly literally but I'd have to dig up the details. I suspect that in many case this has to do with constructs like arrays not always properly preserving the type in every context while a assignment here and there puts the parser (and at times VM) "back on track". I do believe this to be different but maybe I misunderstood your example. Kas.
Hi This kind of things seem to be due to a lack of development in documentation and/or language. I'm worried. Is anyone developing Chuck? greetings Lucas
2009/5/31 Lucas Samaruga
This kind of things seem to be due to a lack of development in documentation and/or language. I'm worried. Is anyone developing Chuck?
Yeah, but its release cycles are getting longer. There's going to be an organized hacking session to get the next release out in the next several months or something like that. Hey cool, check this out: http://web.archive.org/web/*/http://chuck.cs.princeton.edu/release/ (It looks like Archive.org gave up on it early on in 2008, but it's only missing the latest release.) -- Tom Lieber http://AllTom.com/
Tom;
Yeah, but its release cycles are getting longer. There's going to be an organized hacking session to get the next release out in the next several months or something like that.
Yeah. From what I gather people have been hard at work and there have been updates to the CVS but no actual releases. I'd rather have seen a "release early, release often" cycle. I feel it's clear the community is quite good at stress-testing new things so even for a single update (I'm thinking of file IO here at the moment) a release might be worthwhile. I suspect it's Ge who has to make that that call and that he's been unable to do so due to the crazy situation around Smule. I don't mean that as criticism *at all* because I'm so happy for Ge, we should all grab our chances while we have tthem. People can get a version with some updates from CVS but personally I'd rather not and I'd rather stay compattible in the interest of non-confusing discussions on the list; some of the concepts we are dealing with are complex enough as they are. For another thing this release has been interesting to me because we got some new techniques from the community that basically count as new features to me, I'm particularly thinking about casting "up and down" and having what amounts to "duck typing" that way, provided we are sure of what we are doing. Still, it might be a good idea to think about enabling other people besides Ge to push out releases when some new feature is done. I suppose stability is a issue there but let's remember that we have a community that's quite good at finding bugs and issues, then pinpointing them. I can guarantee the DEV's that we are much better at thinking of things they hadn't considered than they are ;¬) and in the bad old days even replacing code would crash and we still had fun while pinpointed bugs are easy to fix. To paraphrase; safe ChucK is boring ChucK. On the other hand; we have slacked a little in adding documented bugs to the Wiki. Let's make it easer on the DEV's for these weeks/months by having all bugs in one place. Let's bring this up to date; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release Yours, Kas. PS, kindly imagine a dozen or so "IMHO's" in the above.
Lucas;
Hi
This kind of things seem to be due to a lack of development in documentation and/or language.
In this case I suppose the issue is with a disagreement on what proper behaviour is. I'd rather have a open discussion about that than have everything determined by a language specification. When the language specification was written we all had far less of a coherent idea of what ChucK was or should be than we now do. I might still have posted about this if the specifications explicitly demanded the current behaviour without a explanation of *why* it is this way. I suppose I agree with you but discussions like this will lead to developments and specifications. I might go as far as saying there will be little development if we don't debate. Yours, Kas.
Hi Kassen, all I really think the problem is simple. (Sorry if I missunderstand part of the discussion but is complicated to me understand some English styles). We have values and referencies. An in ChucK we have one assignment operator for values and other for referencies. In ChucK is not possible to create references to primitive tipes. int @i; [Untitled]:line(1): cannot declare references (@) of primitive type 'int'... [Untitled]:line(1): ...(primitive types: 'int', 'float', 'time', 'dur') The problem here (i think) is that the reference assignment operator acts like a value assignement operator too. Different is the case when the assignment opertor acts over objects (being UGens) that is the ChucK operator. We have one "massive overloaded chuck operator" and a reference assignement operator that haven't defined it behavior on primitive values. greetings Lucas El 01/06/2009, a las 10:21, Kassen escribió:
Lucas; Hi
This kind of things seem to be due to a lack of development in documentation and/or language.
In this case I suppose the issue is with a disagreement on what proper behaviour is. I'd rather have a open discussion about that than have everything determined by a language specification. When the language specification was written we all had far less of a coherent idea of what ChucK was or should be than we now do.
I might still have posted about this if the specifications explicitly demanded the current behaviour without a explanation of *why* it is this way.
I suppose I agree with you but discussions like this will lead to developments and specifications. I might go as far as saying there will be little development if we don't debate.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Lucas
I really think the problem is simple. (Sorry if I missunderstand part of the discussion but is complicated to me understand some English styles).
I think you got everything. Please tell me if something that I write is confusing to you and I'll try to write it differently. We have one "massive overloaded chuck operator" and a reference assignement
operator that haven't defined it behavior on primitive values.
Yes, as far as I can see you are right. This is no big problem but it does look a bit inconsistent and confusing to me. Maybe Tom feels differently, he seems to feel we don't need any assignment at all. I don't think I agree with that but it's a interesting idea to say the least. Yours, Kas.
El 01/06/2009, a las 19:38, Kassen escribió:
I think you got everything. Please tell me if something that I write is confusing to you and I'll try to write it differently.
No, please, is my problem to be slow reading english.
Maybe Tom feels differently, he seems to feel we don't need any assignment at all. I don't think I agree with that but it's a interesting idea to say the least.
Ah, yes, in other languages the behavior is defined by the objects and not from the operator, but a modifier (or something like that) is necessary in one of both the object or the operator. Maybe a matter of taste :-) Lucas
2009/6/1 Kassen
Maybe Tom feels differently, he seems to feel we don't need any assignment at all. I don't think I agree with that but it's a interesting idea to say the least.
Well Poor's example demonstrated that =>'s automatic dereferencing of UGen@ types for connecting UGens makes @=> necessary. -- Tom Lieber http://AllTom.com/
On 2 Jun 2009, at 06:18, Tom Lieber wrote:
Well Poor's example demonstrated that =>'s automatic dereferencing of UGen@ types for connecting UGens makes @=> necessary.
Though there is a semantic difference between referencing and copy- over (cloning), it is not a must to express it through different assignment operators. Think of files. The normals thing is to hand over a reference, but copy-over is possible, though, more less often used. So a => b; could mean to hand over reference - the normal use case, whereas for a copy-over say a.clone() => b; Hans
On Sun, May 31, 2009 at 7:19 PM, Robert Poor
FWIW, I did stumble over an example where => and @=> differ. I typed
noisemakers[x] => Noisemaker @ current_noisemaker;
which tried to patch noisemakers[x] into a null unit generator, producing some strange runtime error. Of course what I intended was:
noisemakers[x] @=> Noisemaker @ current_noisemaker;
So sometimes you just have to ask "please" to get ChucK to do the right thing.
Okay, that's a valid use case. ;p -- Tom Lieber http://AllTom.com/
On 1 Jun 2009, at 00:37, Tom Lieber wrote:
I think @=> is an unnecessary operator. I like the description from way back that the "@" means "please."
Yes, in C++ syntax, it is natural to write an assignment x = y; for both reference and copy-over data types. Some types classes which can not be copied over, like streams, just prohibit assignment. But it is cumbersome to work with - it is convenient being able to pass a reference around. Then one wants to have a GC - a reference count at least. But then it must be made explicit to the user what type the objects are. Some objects, like files, may be copied over, even though one normally does not want to do it. So there should be a clone operators for objects that admit it. And a class object may contain references, and sometimes one may want to copy those over as well, so one might want to have deep clone operator, too. Hans
participants (5)
-
Hans Aberg -
Kassen -
Lucas Samaruga -
Robert Poor -
Tom Lieber