[perl #61286] [PATCH][PROPOSAL] box complements

Will Coleda via RT parrotbug-followup at parrotcode.org
Tue Feb 10 05:09:30 UTC 2009


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


More information about the parrot-dev mailing list