Simon Glover <[EMAIL PROTECTED]> wrote: > This code:
> new P0, .Undef > new P1, .Undef > eq P0, P1, L1 > print "not " > L1: print "ok\n" > end > prints "not ok". Should it? That depends ;) > ... If Parrot considers every Undef PMC to > be distinct, it's going to make tasks like comparing arrays with > large numbers of undefined elements much fiddlier than it should be. Yep. Currently there is no chance to change that. The semantics of unary and binary operators need an existing destination PMC. Usual code for infix '+' is: $P0 = new Undef $P0 = a + b So *currently* the Undefs have to be distinct. But as outlined several times, the current behavior isn't that one that HLLs have. Overloaded operators are functions (multi subs) that return new values. For consistency we really should do the same with operators. Additionally we currently can't have singletons as a result of an operator. This isn't only a serious restriction but can additionally be much more expensive then the Undef issue. We should have: $P0 = cmp a, b with the return result being a singleton True of False PMC. Now a HLL compiler is forced to emit: $I0 = cmp a, b $P0 = new Boolean $P0 = $I0 which is three times the code size and it needs a new PMC for each compare. > For instance, the fact that Undef != Undef means that this code: > new P0, .ResizablePMCArray > set P0, 1 > clone P1, P0 > eq P0, P1, L1 > print "not " > L1: print "ok" > print "\n" > end > prints "not ok". This is a different issue. The ResizablePMCArray doesn't properly inherit the is_equal multi method from FixedPMCArray and as far as I can see, there is no Undef involved at all. Empty array slots are filled with PMCNULL, which is a singleton. The example works for FixedPMCArray. > Simon leo
