Comments on Sept Meeting Notes

Erik Arvidsson erik.arvidsson at gmail.com
Fri Sep 27 07:52:46 PDT 2013


What's the use case for Symbol.keyFor?

On Thu, Sep 26, 2013 at 11:31 PM, Mark S. Miller <erights at google.com> wrote:
> Some other invariants:
>
> For all strings S, Symbol.for(S) === Symbol.for(S)
>
> For all Symbols R made by Symbol.for(S) for some string S
>
> Symbol.keyFor(R) === Symbol.keyFor(R) // I think this can be derived from
> previous statements, but it is late and I'm tired.
>
> For all Symbols U not made by Symbol.for(S) for any S
>
> Symbol.keyFor(U) always throws.
>
> Btw, R stands for Registered and U for Unregistered. A Symbol, once born
> unregistered, can never be registered. This perhaps plugs the communications
> channel Allen had in mind.
>
>
>
>
> On Thu, Sep 26, 2013 at 8:44 PM, Mark S. Miller <erights at google.com> wrote:
>>
>> I think an adequate registry is exactly the two static methods Allen
>> proposed:
>>
>>  Symbol.for(aString) ==> aSymbol
>>
>>  Symbol.keyFor(aSymbol) ==> aString
>>
>> where for all strings S
>>
>>  Symbol.keyFor(Symbol.for(S)) === S
>>
>> I think we've discussed this before -- it is effectively an interning
>> table for Symbols. The nice thing about it is that it is not a global
>> communications channel at all. There's no way to tell if a given string or
>> symbol has already been registered. The interning table can be weak or not
>> as the implementation prefers.
>>
>>
>>
>>
>> On Thu, Sep 26, 2013 at 7:55 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>>
>>> On Thu, Sep 26, 2013 at 7:50 PM, Brendan Eich <brendan at mozilla.com>
>>> wrote:
>>>>>
>>>>> Mark S. Miller <mailto:erights at google.com>
>>>>> September 26, 2013 7:45 PM
>>>>>
>>>>>
>>>>> On Thu, Sep 26, 2013 at 7:12 PM, Brendan Eich <brendan at mozilla.com
>>>>> <mailto:brendan at mozilla.com>> wrote:
>>>>>
>>>>>         Kevin Smith <mailto:zenparsing at gmail.com
>>>>>         <mailto:zenparsing at gmail.com>>
>>>>>
>>>>>
>>>>>         - Duck typing *must* work across Realms.  Symbols without a
>>>>>         registry do not.  You can make special cases for built-in
>>>>>         symbols, but special cases make bad law.
>>>>>
>>>>>
>>>>>     (You learned from me.)
>>>>>
>>>>>     I agree world-of-realms matters, in many ways. We can solve this
>>>>>     more generally, and should. I don't know the timing, but the idea
>>>>>     that cross-realm local issues stop global progress via symbols is
>>>>>     a bad trade in general. Must avoid getting stuck at local maximum.
>>>>>
>>>>>
>>>>> In the same spirit of brevity, you have this backwards. Local hill
>>>>> climbing with no lookahead is how to get stuck at a local maximum.
>>>>
>>>>
>>>> That's what I wrote!
>>>>
>>>> We need a world-of-realms spec. If we have one, probably many problems
>>>> become easy to solve. If we don't, then arguments against symbols in
>>>> particular and any world-wide values (value objects) that lack lookahead
>>>> prevail.
>>>
>>>
>>> Sorry, I misunderstood. In any case, yes.
>>>
>>>
>>>>
>>>>
>>>>
>>>>> The lookahead needed here is not agreement on a registry, but at least
>>>>> a straw registry whose implications we understand. Perhaps we have one,
>>>>> which is fine. We should examine it as part of this discussion of Symbols.
>>>>
>>>>
>>>> Why do you assume a mutable, racy registry?
>>>
>>>
>>> Care to propose a better registry?
>>>
>>> (I agree that we should disqualify any registry that is also a global
>>> communications channel.)
>>>
>>>
>>>>
>>>>
>>>>
>>>> /be
>>>
>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>
>
>
>
> --
>     Cheers,
>     --MarkM



-- 
erik


More information about the es-discuss mailing list