Fork me on GitHub
#cljs-dev
<
2019-02-22
>
borkdude07:02:39

Why isn’t :include-macros true included in a require by default, so a user doesn’t even have to think about this?

thheller08:02:09

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

borkdude08:02:58

ok. so it’s recommended that macro writers set up their namespaces “correctly” so consumer do not have to think about it

borkdude08:02:56

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

thheller08:02:25

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

mfikes12:02:02

@borkdude I haven't grokked that TCHECK ticket, but is it about https://clojurescript.org/guides/ns-forms#_implicit_sugar ?

gfredericks13:02:07

yeah, a namespace "requiring itself" is at least the surface-level effect I'm wondering about

gfredericks13:02:29

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

dnolen13:02:25

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

gfredericks13:02:50

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

gfredericks13:02:37

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

mfikes13:02:23

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

dnolen13:02:59

@gfredericks it's not how Clojure works

dnolen13:02:54

Clojure doesn't self-require in any situation

gfredericks14:02:53

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

borkdude14:02:54

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?

borkdude14:02:26

maybe you could also say: look for macros by default, but if there is no .clj file, do nothing

dnolen15:02:49

we're not changing anything here

dnolen15:02:54

how it works currently is how it works

borkdude15:02:39

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

borkdude15:02:12

@mfikes yes, the ticket is about adding a self-refer to get the implicit sugar for free

mfikes15:02:05

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

borkdude15:02:33

and in the case of a .cljc file?

mfikes15:02:30

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

dnolen15:02:43

that's exactly right

dnolen15:02:47

not interested in any ideas here

gfredericks15:02:14

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

dnolen15:02:33

that's not new advice

dnolen15:02:45

it's been that way for years now

gfredericks15:02:50

sure, I'm just checking

dnolen15:02:58

predates .cljc

gfredericks15:02:10

this is good to know, thank you

borkdude15:02:19

@dnolen is this documented somewhere or something just culturally obvious

dnolen15:02:51

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

mfikes15:02:06

The behavior is certainly documented.

dnolen15:02:14

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

dnolen15:02:20

because what if you don't want that

borkdude15:02:29

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

dnolen15:02:33

then you need a knob

dnolen15:02:38

anyway no magic stuff

dnolen15:02:39

not interested

mfikes15:02:47

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

borkdude15:02:15

@dnolen that’s ok, just wanted to make sure I didn’t oversee something 🙂

gfredericks15:02:53

@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

mfikes15:02:07

It seems like a small wording change away from being descriptive here to becoming prescriptive https://clojurescript.org/guides/ns-forms#_implicit_sugar

👍 5
gfredericks15:02:47

@dnolen okay great, thanks

favila16:02:28

I feel like cljs sorely needs a macrology guide

favila16:02:45

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

favila16:02:30

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

favila16:02:44

how to colocate everything in one cljc file correctly

favila16:02:57

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

favila16:02:31

btw why isn't that just a reader conditional?

favila16:02:53

:cljs-macro-in-clj

favila16:02:58

:cljs-macro-in-cljs

borkdude16:02:01

@favila the macrovich library solves these issues for me

favila16:02:10

I know but have you seen its code?

borkdude16:02:19

that and self-referring macros

borkdude16:02:34

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

dnolen17:02:42

I don't personally think there are many rules here

dnolen17:02:56

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

dnolen17:02:25

and sugar to close the gap between Clojure, ClojureScript

dnolen17:02:06

but how it works - really it's the same

dnolen17:02:47

but if someone wants to write a guide for maximal macro reuse - sure that does seems helpful for the site

👍 5
borkdude17:02:28

@dnolen I think getting functions instead of macros because of forgetting to require them as a macro is a consequence of self-hosted CLJS?

dnolen17:02:59

not really

dnolen17:02:58

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

dnolen17:02:10

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

dnolen17:02:18

it's because ClojureScript isn't self-hosted

dnolen17:02:31

by default, and macros should be behind reader conditionals

borkdude18:02:20

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

borkdude18:02:38

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

dnolen18:02:39

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

dnolen18:02:47

or non-official stuff

borkdude18:02:13

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

borkdude18:02:37

the rest of the cases are pretty clear

dnolen18:02:52

I don't see how it's confusing?

dnolen18:02:14

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

dnolen18:02:26

macros can't intermix with runtime

borkdude18:02:43

it’s not confusing me anymore right now, but it got me confused when I got a function instead of a macro some time

dnolen18:02:55

I don't mean to say it's not confusing

dnolen18:02:06

rather it's only as confusing as ClojureScript macros

dnolen18:02:11

it's no different

dnolen18:02:12

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

didibus18:02:21

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

dnolen18:02:27

i.e. requiring the macro ns from the runtime ns - that lets downstream users get macros automatically

borkdude18:02:34

> Macrovich is a set of four macros to ease writing *.cljc supporting Clojure, Clojurescript and self-hosted Clojurescript I rest my case … 🙂

dnolen18:02:57

yeah I just don't see the problem

dnolen18:02:06

what ClojureScript does is fine for consumers of libs

dnolen18:02:15

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

dnolen18:02:28

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

borkdude18:02:53

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.

dnolen18:02:09

people have all kinds of ideas

dnolen18:02:18

which all boil down to minor conveniences

dnolen18:02:32

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

borkdude18:02:51

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

borkdude18:02:07

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

didibus18:02:47

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.

mfikes18:02:08

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

favila18:02:31

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

favila18:02:09

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

dnolen18:02:19

not going to happen

dnolen18:02:39

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

dnolen18:02:43

anyone can do that

dnolen18:02:05

patch welcome

mfikes19:02:44

Dang. Graal.js was renamed https://github.com/graalvm/graaljs/commit/f75dfccc31bc7622adc409d7f48da56009fe06c3 I suppose our repl env name is still ok

john21:02:18

@dnolen Yeah, you've been interested in seeing a higher level, "better api" for interacting with the analyzer for a while, haven't you?

dnolen21:02:41

we have cljs.analyzer.api right now

dnolen21:02:04

but something for checking &env for target would be useful

dnolen21:02:27

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

john21:02:07

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

dnolen21:02:11

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

dnolen21:02:24

so I wouldn't encourage such things

john21:02:22

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