[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