#787: add vtables for: get_pmc_keyed{_int,_str,}_lvalue ; and similarly for
slice
-------------------+--------------------------------------------------------
Reporter: japhb | Type: todo
Status: new | Priority: normal
Milestone: | Component: core
Version: 1.3.0 | Severity: medium
Keywords: | Lang:
Patch: | Platform: all
-------------------+--------------------------------------------------------
Comment(by pmichaud):
Replying to [comment:3 allison]:
> Parrot doesn't need to have a vtable entry for every HLL operation. This
one unpacks
> pretty cleanly to a series of opcodes (fetch the element/slice, assign
to it, store it back).
This response is at the least very misleading, so I'll try to clarify
things a bit here.
To assign to an element of an aggregate, the basic sequence is "fetch the
element PMC, assign to it". There's no "store it back" operation -- the
PMC element retrieved by the fetch is still bound in the aggregate, so
assigning a new value to that PMC effectively changes it in the aggregate.
In code, the basic sequence would be:
{{{
$P0 = aggregate[key]
assign $P0, value
}}}
The tricky part is when someone wants to assign to an element of an
aggregate that doesn't already exist. In this case, "fetch the element"
returns NULL, so a new PMC has to be created and bound into the aggregate
(i.e., vivified):
{{{
## HLL: @aggregate[$key] = $value
$P0 = aggregate[key]
unless null $P0 goto vivified
$P0 = new ['Undef']
aggregate[key] = $P0
vivified:
assign $P0, value
}}}
For a non-vivifying fetch of an element, we still want to avoid the NULL
that comes back from the aggregate but we don't want to make it permanent,
so we get:
{{{
## HLL: say @aggregate[$key]
$P0 = aggregate[key]
unless null $P0 goto vivified
$P0 = new ['Undef']
vivified:
say $P0
}}}
I think this is what the original posting was getting at -- there are
vivifying (lvalue) and non-vivifying (rvalue) forms of "fetch an element",
and Parrot's opcodes, vtables, and built-in types don't really support the
distinction well. We can potentially improve things with specialized
opcodes, proxy elements in aggregates, and/or references (Rakudo ends up
doing all three of these) -- the question is whether any of them belong in
"core Parrot" to provide a common interface that can be shared by all
HLLs.
TT #1138 posits the creation of a "vivify" opcode to address the "rvalue
fetch" problem, but it doesn't address the issue of "lvalue fetch".
Pm
[update: I've since proposed separate "fetch" and "vivify" opcodes for
generic rvalue and lvalue fetch -- see TT #1138.]
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/787#comment:5>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
