On Fri Dec 19 15:09:09 2008, pmichaud wrote: > On Thu, Dec 11, 2008 at 06:19:14AM -0800, Will Coleda via RT wrote: > > 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 > > Or, as Rakudo handles it: > > $P0 = get_hll_global ['Bool'], 'True' > $P0 = get_hll_global ['Bool'], 'False' > > The reason for "box" going to Integer/Float/String is because these > correspond directly to the int/num/string registers in Parrot, and > also to mimic what happens when doing a subroutine call that > autoboxes int/num/string, or certain vtable functions. > > > > - 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 > > And the other is simply > > $P0 = new 'Undef' > > > > After some experiments with bytecode translation, > > > in WMLScript (r33655) and in Lua (r33760), > > > it seems obvious that we need them. > > > > Can you explain why? > > I agree -- without a clear use case for why these need to be > opcodes, and keeping my "let's have fewer opcode, not more" hat > firmly in place, I don't see the utility of adding these without > some specific use cases. > > Pm > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Per allison[1], rejecting this ticket. http://irclog.perlgeek.de/parrot/2009-02-10#i_896625 -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
