Fork me on GitHub

In cljs, identical? means js ===


It’s not really an intern vs not because js doesn’t expose any such semantics


But cljs = is more expensive in js (a fn call, typeof check, and worse) to get the right equality semantics clojure expects


In theory cljs could use type info to weaken = to identical if it can prove type of its args


Similar to the boolean hint allowing omission of truth_ calls


> It’s not really an intern vs not because js doesn’t expose any such semantics Hmm. I can't quite square this against my comment, so I'm wondering if we are talking past each other on different tangents. So, just for clarity, all I'm saying is ... At the js console: {"hello": "world"} === {"hello": "world"} is always false (all implementations I'm aware of) ("hello" + " " + "world") === "hello world" is always true (all implementations I'm aware of) The 2nd result only happens because js platforms intern strings. So, to me the semantics are exposed. In fact, so much so that they are explicitly exploited (efficiency!) by the reader conditional code fork questioned by thheller.


To me, intern means all instances with same value have same memory address. === has specified behavior for certain types and does not care about interning. If it exists, it allows for a faster compare, but not interned necessarily


Modern Js vms use many different types internally for strings (eg ropes, views, char set-specific encodings, etc), only some of which are interned. Large strings are not interned


👍 - also, === afaik is defined to be indistinguishable from == for primitives, and strings are primitives in js (but not in java)


So in Java, strings are objects, so they would be identical only if the object referenced match - which could be an effect of interning


seems like we could then just optimize the = macro to use === whenever either of the arguments is a string


but reader conditionals are fine too


just get slowed down a lot when reading through any code with reader conditionals, having to context switch constantly is hard