#something as a shorthand for "something", Smalltalk style, but without first class symbols

[JeanHuguesRobert]

Rationnal: minus one character to type and in favor of a style that leads to efficient programs.

[matehat]

+1 I've always loved symbols

[mattly]

I have to say that since this isn't a native construct in javascript, introducing it is opening a can of worms. Are we going to maintain a symbol <> integer lookup table or something? What if we're actually comparing an integer against one of our "symbols"?

[matehat]

I thought it was only that the two following expressions would be equal

#symbol
'symbol'

[mattly]

well in that case it's certainly a derivation from what symbols actually are in ruby; you probably already know this (and apologies if so), but Ruby's symbols aren't just "pretty strings": http://blog.hasmanythrough.com/2008/4/19/symbols-are-not-pretty-strings

I like coffeescript as a way of enforcing good javascript habits; however I think the futher it gets away from normal JS conventions / concepts the harder it will be to drive adoption.

[jashkenas]

I'm afraid that we've already covered symbols in an early ticket. Take a look here:

http://github.com/jashkenas/coffee-script/issues/issue/39

To sum up the issues:

• Strings are already immutable in JavaScript.
• We can't have real symbols, just strings or integers.
• Using strings would make it merely syntax sugar for word-strings.
• Integers can't be used as keys in hashes in JS (a big part of symbols elsewhere).

Given the above, and the issues in the previous ticket, it's definitely not worth adding another language construct for them. Closing as a wontfix.

[matehat]

mattly: I am aware of ruby's implementation of symbols and the problem around its use in some situation, thus the need to suggest proper use of it in an article like the one you linked. In javascript we can't do that, unless we do funky (read: incompatible) stuff. So the problems he pointed out don't apply to javascript.

The suggestion of its inclusion was more, I think, about a stylistic addition to reinforce string identity in situation where that is critical.

[JeanHuguesRobert]

You are right matehat, I did my homework and I read the issue 39 proposal, mine is not a duplicate of it.

I am proposing sugar syntax, no more, not a fullblown Ruby style first class Symbol type of values. I should have made it clearer in the title I guess, sorry.

[jashkenas]

If it's just sugar for strings, I'm still of the opinion that it's not worth introducing an entirely new construct, whose use would be determined only by convention and taste, and not by functionality.

I'm not aware of any programming languages that have pure-sugar symbols. They usually serve an immutable, O(1) comparison purpose, do they not? Smalltalk uses a symbol table, as does Ruby.

[JeanHuguesRobert]

Unless I missed something, I think that JavaScript does a good enough job with immutable strings and as a consequence do not need symbols so much, the speed improvement would be limited.

So yes jashkenas, this is just sugar for strings. Now, regarding convention and taste, it is my understanding that it is already well established that xxx.yyy and xxx['yyy'] have the same result. So, no need for a new conventions, right ?

xxx[#yyy] is shorter to write than xxx['yyy'], that is a feature maybe, isn't it ?

Now, do good conventions matter ? I guess they do, "convention over configuration" is one of the key ingredient of RoR's success for example, isn't it ?

Overall, this whole stuff is less about "symbols" than it is about the use of "keywords" I guess, and about how to better support keywords in JavaScript thanks to CoffeeScript.

Symbols, atoms, whatever the name, are usefull for O(1) comparison purpose, you are right jashkenas.

[matehat]

hehe didn't anyone think of # actually being used as a comment literal? I didn't ..

[JeanHuguesRobert]

Neither did I !!! I shall write some more CoffeeScript before submitting proposal, sorry for the suboptimal signal/noise I introduced.

BTW: What is the purpose of having # for comment literals ? What is wrong with // ? The extra character ?

[weepy]

I also thought it was a shame to use up the rather nice # symbol - just for comments which are served neatly by //. Why don't we switch and free it up?

[matehat]

Well, the # symbol is already widely spread as being a synonym of comments, so many developers already feel right at home with it. Though I agree it's pretty divergent from javascript.

[weepy]

CoffeeScript is supposed to be divergent where it's for the best :-)

[mattly]

In the given use case above, that is something akin to "foo[#bar]", it would be just as easy to do "foo.bar".

Given the rules for parsing things, which are similar in ruby, of how _ is part of a symbol but - isn't, you're still going to have to do foo['bar-baz'] for object slots that have these characters in them; foo[#bar-baz] would require changing the parsing rules (you're subtracting the value of baz from "bar") and of course foo.bar-baz doesn't work (you're subtracting baz from foo.bar). The only other time using "foo[bar]" notation makes sense when you don't know the value of 'bar' and are using a variable, not a string. So there's really no point for the given use case.

[JeanHuguesRobert]

I totally agree with your point mattly, my initial proposal does not work with bar-baz. I suspect that the people who have been creating such keywords in the first place had a strong background in Lisp ;-)

Now, are people happy with these keywords that are not valid JavaScript identifiers ? I don't think so (iam not). Is there a way to make them happier?

Looks like you find one such way. I should rephrase the proposal: Have #some-thing be sugar for 'some-thing' to reduce the impedance mismatch with imported keywords that don't respect the JavaScript syntax for identifiers.

Note: In addition to - there are maybe a few other characters that are valid for keywords in some of the protocols/formats frequently dealt with in JavaScript. For further study.

Note 2: If # is not available then some other character could be found, maybe not the :xxx syntax of Ruby however (a: :a does not look that nice), or maybe yes, I am not sure.

Note 3: obj.#bar-baz.#foo-bar: true looks better than obj["bar-baz"]["foo-bar"]: true, my proposal has ramification way beyong anticipated...

Note 4: BTW, is xx.'valid' (meaning xx['valid']) ?

[noonat]

No @ #4. It would be awesome if that worked, though. I would prefer that over any new symbols.