Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Parent Full thread

They are similar, but with kind of inverted defaults.

Symbol("a") == Symbol("a") is more-less equivalent to Common Lisp's (eq (make-symbol "a") (make-symbol "a")), both of which will return false, because (in Lisp terms) we're creating two different symbols. In Common Lisp, the default behaviour of a reader if it sees a stand-alone symbol token, is to intern it - put it in "global"[0] storage, so that if the reader sees the same-looking symbol token again, it returns the same symbol instance it previously interned.

In JavaScript, per this article, the interning behaviour is available through Symbol.for(), i.e. Symbol.for("a") == Symbol.for("a") should return true, much like (eq 'a 'a) would return true in Lisp.

--

[0] - it's actually per-package storage, but that's getting into the more advanced details of CL.

--

EDIT replaced gensym with make-symbol in Common Lisp example, as the former is used primarily in writing macros, so it ensures the created symbol has an unique printed representation, which helps make macroexpansions more readable.

  (make-symbol "FOO") -> #:FOO
  (make-symbol "FOO") -> #:FOO ; NOT eq to the previous one
  (gensym "FOO") -> #:FOO103
  (gensym "FOO") -> #:FOO104 ; note the incrementing counter appended by gensym

Compare http://clhs.lisp.se/Body/f_mk_sym.htm and http://clhs.lisp.se/Body/f_gensym.htm.

But in Ruby people use symbols to specify an object's properties, and they aren't used that way in JavaScript at all. In JavaScript they are used for metadata and other things you don't want to be serialized by JSON.stringify() or Object.assign(). I've always been confused by why Ruby uses symbols so much.

Well, Ruby objects are basically big hash tables in a way. Makes sense to use a prehashed string to index them (if I understand how symbols work correctly).

Using symbols I think is more expressive than using strings.

I like the separation of strings for external data and symbols for internal data.

So symbols will usually be used for enums or things which logic or control flow depend on. Symbols then have the benefit of feeling like syntax and the scheme zen of code is data is code...

> In JavaScript they are used for metadata and other things you don't want to be serialized by JSON.stringify() or Object.assign().

They're used to avoid conflicts for "generic method" hooks (similar to dunder methods in Python): the conflict issues is why environments have broken when new methods were added, and why e.g. Object.keys and their ilk are "static" functions rather than methods.

If you don't want JSON.stringify or Object.assign to see your properties just make them non-enumerable e.g.:

    > const obj = {};
    > Object.defineProperty(obj, 'prop', {'value': 42});
    > obj
    < {prop: 42}
    > JSON.stringify(obj)
    < "{}"
    > Object.assign({}, obj)
    < {}

Object.assign will copy symbol-keyed properties. In fact Symbol-keyed properties are enumerable by default.

They live in an odd half-way world because many constructs only accept/handle string-keyed properties: Object.keys/entries/values and JSON.stringify use EnumerableOwnProperties and (for..in) uses EnumerateObjectProperties, both of which are specified to ignore non-string-keyed properties (before even checking for enumerability).

> I've always been confused by why Ruby uses symbols so much.

Mutable non-interned strings.

> I've always been confused by why Ruby uses symbols so much.

Good: Other people mainly covered it. Also note that when writing extensions using the C API, accepting options as symbols is generally much more convenient.

Less good:

  val = "something"
  val = :something
  # Saves one character and no need for an end token.

  { "key" => val }
  { key: val }
  # Saves four characters.

Symbol.for("a") != Symbol.for("b")

Perhaps you meant Symbol.for("a") for both?

That's what I meant. Thanks! I corrected the typo.

Reply on news.ycombinator.com