Marker for magrittr call frames

[lionel-]

We are currently porting the tidyverse to the tidy evaluation framework and one aspect of this is to establish pronouns in DSLs so users can be explicit about scoping. E.g. dplyr will have a .data pronoun for the input data frame and a .env pronoun for the calling context.

.env currently gives surprising results with magrittr. E.g. if you have foo defined in the current context, .env$foo doesn't work because .env is actually a child of the calling environment (so it can install the magrittr pronoun .).

The only clean way I can see to solve this is to have magrittr add an attribute or some kind of marker to its frame environment. This marker should resolve to the real calling environment so we don't have to worry about future changes in magrittr internals (i.e. magrittr frames can become a grandchild of the calling env if they ever need to). It's still a bit annoying because we require specific support for magrittr in all functions that need the real parent.frame(), but at least this would provide a robust solution.

cc @hadley

[smbache]

Would you have a look at the "update" branch to see how it could be implemented in that one? It is a simpler function being "compiled" for the pipeline and will be the way going forward. I have just been too busy to finalize it.

[lionel-]

Just tried the branch, the same problem occurs and the same solution would fix it.

Nice stacktrace by the way. Too bad we can't access the value of R_visible other than with withVisible()... Maybe they'd accept a patch making it a primitive, so the trace would be even nicer in future versions of R.

[lionel-]

I can send a PR to install the marker if you'd like. A simple __magrittr_caller_env binding should do it.

[smbache]

Sure - better do it to the update branch. That really should be master.

[krlmlr]

@lionel-: Any updates here? Looks like the currently skipped "filter understands .env in a pipe" tests are related to this problem.

[lionel-]

I have a PR ready but haven't sent it because it's possible we are going to play down the .env pronoun. It isn't as useful since we now have unquoting.

[hadley]

Given that we're only using .env very occasionally now, I think we can just say that it's not compatible with the pipe.