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

On Thu, Dec 11, 2008 at 11:10 AM, François Perrad
<[email protected]> wrote:
> 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.

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)

-- 
Will "Coke" Coleda