This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-21
Channels
- # announcements (6)
- # bangalore-clj (1)
- # beginners (46)
- # cider (21)
- # cljs-dev (30)
- # cljsjs (3)
- # clojure (131)
- # clojure-dev (20)
- # clojure-europe (2)
- # clojure-italy (12)
- # clojure-nl (11)
- # clojure-russia (4)
- # clojure-spec (55)
- # clojure-uk (57)
- # clojurebridge (1)
- # clojured (1)
- # clojurescript (55)
- # cursive (11)
- # data-science (1)
- # datomic (23)
- # duct (1)
- # emacs (1)
- # events (1)
- # figwheel-main (2)
- # fulcro (219)
- # graphql (16)
- # immutant (1)
- # jackdaw (3)
- # java (6)
- # juxt (30)
- # kaocha (8)
- # mount (3)
- # nyc (1)
- # off-topic (16)
- # pathom (48)
- # pedestal (1)
- # re-frame (71)
- # reagent (17)
- # ring-swagger (3)
- # shadow-cljs (96)
- # spacemacs (21)
- # specter (8)
- # speculative (20)
- # sql (21)
- # test-check (2)
- # tools-deps (12)
- # vim (6)
Maybe someone here can explain why a self-referring require-macros is necessary in .cljc? I knew how to fix the issue, but I can’t explain it properly. I just know it works and therefore I’ve always done this in .cljc. https://dev.clojure.org/jira/browse/TCHECK-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51375#comment-51375 (cc @gfredericks)
I think it has something to do with macro inference, so you don’t need a require-macros when referring to the namespace?
my mental model is that the compiler makes 2 completely separate passes, one in cljs and one in clj, and neither pass “knows” about the other by default, so the cljs pass needs to be instructed to require the macros that were read in the clj pass if it wants to use them.
:require-macros
tells the CLJS compiler to require the macro namespace. otherwise the macros are not loaded and won't be expanded
since the defmacro
is visible in :cljs
and not elided it will just be called as a function
that behaviour of defmacro
working like a function can be surprising. one can use @cgrand’s macrovich utils to write a defmacro
that avoids it:
(core/defmacro defmacro
"Like defmacro, but only evaluated at macro-definition time"
[& body]
`(net.cgrand.macrovich/deftime
(core/defmacro ~@body)))
I’ve been bitten by a macro working like a function more then once and I believe it’s only there for self-hosted?
I mean, why not just ignore the macro definition in the CLJS stage when not in self-hosted mode?
hmm. maybe related to self-hosted for some low-level reason, but it can bite you there the same way. the ^defmacro replacement above was written while trying to get macros to work “seamlessly” in Maria, where it’s easy to hit the macro-as-fn problem
I think I set that problem aside, didn’t see a way to make macros work nicely there without introducing too much inconsistency with normal cljs
https://github.com/thheller/shadow-cljs/commit/21521590a01b710d6ca825e473b75759a1c9d85e
don't know how, not familiar with how the default compiler works anymore when it comes to self-hosted stuff
probably should have a discussion about it first too. there might be a reason its not done by default that I'm not aware of
Using generative testing I think I’ve found a bug in CLJS set/union
:
$ clj -A:test -m cljs.main -re node
ClojureScript 1.10.520
cljs.user=> (require '[clojure.set :as set])
nil
cljs.user=> (set/union #{} nil)
#{} ;; <- empty set, correct
cljs.user=> (set/union #{} nil nil)
() ;;<- not a set!
cljs.user=> (set/union #{} nil nil nil)
() ;; <- not a set!
I can reduce it down to the difference of (reduce into nil (list #{}))
in CLJS and CLJ. In CLJS it’s ()
and in CLJ it’s nil
The specs in speculative take nilable sets and also return nil or a set. I’ll read back why that decision was made.
@mfikes > alexmiller [5:57 PM] > I think right now I would treat both inputs and output as nilable > as existing code may be relying on the behavior of those things > nils are often used interchangeably with empty collections. it seems unlikely to me that there is not some code relying on this either for input or output https://github.com/borkdude/speculative/issues/70
@dnolen Pre-screening/vetting would be nice before I write a patch for this: https://dev.clojure.org/jira/browse/CLJS-3054