Block macros name their argument tree, although technically what gets passed in is a forest (as a list of trees). It would be more descriptive, if the argument name somehow indicated this.
As pointed out by @azazel75 in private communication, AST objects that accept a sequence of statements usually call it body; so we could use that name here, too.
From my own experience, the same convention applies in Racket - which is for the most part very pedantic about terminology - so body is likely the "correct" name as far as there is one.
So, in block macros, changing the argument name from tree to body would make the resulting code more self-explanatory. This applies only to block macros. Expr macros take one expression, and decorator macros take one function or class definition; these are trees.
On the other hand, the current single name has the advantage that it's the same for all three kinds of macros.
Another viewpoint is, on some occasions, it would be useful to name the argument subtree or something else (e.g. in an inner definition for a Walker). If the tree argument was passed positionally instead of by name, each call site could use the locally most appropriate name. But then there is no guarantee on any consistency in naming.
Thoughts?
Block macros name their argument
tree, although technically what gets passed in is a forest (as a list of trees). It would be more descriptive, if the argument name somehow indicated this.As pointed out by @azazel75 in private communication, AST objects that accept a sequence of statements usually call it
body; so we could use that name here, too.From my own experience, the same convention applies in Racket - which is for the most part very pedantic about terminology - so
bodyis likely the "correct" name as far as there is one.So, in block macros, changing the argument name from
treetobodywould make the resulting code more self-explanatory. This applies only to block macros. Expr macros take one expression, and decorator macros take one function or class definition; these are trees.On the other hand, the current single name has the advantage that it's the same for all three kinds of macros.
Another viewpoint is, on some occasions, it would be useful to name the argument
subtreeor something else (e.g. in an inner definition for aWalker). If thetreeargument was passed positionally instead of by name, each call site could use the locally most appropriate name. But then there is no guarantee on any consistency in naming.Thoughts?