This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-03
Channels
- # aleph (1)
- # beginners (99)
- # boot (16)
- # cider (35)
- # cljs-dev (46)
- # cljsrn (7)
- # clojure (152)
- # clojure-austin (7)
- # clojure-dusseldorf (8)
- # clojure-italy (1)
- # clojure-uk (7)
- # clojurescript (3)
- # core-async (12)
- # css (8)
- # cursive (18)
- # datascript (2)
- # datomic (19)
- # defnpodcast (6)
- # duct (3)
- # editors (8)
- # emacs (8)
- # figwheel (1)
- # fulcro (20)
- # hoplon (18)
- # jobs-discuss (5)
- # lein-figwheel (1)
- # luminus (3)
- # lumo (19)
- # off-topic (15)
- # onyx (9)
- # parinfer (2)
- # planck (6)
- # portland-or (7)
- # re-frame (4)
- # reagent (7)
- # remote-jobs (1)
- # ring (6)
- # ring-swagger (4)
- # spacemacs (10)
- # specter (3)
- # unrepl (131)
I suppose ^ would be a way to solve https://dev.clojure.org/jira/browse/CLJS-2455
I wonder if there is an alternative, though, by having cljs.core/Eduction
satisfy some appropriate protocol. :thinking_face:
Even in the cond
branch for (seq coll)
, where it calls next
, that will ultimately call rest
, which calls seq
.
FWIW: https://github.com/clojure/clojurescript/commit/f62466d81c3b6657d1f91fa9fb0bc922bf2ee5ef
More relevant: https://github.com/clojure/clojurescript/commit/a113b08a8c2811b0590cc6a36b2e9e5adc1c4c1e
^ this is evidently part of an hack session of sorts leading to support for self hosted ClojureScript. Wow. https://github.com/wbrown/clojurescript/pull/4
Yeah, just trying to dig up some rationale for ISeq
vs. ISeqable
. Perhaps it was part of a mad hack session, which makes it harder to dig into. But I'm speculating that I might be wrong.
I see the above link in GitHub, which may simply be because I cloned something, and it is actually referring to a merge in the other direction (from ClojureScript master to some experimental branch).
OK, the argument would be: nth
only works on types that directly satisfy some needed interface. (That's an appealing argument IMHO.)
I'm trying to see how Clojure's deftype Eduction
ends up being Sequential
. Maybe it is the Util.ret1(coll, coll = null)
call? Hrm.
Oh, you are saying Clojure doesn't coerce either. Got it. 🙂 Then the question becomes, how does nth
work on Eduction
in Clojure?
looking at the Clojure code a bit more closely that’s the only time we should coerce via seq
, if we have Sequential
Clojure's logic seems to be, if translated to ClojureScript: If a type satisfies ISequential
, then nth
is supported on that type. But try to coerce via seq
, and if that coercion fails, then fail with "Index out of bounds"
.
To be fair, Clojure's nth
implemenation is 10+ years old. Before Seqable was a thing. Nowadays, clojure's nth
could probably just use canSeq
As a test, I’m going to run a change from (implements? ISeq coll)
to (or (implements? ISeq coll) (implements? ISequential coll))
through Coal Mine to see if if it finds anything of interest. This change is sufficient to make both (nth (eduction [:x]) 0)
and (nth (eduction [:x]) 1
in ClojureScript behave like Clojure.
As expected, it would be hard for any code in Coal Mine to provoke a failure with this change. I’ll capture the logic / rational, and attach a candidate patch to https://dev.clojure.org/jira/browse/CLJS-2455
Thanks @dnolen, @rauh. TBH, apart from the fact that it interrupts, working through an issue here can be effective compared to conversations in JIRA. 🙂
With the new map-entry?
predicate on master, (map-entry? (first {:a 1}))
differs from Clojure (it’s being honest, at least), but I’m curious if there is a ticket to address the underlying issue
I think we made the most conservative set of changes first, we need to change the map types to return MapEntry
instead of vectors now
Yeah. That’s what I’m doing… don’t want to add a dup. I’ll check and if I can’t find one, I’ll log a presumably fresh one.
Ugh. If anyone has ideas on https://dev.clojure.org/jira/browse/CLJS-2457, please share.
I’m wondering if something is botching the test framework… doing more work to try to isolate where this bizarre behavior is coming from.
I seem to vaguely recall this coming up before. In out unit tests, (prn (seq #js {:a 1 :b 2}))
will print (["a" 1] ["b" 2])
. WTF.