This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (55)
- # cider (22)
- # cljs-dev (123)
- # cljsrn (75)
- # clojars (1)
- # clojure (92)
- # clojure-europe (2)
- # clojure-italy (16)
- # clojure-nl (6)
- # clojure-spec (17)
- # clojure-uk (77)
- # clojured (2)
- # clojurescript (39)
- # core-async (8)
- # cursive (4)
- # data-science (1)
- # datomic (22)
- # duct (4)
- # editors (21)
- # emacs (10)
- # events (4)
- # fulcro (116)
- # graphql (8)
- # immutant (3)
- # jackdaw (1)
- # juxt (3)
- # kaocha (4)
- # luminus (1)
- # mount (1)
- # nrepl (32)
- # off-topic (34)
- # other-languages (5)
- # pedestal (32)
- # reagent (1)
- # ring (6)
- # ring-swagger (7)
- # shadow-cljs (5)
- # spacemacs (3)
- # specter (1)
- # sql (1)
- # vim (21)
:include-macros true included in a require by default, so a user doesn’t even have to think about this?
@borkdude a user doesn't have to think about it if the required namespace does its
:require-macros setup correctly. that is the point. it can't be done automatically because things like
clojure.string would then always load
clojure/string.clj which is never necessary as it doesn't contain any macros.
ok. so it’s recommended that macro writers set up their namespaces “correctly” so consumer do not have to think about it
the test.check maintainers asks if this is the “official position of the CLJS maintainers”: https://dev.clojure.org/jira/browse/TCHECK-154?focusedCommentId=51383&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-51383
@borkdude I haven't grokked that TCHECK ticket, but is it about https://clojurescript.org/guides/ns-forms#_implicit_sugar ?
yeah, a namespace "requiring itself" is at least the surface-level effect I'm wondering about
I always assumed cljs didn't work that way because it was hard to implement, not because it wasn't desirable from a user's perspective
There is a subtle problem where defaulting
:include-macros true could cause a
.clj file to be incorrectly presumed to contain macros and loaded
ok, so you should only do
:include-macros true if there is actually a .clj file to include and if not, an error will happen?
maybe you could also say: look for macros by default, but if there is no .clj file, do nothing
@mfikes yes, the ticket is about adding a self-refer to get the implicit sugar for free
A reason not to default to
:include-macros true when there is a
.clj file present is that the compiler can't assume that this
.clj file contains macros intended to be associated with the runtime namespace
I'm not proposing any, I'm just making sure that "libraries with macros should add self-requires so that users don't have to require macros separately" is the advice
the “implicit macro” section talks about it, but it doesn’t seem like advice as in, you should consider doing this for your lib
Promoting it as an approach is not documented, as far as I know. Outside of official stuff, I promoted it a bit here http://blog.fikesfarm.com/posts/2018-08-12-two-file-clojurescript-namespace-pattern.html
@dnolen the context is just that @borkdude proposed adding this line to a test.check file, and I wanted to make sure it should be there, and check if it was some temporary work-around for a known bug; we aren't arguing for changes to cljs
It seems like a small wording change away from being descriptive here to becoming prescriptive https://clojurescript.org/guides/ns-forms#_implicit_sugar
@mfikes I added an issue for it here: https://github.com/clojure/clojurescript-site/issues/303
there are all sorts of idioms and tricks like this that are not obvious or laid out in one place
but if someone wants to write a guide for maximal macro reuse - sure that does seems helpful for the site
@dnolen I think getting functions instead of macros because of forgetting to require them as a macro is a consequence of self-hosted CLJS?
right. I think the most confusing thing with macros is when you want to support clj, cljs + self-hosted in just one .cljc file
since bootstrapped intentionally follows the same rules as ClojureScript to avoid that problem
it’s not confusing me anymore right now, but it got me confused when I got a function instead of a macro some time
i.e. requiring the macro ns from the runtime ns - that lets downstream users get macros automatically
> Macrovich is a set of four macros to ease writing *.cljc supporting Clojure, Clojurescript and self-hosted Clojurescript I rest my case … 🙂
Right. I can see why some things are confusing. I’m not saying that anything should change. E.g. some people think reader conditionals can be used in the way that macrovich’s case macro works.
I don’t think anyone disagreed with that in this channel as far as I can tell. Some documentation tweaks here and there could improve understanding. E.g. https://github.com/clojure/clojurescript-site/issues/303
I see. Ya, not a huge priority, but I think it would speak more loudly that the macro is missing, as opposed to being a function. The latter can make you believe it works, and just leave you wondering if your macro is just broken. While the former would force you to google about it I think. Or even better if somehow it could throw a compile exception.
Hrm. Well, you only get a function if you use
defmacro when the code is being compiled as ClojureScript.
So, if you happen to use
defmacro in a
.cljs file, for example, you'd get a function.
The reason this is set up this way is that, in self-hosted ClojureScript, you want a
defmacro sitting in a macros namespace to compile to a function—that function is then used by the compiler (during macro expansion).
inspecting &env for a missing key to figure out if your macro is supposed to expand to clj or cljs seems...terrible
explicitly checking for a key isn't great - so hide that detail by adding something to
Dang. Graal.js was renamed https://github.com/graalvm/graaljs/commit/f75dfccc31bc7622adc409d7f48da56009fe06c3 I suppose our repl env name is still ok
@dnolen Yeah, you've been interested in seeing a higher level, "better api" for interacting with the analyzer for a while, haven't you?
fwiw, reader tags, ala
#if-cljs-macro are just as good as
#?(:if-cljs-macro, and library authors can ship them downstream