That looks like the output of :(esc(fn)), but you don't want to quote that,
you want to evaluate it when generating the code, i.e. use $(esc(fn))
wherever you were previously using $fn
On Friday, August 1, 2014 11:38:44 AM UTC-4, Abe Schneider wrote:
>
> That's correct, I'm generating code that keeps a pointer to that function
> to call later on.
>
> If I do that, I have the type `esc(fn)` in the macro (this is what I get
> when printing it out), and taking a dump of that argument gives:
>
> Expr
> head: Symbol call
> args: Array(Any,(2,))
> 1: Symbol esc
> 2: Symbol fn
> typ: Any
>
>
> Does that mean instead of carrying around a function I will need to carry
> around the Expr?
>
> Thanks!
>
> On Friday, August 1, 2014 11:17:50 AM UTC-4, Simon Kornblith wrote:
>>
>> Assuming you're generating code that calls fn, as opposed to trying to
>> call it when generating code in the macro (usually a bad idea), you should
>> use esc(fn) in place of fn
>>
>> On Friday, August 1, 2014 10:50:15 AM UTC-4, Abe Schneider wrote:
>>>
>>> I've come across a problem where I have macro to define a grammar
>>> (similar to how PEGParser currently works):
>>>
>>> @grammar foo begin
>>> rule[fn] = "some" + ("rule" | "test")
>>> end
>>>
>>> where the `[fn]` next to the rule defines a function to call on the
>>> results (in this case it's an expansion). The issue is that parsing the
>>> Expr tree, `fn` is given as a Symbol (which makes sense).
>>>
>>> However, if I try to turn `fn` into a function I run into the namespace
>>> issue I've had previously. If `fn` is defined in my module, it works
>>> without problem. If it's defined in the code that imports the module, it
>>> will not work because that function doesn't exist in the namespace of the
>>> module.
>>>
>>> I'm guessing there isn't an easy solution to fix this problem, but I
>>> thought I'd check to see if someone had an idea.
>>>
>>> Thanks!
>>>
>>>
