Part 3 of meeting notes

Brendan Eich brendan at mozilla.org
Tue Jun 2 16:31:19 PDT 2009


On Jun 2, 2009, at 4:20 PM, Mark S. Miller wrote:

> On Fri, May 29, 2009 at 7:13 PM, Brendan Eich <brendan at mozilla.org>  
> wrote:
> On May 29, 2009, at 4:46 PM, Waldemar Horwat wrote:
>
> We'd want a Name n to be garbage-collected if the only use of n is  
> in hidden places such as x[n].  That would also collect y if it's  
> not reachable from anywhere else.
>
> Really? What about Name instance n makes its identity persistent  
> only while in-memory? Suppose it could be pickled, or better yet, a  
> lexical binding equated to it per the
>
> http://wiki.ecmascript.org/doku.php?id=strawman:names
>
> proposal in a function is declared, and the function is pickled,  
> then serialized to a secure storage channel. Then the in-memory  
> references to n other than x[n] -- but not references to x -- all go  
> away, and the GC runs.
>
> It is required that Name instances never equate to any string. But  
> that does not mean they couldn't be pickled and unpickled. It does  
> not mean they have unique name identity only while in memory.
>
> There should be no requirement that a proxy or ephemeron keeping n  
> alive must remain indefinitely in-memory just so the pickled name  
> can be unpickled later and used to access x[n] where x remained  
> alive the whole time. But under Mark's proposal, that would be  
> required, or else x[n] (aka n[x]) would go away -- become undefined  
> -- behind the back of the storage channel user.
>
> I objected at the meeting this semantic reductionism, and I still  
> do. Private names are not the same as ephemerons.
>
> Brendan, I have now read that strawman page carefully and then  
> reread your email several times. I am utterly confused. I see no  
> connection between the two. If the pickling above is transparent and  
> orthogonal, then it is a semantics-free part of the implementation,  
> like virtual memory, and is unproblematic.

It can't be transparent. If there exists such pickling of names, then  
names are not equivalent to ephemerons.

Ephemerons are great, but they are about garbage collection, liveness.  
Names are about private properties. Semantically there's no required  
connection. Semantic reductionism to the contrary notwithstanding! :-P


> If it is not transparent, do you imagine it being implemented in  
> JavaScript?

UUIDs, in the system with the name-pickling extension.


> If so, then I don't understand your first step: "the function is  
> pickled". Functions are encapsulated, so JavaScript code can't  
> obtain enough information from one to pickle it.

The VM can, and some including SpiderMonkey already do.


> The strawman page says nothing about pickling or any related issue.  
> I see nothing on the strawman page that conflicts with my proposed  
> reduction to ephemerons. What am I missing?

The proposal is a sketch, incomplete, to be worked out by dialog  
including this thread.

My post put forth a thought experiment, about pickling private names  
or functions binding them, to break the equivalence that you see  
between names and ephemerons, showing that the two are not identical.  
Names and ephemerons are equivalent only if you constrain names  
against the extension in the thought experiment, which could certainly  
be implemented using UUIDs.

Now, why should we constrain things that way? Why must  we reduce the  
semantics to make the equivalence mandatory, forcing the identity?

As Allen pointed out at the meeting, semantics that can be separated  
in order to serve different use-cases, however a particular system  
might implement them using common mechanism, should be separated in  
the spec. We don't specify loops in terms of tail calls, assuming we  
have tail calls.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20090602/27148d4a/attachment.html>


More information about the es5-discuss mailing list