Symbols, Protocols, Frames, and Versioning

Dean Landolt dean at
Fri Oct 5 06:53:40 PDT 2012

On Fri, Oct 5, 2012 at 9:51 AM, Dean Landolt <dean at> wrote:

> On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <rossberg at>wrote:
>> On 5 October 2012 14:26, Sam Tobin-Hochstadt <samth at> wrote:
>> > On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith <khs4473 at> wrote:
>> >>
>> >> Sounds good.  As an aside, does the symbol in this case provide any
>> function
>> >> other than "wrapping" the string itself?  Does the symbol carry any
>> >> information that the string does not, from the point of view of the
>> script?
>> >
>> > No, in this case the results of `Symbol.for` are just a duplicate of
>> > the space of strings (just the way interned symbols are in Lisp).
>> Indeed, which is why I'm not sure I understand what this idea is
>> trying to achieve. Is it more than just an ad hoc way to introduce a
>> second namespace?
I really need learn to proofread better! Corrected below...

Symbols already introduce a second namespace, and in a way that allows us
> represent infinitely many ad hoc string namespaces side-by-side, with no
> need for nesting (which means the cardinality of symbols > strings I
> guess). But Symbol.for wouldn't be an ad hoc namespace -- IIUC it would be
> *the* de jure namespace to map string names to references for system-wide
> concepts like the iterator symbol.
> IMHO the *Symbol.for* namespace is very similar to the module namespace,
> perhaps too similar to justify Symbol.for. Wouldn't it be easier to spec.
> some subset of the module namespace to behave in the manner described for
> Symbol.for? In fact this is exactly how I imagined the @ module prefix
> (often used by Brendan in module examples) would work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list