> > Also note that since a macro is only an AST manipulation, it can't do > anything that couldn't be done by typing that same AST into your function > in the first place >
This is almost true, but note that there are some cases where a macro might generate Expression object that does not have a syntax, so they would be impossible to type. Eg. we don't have a special syntax for turning off bounds checking in a block of code, but we do have a AST expression that does that. Thus we have a macro @inbounds that wraps a block gives you access to the *:boundscheck* expression. Ivar kl. 21:56:58 UTC+2 lørdag 21. juni 2014 skrev Jameson følgende: > > Right. Also, to answer the reverse question, a macro can't do anything > with the value or type that will be assigned at runtime (this sounds > obvious, but comes up very often) > > Also note that since a macro is only an AST manipulation, it can't do > anything that couldn't be done by typing that same AST into your function > in the first place > > On Saturday, June 21, 2014, Patrick O'Leary <[email protected] > <javascript:>> wrote: > >> The answer to your question about the second part of Jameson's response >> is the first part of Jameson's response--at compile time you can still >> modify the syntax tree of the program. >> >> On Saturday, June 21, 2014 1:50:45 PM UTC-5, Andrew McKinlay wrote: >>> >>> What can I do at compile-time that I can't at run-time? >>> On Jun 21, 2014 2:49 PM, "Jameson Nash" <[email protected]> wrote: >>> >>>> A macro inserts the result back into the AST. and it is called at >>>> compile-time, not run-time. >>>> >>>> On Saturday, June 21, 2014, Andrew McKinlay <[email protected]> >>>> wrote: >>>> >>>>> What's the difference between writing macros versus functions that >>>>> take `Expr` objects? Is there anything you can't do with a function that >>>>> takes expression objects? Are there any advantages of using macros beyond >>>>> no having to quote the code you pass as an argument? >>>>> >>>>
