Symbols, Protocols, Frames, and Versioning
Mark S. Miller
erights at google.com
Thu Oct 4 14:30:52 PDT 2012
For a fresh symbol and an immutable association to a string fixed at
creation time, no problem.
For an interned symbol whose associated string name is the string interned
to get it, no problem.
On Thu, Oct 4, 2012 at 2:19 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
> The private name proposal included the possibility of attaching a string
> value to a symbol when it is created. The string could be used in debug
> output (toString) for the symbol.
> "Mark S. Miller" <erights at google.com> wrote:
> It depends what you mean by "associating". What do you have in mind?
> On Thu, Oct 4, 2012 at 1:18 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>> Presumably, this concern would also apply to associating programmer
>> supplied debug info with symbols
>> "Mark S. Miller" <erights at google.com> wrote:
>> On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock <allen at wirfs-brock.com
>> > wrote:
>>> Note that in most cases, you want to look up an already interned symbol
>>> name rather than intern a new one.
>> One of the beautiful things about interning is that it is a pure
>> function, and so does not provide a communications channel. If one frame
>> could test whether some other frame somewhere had already interned a given
>> name, you'd have an unpluggable cross-frame communications channel.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss