You're right, and the manual even talks about the using eval to prevent code reuse. I guess it also depends on whether you are creating a bunch of functions in a one-time shot, or exposing a function creation interface that will be called as needed. Your example seems to be a case of the former, whereas I think macros are a better option for the latter (provided there is no run-time data needed for function creation). As an example there's @enum (https://github.com/JuliaLang/julia/blob/master/base/Enums.jl#L26), which generates multiple functions, but is only called by users.
But I still want to emphasize that I think the advice to always use functions over macros is not correct. Macros are valuable tools for pure code manipulation / generation and are also safer than functions because they don't use runtime data. I don't think people should be told to shy away from them. Thanks, Josh On Sunday, May 31, 2015 at 8:49:09 PM UTC-4, Tom Lee wrote: > > I'll concede that if you know the function name at runtime, Mauro's > solution may be a little cleaner, especially if it will be called a lot. > > There are plenty of examples in Base of @eval being used to define > functions, such as lines 11-18 here: > https://github.com/JuliaLang/julia/blob/861f02712eb4b41c08fed3f21c5a4206b8d669bc/base/int.jl > I've copied this pattern in my own code and found it extremely convenient. > I can't think of any examples of macros in Base which define functions. > > Cheers, > > Tom > > > On Monday, 1 June 2015 02:35:28 UTC+10, Josh Langsfeld wrote: >> >> I don't think this is correct actually. With Julia's metaprogramming >> abilities, all macros could be handled by runtime functions. >> >> The rule I follow is that macros should be used when some processing >> needs to be done at compile time / source-processing time. Usually, that's >> exactly when you want to programmatically generate code for a function. In >> particular, I thought it was widely regarded that calling on 'eval' was a >> sign you should consider using macros for your problem if possible. >> >> So I think the first reply from Mauro is the most Julian solution. Unless >> there's something really weird like the function name isn't known until >> runtime, in which case no macro can work. >> >> On Sunday, May 31, 2015 at 5:48:41 AM UTC-7, Tom Lee wrote: >>> >>> ... >>> >>> Also, I should clarify that when I wrote "My understanding is that you >>> should never use a macro if you can easily write an equivalent function" I >>> meant you should not create a new macro to do something that can just as >>> easily be done by a function - not that existing macros like @eval should >>> be avoided. >>> >>
