This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-13
Channels
- # 100-days-of-code (5)
- # adventofcode (1)
- # announcements (8)
- # beginners (148)
- # boot (17)
- # calva (26)
- # cider (17)
- # cljdoc (2)
- # cljs-dev (55)
- # cljsjs (2)
- # clojure (198)
- # clojure-dev (11)
- # clojure-finland (1)
- # clojure-italy (23)
- # clojure-nl (6)
- # clojure-spec (44)
- # clojure-uk (148)
- # clojurescript (27)
- # clojutre (20)
- # core-logic (21)
- # cursive (12)
- # datascript (10)
- # datomic (33)
- # emacs (11)
- # figwheel-main (49)
- # fulcro (19)
- # graphql (2)
- # off-topic (48)
- # onyx (2)
- # other-languages (53)
- # pedestal (3)
- # reagent (75)
- # reitit (17)
- # rum (1)
- # slack-help (2)
- # specter (2)
- # sql (3)
- # tools-deps (24)
- # unrepl (4)
- # yada (1)
back when I was purging it you would still occasionally find people using it for no good reason
right, we could move that stuff into the compiler and get rid of it completely, but that’s also a bit of extra work that isn’t particularly meaningful
Ahh, yeah. I saw a note on how js*
in the and
macro can flummox core.async
. Maybe some other approach might help
I use js*
to emit some hand-crafted js code in place of macro expanded code, to provide correct line numbering in chrome console / javascript stack traces:
https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/codegen.clj#L283
I agree, my quick take (without digging into it) is that core.async
is making some sort of assumption
a good project would be to copy-pasta core.async Clojure implementation which fixes a lot more bugs than just js*
andare? 😄
well the issue with and
macro is weird ... it should not evaluate both expression just because in a go
macro no?
if I understood the problem correctly of course
also a good way to test this - return and
to it’s old form - it may still not work as expected
I've noticed that in clojure, seq
and seqable?
both check, and can create seqs from, Java Iterables, but cljs's seqable?
et al doesn't do the same for JS via ES2015's iterator protocol. Anyone know whether this is intentional or just hasn't been gotten around to yet post-ES2015? Seems like it'd be trivial to implement since ITER_SYM
is already defined in core
figured I'd see if anyone knew offhand before I start tinkering with it and/or posting to the google group for the first time
seems like there's an opportunity to add a little interop with newer JS features (iterables, Map/Set, etc)
@jesse.wertheim I’ve never used it, but es6-iterator-seq
yep, so that gives you a seq from an iterator (object with a .next() fn) - one would just need to combine that with modifying the the seq-producing core to check Symbol.iterator
if other checks fail and do (es6-iterator-seq (. foo ITER_SYM))
@mfikes easy enough to do in userland code if necessary, just wondering if it'd be desirable to have parity with clojure's interop with Java's iterator protocol
Or if it's being avoided, possibly because some iterables in JS could end up performing weird side effects as you consume their iterator
no worries, appreciate the response regardless! I'll just play with it when I have time and ask the google group once I've got the specifics nailed down of what underlying cljs bits I'd need to modify
or just see if the patch gets accepted I guess? I haven't contributed before so was just gonna follow the contributing guide verbatim re: etiquette
ah, great. In any case, I think it's a good idea - it'll allow for easy consumption of ES Map/Set and any custom iterables - and things like NodeLists on the DOM are iterable now, as well. The danger is that native iterators in JS are also iterable iterators, so if this were implemented, (seq some-es-iterator)
would, rather than error, invoke Symbol.iterator
on it, get the same iterator back, and then consume it
but for that to happen you'd have to be doing some pretty weird stuff with mutable things - raw iterators aren't usually just hanging around
core.async
doesn’t realize that it is not ok to lift the arguments out of js*
and let
-bind them
(def cards :foo)
(js*
"((~{}) && (~{}))"
(vector? cards)
(< 0 (count cards)))
gets converted to
(let [temp-1 (vector? cards)
temp-2 (< 0 (count cards))]
(js* "((~{}) && (~{}))" temp-1 temp-2))
and this results in premature evaluation of
(< 0 (count cards))
So, TL;DR, core.async
thinks js*
is a function, effectively. It doesn’t realize it is a special form.
^ this is the result of taking a look at the JavaScript generated for
(go (and (vector? cards) (< 0 (count cards))))
Actually, this is cut-n-dry and easily seen if you
(macroexpand '(go (and (vector? cards) (< 0 (count cards)))))
and do this simple enhancement for people who want to use code splits https://dev.clojure.org/jira/browse/CLJS-2903
at Rich’s Datomic Ions talk yesterday in NYC, a user asked me about this, and I agree it’s an oversight
Yeah, a release would probably be good. I'm thinking that any of the newer type inference stuff should probably wait until the beginning of another dev cycle. The fix for this defect is probably safe enough to include in a release https://dev.clojure.org/jira/browse/CLJS-2883