one situation where implicit macro loading doesn’t work: you have foo.bar namespace which declares macros and in bar.cljs you don’t require-macros from itself in foo.other you require foo.bar :refer [a macro] throws saying a macro doesn’t exist but if you refer-macros [a macro] everything works fine

@dnolen I’m trying to understand if this is by design or should maybe be the focus of future work in implicit macro loading

it could possibly (can’t know without trying) solve the problem of using require-macros in an own namespace for bootstrap CLJS, which currently throws max call stack exceeded

@juhoteperi hrm, will take a look later

@anmonteiro you need to make the explicit link between a macro ns and the runtime ns of the same name

none of the implicit stuff works if you don’t do this - by design

@dnolen I’m trying to understand why that is. is there a JIRA design page or issue that discusses this? I can maybe see one reason which is undesired side effects if you don’t make the explicit link

e.g. if you don’t want to require-macros by default there would be no way to express that. probably a good enough reason

@anmonteiro making a link based on the name is never going to be safe

there might be another namespace with same name for who knows what reason

yeah, sounds like a good enough reason to me

so you have to explicitly make the association

yesterday I was playing with #js values and it seems like strings are emitted into javascript as they are without escaping backslashes, it manifested this way: I would expect #js {“key\\x” 0} to product js object with key ‘key\x’ (single backslash), but instead it gives me ‘keyx’, I have to double backslash it #js {“key\\\\x” 0}, so java string is ‘key\\’ and when emitted to js, it gets again interpreted as a backslash and produces object with key ‘key\x'

@darwin have you tried it in any other engine than V8?

not yet, just wanted to mention it here if it is worth investigating further

https://github.com/clojure/clojurescript/blob/master/src/test/cljs/cljs/core_test.cljs#L558

sounds related?

but if it is what I think it is, it will be failing in all js engines

we simply emit strings as they are into javascript, not expecting backslashes

the above behavior should be expected

you want to see slashes in source you need to double backslash

that V8 fail can be related, if you escape something which makes no sense to be escaped, some js engine could complain and other just silently use unescaped version (I can imagine)

dnolen: ok, I can live with that, but it was quite surprising for me

if you can demonstrate this somehow different from how we emit strings in general - then something to look at

otherwise - no way

I might investigate it further, because now I feel quite insecure, emitting strings from macros into cljs code in general if they have the same issue

e.g. I have a string loaded from outside, I want to emit it as-is via a macro, and if it happens to include backslashes I will end up with a different string in JS (cljs)

this is just speculation

which you haven’t demonstrated

indeed

anyways

unless you have information, assume it works

and we’re not changing the above, it’s been that way for 5 years

and will undoubtable create chaos

I understand that touching such thing would break code in the wild, at least we could have some helper fn, which would escape “unknown” strings when being emitted (on demand for people who know this)

not interested 🙂

ok 🙂

my official stance on this can be documented as “non-issue”