Fork me on GitHub
#clojure-dev
<
2018-05-04
>
andy.fingerhut00:05:13

So when folks refer to Henry Baker's 'egal' paper as inspiration for Clojure's definition of clojure.core/=, I definitely get that for numbers, strings, characters, immutable collections, and references, clojure.core/= is 99% similar to Baker's 'egal'. But clojure.core/= also returns true for all kinds of pairs of mutable Java objects, which Baker's egal would return false for, wouldn't it?

hiredman00:05:07

you could say it is like egal for the types it knows about(which are immutable), and instead of using pointer equality for other types, it uses java's .equal, which is by default pointer equality

andy.fingerhut00:05:56

Yes, which seems like kind of an odd mix when likening it to Baker's egal. I understand that it can be convenient for clojure.core/= to use Java's .equal whenever a "non-Clojure type" is involved, but ... just not egal at all in those cases.

alexmiller01:05:06

The egal parts are entirely focused on Clojure data structures. Also, Clojure wants to have good (read: useful) interop with the host, which means building on Java equals. Don’t over think it.

andy.fingerhut01:05:25

I reserve the right to over think it 🙂 But I won't over discuss my over thinking here if I can possibly avoid it. I'm becoming convinced that different people mean different things when they say "referential transparency", and reading Henry Baker's egal paper again is confusing me more when I try to understand most of what he says -- I think partly because discussing multiple possibly meanings for equality almost means you have to qualify every statement you make with "which definition of equals am I assuming for this sentence".

alexmiller01:05:15

Java in a nutshell

reborg09:05:31

Surprised (positively) by this considering https://dev.clojure.org/jira/browse/CLJ-1878

user=> (clojure-version)
"1.9.0"
user=> (let [[h & r :as s] (sorted-set 12 14)] r)
(14)
user=> (clojure-version)
"1.8.0"
user=> (let [[h & r :as s] (sorted-set 12 14)] r)
UnsupportedOperationException nth

bronsa10:05:25

it's a case of GIGO after a performance optimization in sequential destructuring with rest

bronsa10:05:44

user=> (let [[a b] (sorted-set 1 2)])
UnsupportedOperationException nth not supported on this type: PersistentTreeSet  clojure.lang.RT.nthFrom (RT.java:984)