Peter Meilstrup

There is also the problem where you might want to use a function in the expansion of a macro which is overridden in the target environment. Perhaps could look at...

Namespace problems with function calls can be avoided completely if you template in the literal function objects rather than their names. This makes tracebacks rather hard to read though.

If you use the idiom that every macro creates a lambda to do its work in, then including a gensym facility in `template` for local macro vars could work for...

Or not even a gensym: put the things you want to evaluate in the target env in inline function arguments. So a hygienic R macro ``` stuff + syntactic_transform(other_stuff) ```...

Another possibility : wrap text of every arg in a literal closure that preserves the environment. Macro result evaled in env. of macro, while wrapped args recover env of body....

Also need a "str" method for dots objects.

For those rare times when you actually want the calling environment (rather than the lexical env of an argument) there should be calling_env, which does that, but throws an error...

On [inspection](https://gist.github.com/crowding/39bed8c990f59792fd71), I use deeply nested `.` all the time.

It is also required for passing CRAN documentation checks.

I can check JIT optimization at package load, but does that affect the compilation that is done when the package is byte-compiled?