On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg <rossb...@google.com>wrote:
> On 2 April 2014 20:26, Mark S. Miller <erig...@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. > They can, in theory - for the sake of argument, let's define "weak reference to fat pointer" to be "weak reference to its backing store + offset" (this is probably even fairly efficiently implementable). The question is, is this a desired semantics, and as we discussed above, it is clearly not. "True JS object" with generative identity seems to be a nice demarcation line for any notion of weak reference that we have (admittedly, we do not have the notion of weak reference per se in the spec, only weak maps, but willy-nilly the programmers will reason of them in terms of weak references). > > >> - 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. > Correct, yes - I think Mark says the same thing when he says "the implications are tricky". "Passing transparently between vats, address spaces, and machines" must be a non-goal for value objects as proposed. That's also how I read "uvalues have a prototype ... when transmitted between realms, uvalues retain this link" - among other things, it means that uvalues from different realms are never equal (since their prototype links are different by virtue of belonging to different realms). Dmitry
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
