Clojurians Log v2

Macros are expanded away before rewriting, but they are expanded using tools.analyzer which isn't necessarily exactly the same expansion environment as what you get from the compiler

Ah, that might be what's causing my issue then, since I'm making use of &env.

I don't know about tools.analyzer, but Ridley will handle &env properly: https://github.com/xadecimal/riddley

I do wish the compiler exposed a macroexpansion that was exactly the same it used though.

The problem is &env leaks compiler internals, the values in the map are whatever internal class in the compiler

tools.analyzer does pass &env when it does macro expansion, but it uses its own locals representation as the values in the env map instead of trying to instantiate what the compiler uses

I'm unsure what exactly is going on, but I'm getting a Too many arguments in method signature in class file error, so I think maybe there's some feedback loop going on between go and my macro, though adding debug statements to my macro doesn't reveal anything off.

I think I'll try redesigning it and hope the new version works. As clever as core.async is, it does have some rather gnarly edge conditions.

That is interesting, to my knowledge the fns generated by the go macro all take just a few args

I did think it was one of the functions that my macro generated, but when I put a few print statements into my macro that didn't seem to be the case. However, I believe I can take out the go-blocks until the last stage, which should prevent bad interactions between my macro and the go macro.