On 21/06/2020 11:37 a.m., Benjamin Tyner wrote:
On 6/20/20 5:04 PM, Duncan Murdoch wrote:
I think you effectively did that in your original post (all but
encapsulating the expression in a function), so yes, it's possible.
However, it's a really bad idea. Why use non-standard evaluation when
standard evaluation is fine? Standard evaluation follows some well
defined rules, and is easy to reason about. NSE follows whatever
rules it wants, so it's really hard for users to follow. For example,
assuming you had the g() you want, what would this give?
z <- 3
f(x = z, y = g(z))
You can't possibly know that without knowing whether there's a local
variable in f named z that is created before y is evaluated.
Duncan Murdoch
Very good point, and I agree it's best to use standard evaluation
whenever possible. The role of g would essentially be to modify one or
more elements of f's formals in-place. For example calling:
f(x = 3, y = g(expr))
would be equivalent to calling a function fm:
fm(x = 3)
where the body of fm is identical to that of f, but:
> formals(fm)
$x
$y
expr
though I expect g would be non-trivial to code up robustly.
I would still say that's a bad idea. The defaults for a function's
arguments are decided by the function's author, so it makes sense for
them to be evaluated in the evaluation frame of the function. The
actual arguments given to the function are decided by whoever calls it,
so they should be evaluated in the caller's environment. That's
standard evaluation.
What you're trying to do mixes up these things: you want the caller to
be able to evaluate things that depend on function internals. That is
bad, because it means the function can no longer be a black box that
does what it is documented to do: it also needs to do it in exactly the
way it did when the caller wrote g(expr), or that could give a garbage
value. Effectively you've broken the encapsulation that functions give
you. You've made f() part of whatever function calls it (but imposed
the rule that says the source of f() can't be modified, which makes no
sense).
Duncan Murdoch
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
