Why isn’t :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

yes. it has been ever since https://dev.clojure.org/jira/browse/CLJS-948

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

so it would maybe be nice to point him to some docs where this is stated.

I'm in no position to make "official" statements

who is?

David?

^ @dnolen ?

@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

it's weird-enough looking that it seems like a workaround for something

@borkdude why should :include-macros true default be desirable?

An easy naive answer is "because that's how clj-jvm works"

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

@dnolen

There is a subtle problem where defaulting :include-macros true could cause a .clj file to be incorrectly presumed to contain macros and loaded

@gfredericks it's not how Clojure works

Clojure doesn't self-require in any situation

@dnolen I mean (require 'foo.bar) gets both the macros and the functions

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

we're not changing anything here

how it works currently is how it works

Not requesting a change. Just wondering what’s the reason behind it.

@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

and in the case of a .cljc file?

It seems that any assumptions made by the compiler in this case could be incorrect...

that's exactly right

not interested in any ideas here

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

that's not new advice

it's been that way for years now

sure, I'm just checking

predates .cljc

this is good to know, thank you

@dnolen is this documented somewhere or something just culturally obvious

might not be, I thought it was covered in some description of the macro stuff

The behavior is certainly documented.

in theory this suggestion in .cljc would be ok - but it's not

because what if you don't want that

the “implicit macro” section talks about it, but it doesn’t seem like advice as in, you should consider doing this for your lib

then you need a knob

anyway no magic stuff

not interested

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 that’s ok, just wanted to make sure I didn’t oversee something 🙂

@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

not a bug

for context, the issue is: https://dev.clojure.org/jira/browse/TCHECK-154

@dnolen okay great, thanks

@mfikes I added an issue for it here: https://github.com/clojure/clojurescript-site/issues/303

I feel like cljs sorely needs a macrology guide

there are all sorts of idioms and tricks like this that are not obvious or laid out in one place

e.g. how to set up self-host macros

how to colocate everything in one cljc file correctly

how to use the &env sniffing trick to figure out what environment you are in

btw why isn't that just a reader conditional?

:cljs-macro-in-clj

:cljs-macro-in-cljs

@favila the macrovich library solves these issues for me

I know but have you seen its code?

that and self-referring macros

yes, I’m glad I didn’t have to figure that part out 😛

I don't personally think there are many rules here

in fact nothing has changed since 2011 except for the addition of one thing

and sugar to close the gap between Clojure, ClojureScript

but how it works - really it's the same

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?

not really

well, I mean sure in one sense - self-host added defmacro

but getting them as functions is not a consequence of self-hosted really

it's because ClojureScript isn't self-hosted

by default, and macros should be behind reader conditionals

behind which reader conditional, #?(:clj …) ?

but then it won’t be handled by self-hosted?

there's no such thing as macros in ClojureScript outside of bootstrapped

or non-official stuff

right. I think the most confusing thing with macros is when you want to support clj, cljs + self-hosted in just one .cljc file

the rest of the cases are pretty clear

I don't see how it's confusing?

since bootstrapped intentionally follows the same rules as ClojureScript to avoid that problem

macros can't intermix with runtime

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 don't mean to say it's not confusing

rather it's only as confusing as ClojureScript macros

it's no different

I think probably the source of confusion comes from the magical addition

Speaking of which, why do macros compile as function? And not just get skipped?

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 … 🙂

yeah I just don't see the problem

what ClojureScript does is fine for consumers of libs

that's the priority - for writers of libs - it's not that big of a deal IMO

@didibus we could do that - but it doesn't seem that important

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.

people have all kinds of ideas

which all boil down to minor conveniences

I'll just say that what we have is good enough for the forseeable future

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

And now I’m off to a pre-party of ClojureD. Bye!

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).

This would help: https://dev.clojure.org/jira/browse/CLJS-2636

inspecting &env for a missing key to figure out if your macro is supposed to expand to clj or cljs seems...terrible

that seems like it's crying out for a reader conditional tag

not going to happen

explicitly checking for a key isn't great - so hide that detail by adding something to cljs.analyzer.api

anyone can do that

patch welcome

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?

we have cljs.analyzer.api right now

but something for checking &env for target would be useful

I've tried to prefer that ns where it makes sense in newer ClojureScript code

fwiw, reader tags, ala #if-cljs-macro are just as good as #?(:if-cljs-macro, and library authors can ship them downstream

reader tags far as I know was not intended for source - just data

so I wouldn't encourage such things

Yeah, a plain 'ol macro oughta work in most cases too