Here's another oddity. The following file: --------------------------------------- // file: ouroboros.ck class Ouro { Boros @ boros; fun void set_boros(Boros boros) { <<< this.toString(), "set_boros(", boros.toString(), ")" >>>; boros @=> this.boros; } } class Boros { Ouro @ ouro; fun void set_ouro(Ouro ouro) { <<< this.toString(), "set_ouro(", ouro.toString(), ")" >>>; ouro @=> this.ouro; } } --------------------------------------- gets a compile-time error: --------------------------------------- r% chuck ouroboros.ck [ouroboros.ck]:line(5): class 'Boros' has no member 'toString' [ouroboros.ck]: ...in function 'set_boros' --------------------------------------- This is odd, since (AFAIK) toString() is defined on the Object class, and all classes inherit from Object. If I remove the toString() call on boros as below, it compiles without error. Note chat ChucK has no problem compiling ouro.toString() in function 'set_ouro': --------------------------------------- // file: ouroboros.ck class Ouro { Boros @ boros; fun void set_boros(Boros boros) { <<< this.toString(), "set_boros(", boros, ")" >>>; boros @=> this.boros; } } class Boros { Ouro @ ouro; fun void set_ouro(Ouro ouro) { <<< this.toString(), "set_ouro(", ouro.toString(), ")" >>>; ouro @=> this.ouro; } } --------------------------------------- Is this because Boros is a forward reference? And is this not a bug? - Rob
Robert; Is this because Boros is a forward reference? And is this not a bug?
Actually I'm quite surprised you got the second version to compile at all. You are defining a chicken as something that comes out of a egg, while a egg is something that comes out of a chicken. On behalf of your cpu and ram I suggest you stop doing this; if every Ouro contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros(which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros ( and so on )))))))))))) then there will be trouble. Yours, Kas.
Kas:
Actually, an ouro contains a *reference* to a boros and vice versa.
There nothing bestial about that -- in fact it's a useful and often
appropriate construct.
You're just trying to goad me into writing that wiki entry on ChucK
references, aren't you? :)
-Rob
Sent from my iPhone
On Oct 2, 2009, at 4:06 PM, Kassen
Robert;
Is this because Boros is a forward reference? And is this not a bug?
Actually I'm quite surprised you got the second version to compile at all. You are defining a chicken as something that comes out of a egg, while a egg is something that comes out of a chicken.
On behalf of your cpu and ram I suggest you stop doing this; if every Ouro contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros(which in turn contains a Ouro (which in turn contains a Boros (which in turn contains a Ouro (which in turn contains a Boros ( and so on )))))))))))) then there will be trouble.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Rob; Actually, an ouro contains a *reference* to a boros and vice versa. There
nothing bestial about that -- in fact it's a useful and often appropriate construct.
Ok, so what you are doing here is creating a reference that can later be set to reference a actual object instance external to the class? Ok, that's quite different. You're just trying to goad me into writing that wiki entry on ChucK
references, aren't you? :)
Hmmmm, actually now that I looked the manual does cover references (chapter 13). I think I skimmed over that section before as it made zero sense to me back then :-). My oops on both counts. Kas.
references, aren't you? :)
I would also like to thank you for this hint in the right direction and making me look over the manual section again. I now see how "sprinkling @ signs" there and there is not "magic fairy dust" (though they did seem like
Robert; You're just trying to goad me into writing that wiki entry on ChucK that at the time to Mike and me) but instead worked by creating additional references which helped fight the buggy reference count. It all looks quite understandable all of a sudden. One thing that *still* bugs me is something I saw back then that looked roughly like this; class Foo { //loads of stuff } fun Foo fooFighter( Foo @ input) { //stuff return something; } The bit that still casts its tentacled shadows over my restless nights is the "Foo @ input" thing. Why on earth would we ever do that? There must be a valid reason to it because according to Mike that bit came from Spencer so there must be a reason for it that I simply don't get. Kas.
On 3 Oct 2009, at 00:39, Robert Poor wrote:
This is odd, since (AFAIK) toString() is defined on the Object class, and all classes inherit from Object. If I remove the toString() call on boros as below, it compiles without error.
It seem to be a bug. On the one hand the program can be simplified to: class A { B @ b; <<< "B:", b.toString() >>>; } class B {} with the error still there. But the following compiles: class A { B @ b; <<< "B:", b.k >>>; } class B { int k; } So chuck seems supposed to be able to handle forward references, but not working for toString(). Hans
participants (3)
-
Hans Aberg -
Kassen -
Robert Poor