On Fri, Oct 5, 2012 at 9:51 AM, Dean Landolt <[email protected]> wrote:
> > > On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <[email protected]>wrote: > >> On 5 October 2012 14:26, Sam Tobin-Hochstadt <[email protected]> wrote: >> > On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith <[email protected]> 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. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
