2008/12/11 Will Coleda via RT <[EMAIL PROTECTED]>: > On Thu Dec 11 01:51:23 2008, fperrad wrote: >> The new opcode 'box' is limited by its 3 signatures that target Float, >> Integer & String. >> I propose the 3 following new opcodes : > >> - true >> - false > > These can be approximated with: > > $P0 = box 1 > $P0 = box 0
No. On Lua, LuaNumber maps Float & Integer, LuaBoolean maps Boolean. So, with the current signature of box : $P0 = box 1 is equivalent to $P0 = new 'LuaNumber' set $P0, 1 but I want a LuaBoolean, because I want respect the precise rules of coercion for arithmetic operations. The expected behavior with a LuaNumber containing 1 and with a LuaBoolean containing 1 is not same. On WMLScript, WmlsInteger maps Integer, WmlsBoolean maps Boolean So, $P0 = box 1 is equivalent to $P0 = new 'WmlsInteger' set $P0, 1 but I want a WmlsBoolean. > > I know you'll end up with an Integer (or, perhaps, a LuaInt) instead of > a Boolean here. That doesn't work? > >> - undef or nil (less Perlish) > > undef and null are two different things in parrot, but we do have an > opcode for one of them, at least: > > $P0 = null > >> After some experiments with bytecode translation, >> in WMLScript (r33655) and in Lua (r33760), >> it seems obvious that we need them. > > Can you explain why? > With the opcode 'box', I could rewrite the generation of : - ConstantInteger - ConstantFloat - ConstantString but not : - ConstantBoolean - ConstantNil That's seems not homogene. >> François. > > > -- > Will "Coke" Coleda > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
