typed objects and value types

Andreas Rossberg rossberg at google.com
Wed Apr 2 23:26:18 PDT 2014


On 2 April 2014 20:26, Mark S. Miller <erights at google.com> wrote:
> We could specify that WeakMaps can use typed objects as keys. The current
> discussion in your article confuses semantics with implementation when it
> speaks of typed objects comparing structurally. Typed objects have identity,
> characterized by the four-tuple you explain. Just as all the bits of a thin
> pointer are significant when comparing two thin pointers to see if they
> point at the same semantic object identity, so are all the bits in your fat
> pointer significant. Don't get confused by the bits in the pointer to the
> fat pointer, when the fat pointer happens to be boxed.

I'm not sure I agree with your notion of identity on pointers here. It
doesn't make sense to me, semantically, to characterise structural
(fat) pointers as having identity, just because their pointees have.
(Or in other words, tuples do not acquire identity just because some
of their components are values with identity. This is mixing up
domains.)

In any case, from the low-level perspective of the GC, a fat pointer
definitely is an object separate from the buffer it points to (though
it strongly references this buffer). Weak maps currently work by
making the references to their keys weak. But that would simply be
incorrect in the case where a key is a fat pointer -- because of its
structural equality, an equivalent pointer can be recreated. It is
unclear to me how weak maps could (efficiently) be extended to support
this particular notion of reverse transitive weakness that you allude
to.

>> - uvalues have a prototype linked to their def'n
>>   - the syntax 'uvalue.foo' can be used to access members of this
>> prototype
>
> +1.
>
>>   - when transmitted between realms, uvalues retain this link
>
> A uvalue is deeply uvalue only when its prototype and all the methods found
> there are uvalues. Although this is the case for E, the implications for JS
> are, ahem, tricky. If they're not deep in this way, then they can't be
> passed transparently between vats, address spaces, and machines.

How can a prototype possibly be a fully structural value in
JavaScript? Especially, since the language has this great feature of
making all functions objects with identity?

On the other hand, I also don't see how uvalues can work without a
prototype link. So it seems that it's simply impossible to make them
transparently transferable between vats in the way you desire (and I
would, too). It seems that JavaScript is actively hostile to that
idea.

/Andreas


More information about the es-discuss mailing list