The Name of the Name
Lisp precedent: Objects which are used to name things (that is, they are used as keys by identity), and may be not globally-named themselves, are called symbols.
I like it. +1.
On Wednesday, August 1, 2012 at 3:47 PM, Mark S. Miller wrote:
Now that we have both private Names and unique Names, the general category covering both is simply Names. Properties can therefore be indexed by strings or Names. Strings are the ones consisting of a sequence of characters that can typically be pronounced. Names are anonymous identities.
In the real world, names and identities are distinct concepts, and names are the one corresponding to a unique sequence of characters that can be pronounced.
Is "Name" exactly the wrong name for a opaque unique identity typically used to index a property? Is there a better term?
Absolutely agree - I also think that Name has a high probability of extant code breakage.
I've spent some time looking at synonyms for "Unique", but nothing immediately stands out as "intuitive API"
Did you have any specific replacement?
On Wednesday, August 1, 2012 at 4:26 PM, Mark S. Miller wrote:
I like it. +1.
Symbol was on my short list but worried it was too similar to Name.
It seems less likely to conflict with extant code, but not by much.
+1 (but we can get weirder if we wanted to)
Symbol could already be used by parsers and compilers. What about UniqueName?
Why is there concern about uniqueness at all? Won’t this be inside a module?
import Symbol from "@symbols"
From: François REMY Sent: Wednesday, August 1, 2012 17:07:02 To: Rick Waldron, Mark S. Miller CC: es-discuss Subject: RE: The Name of the Name
Symbol could already be used by parsers and compilers. What about UniqueName?
Symbol is not bad. I think people could use it for similar purposes as Ruby's symbols, but it might get a little confusing at the differences - not that it should stop us if we like the word.
Some other ideas:
Key, Signature (unforgeable), Token, Privilege
I suspect we will get around to having some level of syntactic support for defining these things so I'm more concerned about how we talk about them (ie, the name of the language feature) then I am about what what has to be typed in source code and possible source code name conflicts.
From that perspective, a fairly unusual noun that is unlike to be confused with application domain concepts would be ideal.
One possibility is : moniker Microsoft COM uses that term for a different but somewhat similar abstraction. Other than that usage, which seems benign, moniker seems unlikely to carry other unwarranted technical implications.
Consider: "A property key is either a string or a moniker" "If the key is a private moniker then then it isn't reflected by Object.getOwnPropertyNames"
On Wednesday, August 1, 2012 at 6:12 PM, Allen Wirfs-Brock wrote:
I suspect we will get around to having some level of syntactic support for defining these things so I'm more concerned about how we talk about them (ie, the name of the language feature) then I am about what what has to be typed in source code and possible source code name conflicts.
From that perspective, a fairly unusual noun that is unlike to be confused with application domain concepts would be ideal.
One possibility is : moniker Microsoft COM uses that term for a different but somewhat similar abstraction. Other than that usage, which seems benign, moniker seems unlikely to carry other unwarranted technical implications.
Consider: "A property key is either a string or a moniker" "If the key is a private moniker then then it isn't reflected by Object.getOwnPropertyNames"
Yes, this is exactly the kind of "weird" I was hoping for—something that really distinguishes the concept from all other existing language concepts.
Allen Wirfs-Brock wrote:
I suspect we will get around to having some level of syntactic support for defining these things so I'm more concerned about how we talk about them (ie, the name of the language feature) then I am about what what has to be typed in source code and possible source code name conflicts.
From that perspective, a fairly unusual noun that is unlike to be confused with application domain concepts would be ideal.
One possibility is : moniker
/n./ /Slang/ A personal name or nickname.
Nope.
Microsoft COM
You lost me right there :-P.
uses that term for a different but somewhat similar abstraction. Other than that usage, which seems benign, moniker seems unlikely to carry other unwarranted technical implications.
Consider: "A property key is either a string or a moniker"
I agree that "Name" here is confusing when one reads aloud, because the capital N and code font are not voiced. However in print, Name can work as well as Symbol or other terms.
It would be awkward to have only compound names such as UniqueName and PrivateName.
Hacker jargon such as a nouned "gensym" would be as distinctive, if not moreso, and better yet, well-employed compared to "moniker".
I'd love to hear from Dave and Sam since they have lots of experience from Racket/Scheme.
On Wed, Aug 1, 2012 at 3:44 PM, Brendan Eich <brendan at mozilla.org> wrote:
[...] However in print, Name can work as well as Symbol or other terms.
If we call the category of things that Object.getOwnPropertyNames does not return "Name"s, ...
It is too late to rename getOwnPropertyNames.
On Aug 1, 2012, at 3:44 PM, Brendan Eich wrote:
One possibility is : moniker
While I recognize the benefit of staking out new territory, I think that misses the opportunity to build off of existing intuitions. I tend to think it's ok to use a term from another language that isn't 100% isomorphic, as long as a) the analogy helps people bootstrap their understanding, b) the core intuition suggested by the name is good, and c) the differences aren't likely to trip people up.
Consider: "A property key is either a string or a moniker"
I agree that "Name" here is confusing when one reads aloud, because the capital N and code font are not voiced. However in print, Name can work as well as Symbol or other terms.
I'm partial to Symbol. It doesn't smell like a thesaurus was involved, and it's a decent intuition. In the Lisp world, strings and symbols are isomorphic, but there's a sense that symbols have identity where strings don't. Now, Lisp symbols are historically forgeable and interned, so this isn't exactly the same concept. But you can still ride on the intuition that "symbols are like strings but they have identity / cheap comparison". And it feels like a smaller delta to the language to say:
"A property key is either a string or a symbol"
rather than
"A property key is either a string or a new-thing-you-haven't-heard-of"
(YMMV)
It would be awkward to have only compound names such as UniqueName and PrivateName.
Yes, compound names feel like we're giving up. :) And I'd really rather unify unique/private into a single datatype with a privacy flag, rather than two separate datatypes.
Hacker jargon such as a nouned "gensym" would be as distinctive, if not moreso, and better yet, well-employed compared to "moniker".
I could live with nouning gensym, even though some people are allergic to nouning/verbing. Then again, new Gensym does smack of the Kingdom of Nouns -- verbing a nouning of a verb, oh my! Or we could simply have a gensym() function -- uncapitalized -- and refer to the result as "a gensym." That's just a single nouning.
In a vacuum, I like the idea of "key" but that's obviously far too generic, and the term is already used by Object.keys(). I tried thesaurusing it but nothing jumped out at me.
Oops, you're right.
I could go for Symbol.
On Aug 1, 2012, at 3:53 PM, Mark S. Miller wrote:
On Wed, Aug 1, 2012 at 3:44 PM, Brendan Eich <brendan at mozilla.org> wrote:
[...] However in print, Name can work as well as Symbol or other terms.
If we call the category of things that Object.getOwnPropertyNames does not return "Name"s, ...
It is too late to rename getOwnPropertyNames.
That's been bothering me too. I think it's good you brought this up. As long as we come up with a reasonable new term, it's probably best for us to alpha-rename the spec-internal concept of "a thing that can be used as the key of an object property", and stick with "name" and "key" as user-facing terminology for "a string that is used as the key of an object property."
On Wed, Aug 1, 2012 at 3:56 PM, David Herman <dherman at mozilla.com> wrote:
In the Lisp world, strings and symbols are isomorphic, but there's a sense that symbols have identity where strings don't. Now, Lisp symbols are historically forgeable and interned, so this isn't exactly the same concept.
In Common Lisp (which I am most familiar with, and I think is a relevant design), this is not right.
A symbol is an object; it has a name property, which is a string. The name need not be unique. Package (namespace) objects are mappings between strings and symbols, with the constraint that if a symbol is in a package, then the symbol's name property is also the string that the package maps to it. (This constraint can be considered a mistake, in that it prohibits renamed imports.)
Therefore, a symbol which is not in a package ("uninterned") is not "forgeable" — that is, you cannot obtain it starting from its name unless it's in some other table you have — with the caveat that since CL is very far from a capability design, there are plenty of ways to get your hands on a symbol being used, so this does not have any security properties.
Uninterned symbols are used for unique generated names ("gensyms"); interned symbols (those which exist in packages) are used for names written in source code. These essentially correspond to the use cases of the proposed unique-names and strings, respectively; CL's design gains orthogonality by having even "ordinary names" be symbols rather than strings, so the programmer need not have different code paths.
On Wednesday, August 1, 2012 at 6:56 PM, David Herman wrote:
On Aug 1, 2012, at 3:44 PM, Brendan Snip...
I could live with nouning gensym, even though some people are allergic to nouning/verbing. Then again, new Gensym does smack of the Kingdom of Nouns -- verbing a nouning of a verb, oh my! Or we could simply have a gensym() function -- uncapitalized -- and refer to the result as "a gensym." That's just a single nouning.
Re: "Gensym", spelled as capitalized proper noun, competes for discoverability with a company of the same name.
How ironic for two gensyms to conflict ;).
On Aug 1, 2012, at 4:20 PM, Kevin Reid wrote:
On Wed, Aug 1, 2012 at 3:56 PM, David Herman <dherman at mozilla.com> wrote:
In the Lisp world, strings and symbols are isomorphic, but there's a sense that symbols have identity where strings don't. Now, Lisp symbols are historically forgeable and interned, so this isn't exactly the same concept.
In Common Lisp (which I am most familiar with, and I think is a relevant design), this is not right.
I'm always torn whether to say "the Scheme world" and risk upsetting Lispers that I didn't include them, and "the Lisp world" and risk upsetting Lispers that I spoke for them... Please just s/Lisp/Scheme/g on my email. :)
...
Sure, some Schemes have uninterned symbols as well.
Uninterned symbols are used for unique generated names ("gensyms"); interned symbols (those which exist in packages) are used for names written in source code. These essentially correspond to the use cases of the proposed unique-names and strings, respectively; CL's design gains orthogonality by having even "ordinary names" be symbols rather than strings, so the programmer need not have different code paths.
OK, so you're definitely talking way more specifically about Common Lisp. I was trying to generalize about languages in the Lisp tradition, and what they all have in common about the base concept of symbols. (And probably getting it wrong, since I know more about Scheme and Racket than I do about languages that call themselves Lisp.)
At any rate, the tradition of uninterned symbols is one more point in favor of using the terminology of symbols.
But let's not get derailed by details of other languages. Every language gets to choose its own terminology. No two languages are going to have the same exact definition of any term. My point is that I think there's enough overlap of intuition to make it a reasonable choice.
On Aug 1, 2012, at 4:45 PM, David Herman wrote:
...
Sure, some Schemes have uninterned symbols as well.
Oops, meant to snip my own text there as well, since I addressed uninterned symbols further down. Hope it didn't come across rude.
On Aug 1, 2012, at 3:44 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I suspect we will get around to having some level of syntactic support for defining these things so I'm more concerned about how we talk about them (ie, the name of the language feature) then I am about what what has to be typed in source code and possible source code name conflicts.
From that perspective, a fairly unusual noun that is unlike to be confused with application domain concepts would be ideal.
One possibility is : moniker
/n./ /Slang/ A personal name or nickname.
Nope.
string /n./
- a thin length of cord, twine, fibre, or similar material used for typing, hanging, binding, etc.
- a group of objects threaded on a single strand
- a series or succession of things, events, acts, utterances, etc. ...
In appropriating nouns for reassignment to technical concepts we aren't looking for words whose every-day meaning is an exact match to the technical concept. Instead we look for words whose common meaning has enough conceptual relationship to the concept such that it aids in learning and communicating about the technical concept. Otherwise, we could just uses unique gibberish words.
"Moniker" is conceptually close enough to be helpful, but doesn't have many conceptual implications that are likely to cause confusion between its normal English meaning and the technical concept.
Microsoft COM
You lost me right there :-P.
Arguably, JS's object model is closer to COM's then it is is to a lot of other things...
uses that term for a different but somewhat similar abstraction. Other than that usage, which seems benign, moniker seems unlikely to carry other unwarranted technical implications.
Consider: "A property key is either a string or a moniker"
I agree that "Name" here is confusing when one reads aloud, because the capital N and code font are not voiced. However in print, Name can work as well as Symbol or other terms.
It would be awkward to have only compound names such as UniqueName and PrivateName.
Hacker jargon such as a nouned "gensym" would be as distinctive, if not moreso, and better yet, well-employed compared to "moniker".
Gensym has hacker cred. but most JS programmers aren't hackers. Moniker is easier to explain:
Daddy, whats a "Moniker"? It's a unique object that can be used as a property name.
Daddy, what's a "Gensym"? It's a unique object that can be used as a property name. "Gensym" is short for "Generated symbol" and was first used in Lisp to name the the built-in function that could be used to generate unique symbolic names. Among Lisp programmers "gensym" also came to mean any value generated by the gensym function. In JavaScript we don't generally use the term "symbol" but unique non-string property keys are conceptually kinda similar to Lisp gensyms so we decided to use the same name. Isn't hacker culture cool!
Allen Wirfs-Brock wrote:
On Aug 1, 2012, at 3:44 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I suspect we will get around to having some level of syntactic support for defining these things so I'm more concerned about how we talk about them (ie, the name of the language feature) then I am about what what has to be typed in source code and possible source code name conflicts.
From that perspective, a fairly unusual noun that is unlike to be confused with application domain concepts would be ideal.
One possibility is : moniker /n./ /Slang/ A personal name or nickname.
Nope.
string /n./
- a thin length of cord, twine, fibre, or similar material used for typing, hanging, binding, etc.
- a group of objects threaded on a single strand
- a series or succession of things, events, acts, utterances, etc. ...
Sorry, this is not analogous. Strings are in JS, everyone knows that term in context. Coming late to the party with Monicker (or Gensym, I agree) is the challenge.
In appropriating nouns for reassignment to technical concepts we aren't looking for words whose every-day meaning is an exact match to the technical concept. Instead we look for words whose common meaning has enough conceptual relationship to the concept such that it aids in learning and communicating about the technical concept. Otherwise, we could just uses unique gibberish words.
We might do better to use hacker jargon. "Moniker" is uncommon enough in modern English to sit awkwardly on most tongues and all keyboards and screens. Just say no :-|.
Microsoft COM You lost me right there :-P.
Arguably, JS's object model is closer to COM's then it is is to a lot of other things...
No, COM is standardized vtbls and vptrs and calling conventions, plus IUnknown etc. built on top.
JS's model is much higher-level. The the extent that COM (or rather, C++ or even C) nominal typing infects built-ins and "host objects", JS and its users suffer.
FWIW, +1 on symbol.
Being a non-native English speaker, "moniker" sounds strange to me: I didn't even know the meaning of the word until this point.
Now that we have both private Names and unique Names, the general category covering both is simply Names. Properties can therefore be indexed by strings or Names. Strings are the ones consisting of a sequence of characters that can typically be pronounced. Names are anonymous identities.
In the real world, names and identities are distinct concepts, and names are the one corresponding to a unique sequence of characters that can be pronounced.
Is "Name" exactly the wrong name for a opaque unique identity typically used to index a property? Is there a better term?
Now that we have both private Names and unique Names, the general category covering both is simply Names. Properties can therefore be indexed by strings or Names. Strings are the ones consisting of a sequence of characters that can typically be pronounced. Names are anonymous identities. In the real world, names and identities are distinct concepts, and names are the one corresponding to a unique sequence of characters that can be pronounced. Is "Name" exactly the wrong name for a opaque unique identity typically used to index a property? Is there a better term? -- Cheers, --MarkM