set_pmc + setref/deref: anyone using them?
Matt Diephouse
setref and deref opcodes were removed? Note that if you are using set
_pmc but are not using assign_pmc, then you may not be
inconvenienced because right now the default assign_pmc vtable calls set_pmc.
These opcodes were added to make transparent references
possible, but they weren't really specced out or desisign
ed properly. As such, they're a little broken and we'd like to remove them.
--
Matt Diephouse
http://matt.diephouse.com
Allison Randal
Removing opcodes because they're a little broken sounds odd. What
problem were they designed to solve, and what's our replacement strategy
for solving the problem?
Allison
Matt Diephouse
As I understand things, the set_pmc vtable function has a long and
messy history. The assign_p_p opcode originally called set_pmc. A
(long) while back, it was changed to call a new assign_pmc vtable
function instead. But to help transition, the default assign_pmc
vtable function called set_pmc -- and this is still the case today.
That prompted me to look at removing set_pmc in the first place.
set_pmc/assign_pmc at least need to be decoupled.
It looks like after assign_pmc, a new opcode, set_ref_p_p was added
that called set_pmc. The use case is for transparent references: PMCs
that enforce read-only-ness and STM references. The problem with
having a vtable that does is is that the referenced PMC can't use this
vtable: the transparency breaks down.
Chip and I concluded at the hackathon that this is broken and in need
of redesign. I threw out the idea of not being able to change the
refenced pmc, but simply creating a new reference pmc when this needs
to change:
.local pmc obj, ref
obj = new .Whatever
ref = new .Ref, obj
...
ref = new .Ref, obj2
This mostly steps around things, but it won't let you alias a
reference (with Tcl's aliasing semantics, anyway) because morph and
assign are also vtable functions, so you can't assign a new pmc or
morph to a different pmc type that will let you.
There needs to be some way to reach behind the curtain if transparent
references are really going to work. AFAICT, that means redesigning
from scratch because of the fundamental problems with the current
approach.
Of course, I'm not the designer and I don't care that much about this
particular issue, so I won't put up a fight if you say you'd like to
keep things as they are for now (with the exception of separating
set_pmc from assign_pmc).
Allison Randal
>
> As I understand things, the set_pmc vtable function has a long and
> messy history. The assign_p_p opcode originally called set_pmc. A
> (long) while back, it was changed to call a new assign_pmc vtable
> function instead. But to help transition, the default assign_pmc
> vtable function called set_pmc -- and this is still the case today.
Let's take a step backward. The original intent was that set_pmc would
replace a container PMC with another container PMC, while assign_pmc
would only change the value of one PMC to the same value as another PMC.
Arguably the names are poorly chosen, since they've caused confusion
over the years (resulting in odd implementation choices), but the
fundamental distinction is valid.
> That prompted me to look at removing set_pmc in the first place.
> set_pmc/assign_pmc at least need to be decoupled.
Agreed they need to be decoupled (and possibly renamed).
> It looks like after assign_pmc, a new opcode, set_ref_p_p was added
> that called set_pmc. The use case is for transparent references: PMCs
> that enforce read-only-ness and STM references. The problem with
> having a vtable that does is is that the referenced PMC can't use this
> vtable: the transparency breaks down.
Agreed.
> Chip and I concluded at the hackathon that this is broken and in need
> of redesign. I threw out the idea of not being able to change the
> refenced pmc, but simply creating a new reference pmc when this needs
> to change:
>
> .local pmc obj, ref
> obj = new .Whatever
> ref = new .Ref, obj
> ...
> ref = new .Ref, obj2
>
> This mostly steps around things, but it won't let you alias a
> reference (with Tcl's aliasing semantics, anyway) because morph and
> assign are also vtable functions, so you can't assign a new pmc or
> morph to a different pmc type that will let you.
Could you write this up into a more complete proposal? I've got a
general sense of where you're headed, but the
positives/negatives/compromises are all in the details.
Thanks,
Allison