I'm not sure if it would help your case, but I did something similar for a
much simpler case. The result is kind of hideous but it works. I wanted to
expose a function called "debug" from the "Lumberjack.jl" logging package
as a macro, so function arguments would not be evaluated when the current
loglevel was less verbose. I'm sure there is a less hideous way to do this,
but this is what ended up working after trial and error:
using Lumberjack # defines the "debug" function, among others
macro debug(msg) :(esc(debug(string($(esc(msg)))))) end
So inside the macro, "debug" resolves to a function defined in the scope of
this file (through the "using Lumberjack" statement). Other files that
import this one do not import Lumberjack, yet this macro works, which is
why I think it might be similar to your case.
On Friday, June 13, 2014 1:45:52 PM UTC-4, Andrew McKinlay wrote:
>
> Is it possible to quote code where the methods are already resolved? For
> example, instead of `+` being a symbol in the quoted code, it would be
> resolved to the + operator from the current module?
>
> On Friday, May 23, 2014 8:31:19 PM UTC-4, Isaiah wrote:
>>
>> parse("...codez...") can be helpful too.
>>
>> For (1) & (2), the single-quoted numbers are interpreted as literals
>> rather than symbols. It is possible to create a Symbol called `:1` with
>> `symbol("1")`, if needed, but that seems strange. The entry syntax `:1`
>> might be disallowed for efficiency and disambiguation - I'm not sure.
>>
>> For (3), in general, a TopNode tells the compiler to resolve any names to
>> the current base module. It might be illustrative to look at the difference
>> between these expressions:
>>
>> julia> a = 1
>> 1
>>
>> julia> :($a + 1)
>> :(1 + 1)
>>
>> julia> :(1+:(a+2))
>> :(1 + :(a + 2))
>>
>> julia> :(1+:($a+2))
>> :(1 + top(Expr)(:call,:+,a,2))
>>
>> The last case asks for an interpolation which cannot be expanded at parse
>> time, because the interpolation is quoted. The `top(Expr)` and `call` are
>> generated to guarantee that `foo` - whatever the value of `foo` ends up as
>> in the Top module namespace - is used when the expression is evaluated.
>>
>> (as an aside, eval'ing those last two examples will give errors,
>> because it is not possible to add an Int and an Expr)
>>
>>
>>
>>
>>
>> On Fri, May 23, 2014 at 3:53 PM, Adam Smith <swiss.arm...@gmail.com>
>> wrote:
>>
>>> I find it quite helpful to use dump() on expressions to see the first
>>> few levels of the parsed AST. That makes it easier to see what Julia is
>>> doing with your expressions.
>>>
>>>
>>> On Thursday, May 22, 2014 5:17:13 PM UTC-4, Andrew McKinlay wrote:
>>>>
>>>> I have been trying to grok Julia macros, so I've dived into the
>>>> metaprogramming docs. Whilst playing around with the interpreter, I've run
>>>> into some peculiarities that I don't quite understand.
>>>>
>>>> julia> versioninfo()
>>>> Julia Version 0.3.0-prerelease+2690
>>>> Commit e4c2f68* (2014-04-20 12:15 UTC)
>>>> ...
>>>>
>>>>
>>>> 1. Why is typeof( :(:(1+2)) ) == Expr, but typeof( :(:(1)) ) ==
>>>> QuoteNode?
>>>> 2. Why is typeof( :(1) ) == Int64, but again typeof( :(:(1)) ) ==
>>>> QuoteNode?
>>>> 3. Why is typeof( :(1+:($1+2)).args[3].args[1] ) == TopNode?
>>>>
>>>>
>>>> I was assuming that quoting was just a shorthand way for constructing
>>>> expressions, since the docs say:
>>>>
>>>>> There is special syntax for “quoting” code (analogous to quoting
>>>>> strings) that makes it easy to create expression objects without
>>>>> explicitly
>>>>> constructing Expr objects.
>>>>
>>>> But the types of objects constructed by quoting do not always take the
>>>> form of an Expr, as above.
>>>>
>>>> What is going on here?
>>>>
>>>
>>
