Clojurians
#cljs-dev
<
2017-10-15
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

favila00:10:42

In cljs, identical? means js ===

favila00:10:14

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

favila01:10:35

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

favila01:10:00

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

favila01:10:02

Similar to the boolean hint allowing omission of truth_ calls

mikethompson02:10:03

> 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.

thheller07:10:41

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

thheller07:10:46

but reader conditionals are fine too

thheller07:10:28

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

favila14:10:10

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

favila14:10:51

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

pesterhazy16:10:51

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

pesterhazy16:10:34

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