Symbols, Protocols, Frames, and Versioning

Dean Landolt dean at deanlandolt.com
Fri Oct 5 06:51:49 PDT 2012


On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 5 October 2012 14:26, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> > On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith <khs4473 at gmail.com> 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?
>


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 module namespace is a 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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121005/fa09473a/attachment-0001.html>


More information about the es-discuss mailing list