Fork me on GitHub
#cljs-dev
<
2016-09-13
>
anmonteiro12:09:18

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

anmonteiro12:09:46

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

anmonteiro12:09:42

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

dnolen12:09:40

@juhoteperi hrm, will take a look later

dnolen12:09:26

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

dnolen12:09:39

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

anmonteiro12:09:45

@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

anmonteiro12:09:25

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

dnolen12:09:02

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

dnolen12:09:15

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

anmonteiro12:09:49

yeah, sounds like a good enough reason to me

dnolen12:09:08

so you have to explicitly make the association

darwin13:09:11

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'

anmonteiro13:09:14

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

darwin13:09:40

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

anmonteiro13:09:48

sounds related?

darwin13:09:49

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

darwin13:09:14

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

dnolen13:09:23

the above behavior should be expected

dnolen13:09:35

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

darwin13:09:56

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)

darwin13:09:11

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

dnolen13:09:10

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

dnolen13:09:13

otherwise - no way

darwin13:09:04

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

darwin13:09:47

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)

dnolen13:09:03

this is just speculation

dnolen13:09:10

which you haven’t demonstrated

dnolen13:09:37

unless you have information, assume it works

dnolen13:09:45

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

dnolen13:09:54

and will undoubtable create chaos

darwin13:09:59

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)

dnolen13:09:15

not interested 🙂

dnolen13:09:43

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