es-discuss Digest, Vol 41, Issue 9

Leo Meyerovich lmeyerov at gmail.com
Sat Jul 3 23:58:00 PDT 2010 

... and while it might be unclear from my tone, I've repeatedly hit pain points weak references, so I'm for an encoding getting in. It's a big deal for proper frameworks & DSL design.

The dictionary approach was nice in that it supports weak references (a singleton collection) and provides object->value mapping in one small API, but from a semantics / design perspective, it's not very orthogonal. E.g., a weak reference option and an actual object->value dictionary can be used to create a weak dictionary with an equally (asymptotically, at least) sized heap.

- Leo



On Jul 3, 2010, at 11:34 PM, Leo Meyerovich wrote:

> 
> On Jul 3, 2010, at 10:50 PM, Mark S. Miller wrote:
> 
>> On Sat, Jul 3, 2010 at 10:27 PM, Leo Meyerovich <lmeyerov at gmail.com> wrote:
>> Is object identity the inverse of hash? So myObj == identity(hash(myObj))?
>> 
>> No. There is not and must not be an identity function which turns data into access. This would destroy the most important safety property of JavaScript, that object references are not forgeable.
>> 
> 
> 
> I'm with you there. Was surprised when I thought it was being proposed in that way! 
> 
> 
>> Also, hashes can collide. So the most you get is the conventional:
>> 
>> * if (typeof x !== 'number' && x === y) then hash(x) === hash(y)
>> 
>> * if (hash(x) === hash(y)) then it is likely but not guaranteed that x === y.
>> 
> 
> Object hashes seems like a misnomer in this case as it seems fine to require them not to collide. I don't know what happens in JS when you use more than 32 bits or 64 bits of references, but I'd expect a similar out-of-memory restriction for a for-free (hashless) implementation ;-) Anyways, red herring and I probably don't know enough about serialization, object persistence, etc. to discuss what a useful API would be here for expected use case in a helpful way.
> 
>>  
>> Then weakly keyed or mapped tables are obviously possible, even though they'll have to be manually cleared of expired values.
>> 
>> Unfortunately, while this may support encoding weak mappings, I suspect a feature like that is used more often in frameworks than application code, so there might be a big penalty. ActionScript 3 introduced a Dictionary object that performs weak mappings -- perhaps that can be used to find a concrete comparison point. i don't know how this is distinct from 'ephemeron' tables, so I might be missing something.
>> 
>> I don't know ActionScript or its Dictionaries.
> 
> http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html
> 
> I no longer have asc installed so cannot directly check when they write 'weakKeys'  whether they really meant weak keys or weak mappings (so both key & value are weak); the description reads both ways. It might be useful to analyze how it is used (or not) before suggesting a deviation from it. This is not from the perspective of weak dictionaries being good but something that can be learned from. 
> 
> FWIW, I believe ActionScript's use introduces non-determinism to the language: iterating over the dictionary can reveal an object that is only weakly referenced if the GC hasn't run yet. At this point, the JS semantics guys might want to chime in -- it simplifies requirements on GC implementation, but I don't know how it changes program analysis (e.g., an escape analysis would simply be conservative there). Just as introducing forgeable references breaks encapsulated reasoning, this might also interact oddly with some useful characterizations of JS. Unfortunately, the semantically clean alternative, forcing a reachability check, isn't decidable.
> 
> - Leo
> 
> 
> 
>>  
>> 
>> - Leo
>> 
>> 
>> 
>> On Jul 3, 2010, at 12:00 PM, es-discuss-request at mozilla.org wrote:
>> 
>>> Send es-discuss mailing list submissions to
>>> 	es-discuss at mozilla.org
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> 	https://mail.mozilla.org/listinfo/es-discuss
>>> or, via email, send a message with subject or body 'help' to
>>> 	es-discuss-request at mozilla.org
>>> 
>>> You can reach the person managing the list at
>>> 	es-discuss-owner at mozilla.org
>>> 
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of es-discuss digest..."
>>> Today's Topics:
>>> 
>>>   1. Re: We need to name "EphemeronTable" (was: Do we need an
>>>      experimental	extension naming convention?) (Brendan Eich)
>>>   2. Re: We need to name "EphemeronTable" (was: Do we need an
>>>      experimental	extension naming convention?) (P T Withington)
>>> 
>>> From: Brendan Eich <brendan at mozilla.com>
>>> Date: July 2, 2010 10:01:26 PM PDT
>>> To: Mark S. Miller <erights at google.com>
>>> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>, Erik Arvidsson <erik.arvidsson at gmail.com>
>>> Subject: Re: We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)
>>> 
>>> 
>>> On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote:
>>> 
>>>> I'm also in favour of a regular Map and Set. Also a dense List (i.e., what we might have otherwise called an Array :(.) However, the history of oo class libraries shows collection libraries to be a tarpit, so I'm unwilling to take the lead on this issue. If someone else would like to, so long as they keep it bloody simple (i.e., not like Java, Smalltalk, or STL), that'd be great. Even the E collections <http://erights.org/elang/collect/tables.html> <http://erights.org/javadoc/org/erights/e/elib/tables/EMap.html>, where I could make them as simple as I wished, got way too complicated -- more complicated than I would find acceptable.
>>>> 
>>>> Great designers of extraordinarily simple expressive APIs, please step forward!
>>> 
>>> Ideally TC39 should not standardize or design anything not already proven and popular (if not dominant) in the field. The problem is no one can make practicaly O(1) collections without Object.hashcode and Object.identity.
>>> 
>>> Say we add hashcode and identity. Then we'll have to wait a while, Could we bootstrap Set, Map, and WeakMap and call it enough? I think so.
>>> 
>>> "Dense List" could be added but implementations are optimizing for dense arrays already. I think this one is too close to Array to be worth it, but without a detailed design that's just my gut reaction. FWIW.
>>> 
>>> /be
>>> 
>>> 
>>> 
>>> From: P T Withington <ptw at pobox.com>
>>> Date: July 3, 2010 4:47:50 AM PDT
>>> To: Brendan Eich <brendan at mozilla.com>
>>> Cc: "Mark S. Miller" <erights at google.com>, Erik Arvidsson <erik.arvidsson at gmail.com>, "es-discuss at mozilla.org" <es-discuss at mozilla.org>
>>> Subject: Re: We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)
>>> 
>>> 
>>> Coming late to the party:  'alias' might be intuitive (from it's dictionary definition and use in filesystems as a non-preserving way to give an alternate name).
>>> 
>>> On 2010-07-03, at 00:57, Brendan Eich wrote:
>>> 
>>>> On Jul 2, 2010, at 8:58 PM, David Herman wrote:
>>>> 
>>>>>> Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
>>>>> 
>>>>> +1
>>>>> 
>>>>> I <3 WeakMap.
>>>> 
>>>> The Force is strong with WeakMap! ;-)
>>>> 
>>>> +1 or more
>>>> 
>>>> /be
>>>> 
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>>     Cheers,
>>     --MarkM
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100703/14b5f555/attachment-0001.html>

More information about the es-discuss mailing list