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

[François PERRAD]

# New Ticket Created by François PERRAD
# Please include the string: [perl #61286]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=61286 >


The new opcode 'box' is limited by its 3 signatures that target Float,
Integer & String.
I propose the 3 following new opcodes :
- true
- false
- undef or nil (less Perlish)

After some experiments with bytecode translation,
in WMLScript (r33655) and in Lua (r33760),
it seems obvious that we need them.

François.

[Francois Perrad]

Post by François PERRAD
The new opcode 'box' is limited by its 3 signatures that target Float,
Integer & String.
- true
- false

$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?

Post by François PERRAD
- undef or nil (less Perlish)

undef and null are two different things in parrot, but we do have an
$P0 = null

Post by François PERRAD
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.

Post by François PERRAD
François.

--
Will "Coke" Coleda
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Will Coleda]

On Thu, Dec 11, 2008 at 11:10 AM, François Perrad

Post by Francois Perrad

Post by François PERRAD
The new opcode 'box' is limited by its 3 signatures that target Float,
Integer & String.
- true
- false

$P0 = box 1
$P0 = box 0

No.
On Lua, LuaNumber maps Float & Integer, LuaBoolean maps Boolean.
$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?

Post by François PERRAD
- undef or nil (less Perlish)

undef and null are two different things in parrot, but we do have an
$P0 = null

Post by François PERRAD
After some experiments with bytecode translation,
in WMLScript (r33655) and in Lua (r33760),
it seems obvious that we need them.

Can you explain why?

- ConstantInteger
- ConstantFloat
- ConstantString
- ConstantBoolean
- ConstantNil
That's seems not homogene.

Post by François PERRAD
François.

As I understand it, box is designed to deal /only/ with promoting the
3 basic register types (SIN) to PMCs of the appropriate HLL type (just
like autoboxing in PCC), not to provide a way to promote literal
values for arbitrary core PMCs. So the discontinuity is that not every
core PMC has a corresponding register type.

I think a more general approach might be to have an opcode that
combined 'new' and 'assign'. You could even have it respect the HLL
mappings if present.

$P1 = new_init 'LuaBoolean', 1 # explicitly pick a type.
$P3 = new_init 'String, 'good luck' # this type is overridden by the
HLL, get a LuaString as a result.

But ISTR this was shot down by Chip some time ago, and what little
support there is for it (new_from_string) is slated to be removed.

(IAN The Architect)

[Chromatic]

Post by Will Coleda
As I understand it, box is designed to deal /only/ with promoting the
3 basic register types (SIN) to PMCs of the appropriate HLL type (just
like autoboxing in PCC), not to provide a way to promote literal
values for arbitrary core PMCs. So the discontinuity is that not every
core PMC has a corresponding register type.

Yes.

Post by Will Coleda
I think a more general approach might be to have an opcode that
combined 'new' and 'assign'. You could even have it respect the HLL
mappings if present.

If Lua has dynops, this is easy. If Lua doesn't have dynops, this could
easily be a function.

-- c

[Patrick R. Michaud]

Post by François PERRAD
The new opcode 'box' is limited by its 3 signatures that target Float,
Integer & String.
- true
- false

$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.

Post by François PERRAD
- undef or nil (less Perlish)

undef and null are two different things in parrot, but we do have an
$P0 = null

And the other is simply

$P0 = new 'Undef'

Post by François PERRAD
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