the predicate function is to be evaluated in the environment of the formula list(check_item) ~ predicate.
The scope of evaluation of the right-hand side of the formula check_item is a bit more delicate: the environment of the rhs of check_item must be in scope, with precedence given, however, to arguments of f, which are then found in an isolated (temporary) environment of promise objects. (In the “Tidy Evaluation” framework, we would say that the arguments overscope the context of the check item.)
Thus, when validating a check item, three environments are in play:
An environment of promises (the arguments of f as they are called).
The environment of check_item.
The environment of the formula list(check_item) ~ predicate.
These are generally not linearly ordered, so creating the proper transformation of the validation expression, and the proper environment in which to evaluate it, requires care. Thus, check_item is a quosure, in the tidy-eval sense.
One approach to ensuring that the validation occurs with the proper lexical scoping is as follows:
Tabluate the check-item environments in the data frame of checks (currently, only the environment of the check formula is recorded)
Modify the validation environment so that its parent is the environment of the formula check_item.
Bind the predicate(s) and the temporary environment of promises (whose parent is the environment of f) to the validation environment, which should contain no other bindings. (Potential name clashes in higher in the chain of environments can be virtually eliminated by using randomly generated names.)
For example, if we were to do this
a <- 1
is_positive <- function(.) . > 0
foo <- firmly(function(x) NULL, list(~x - a) ~ is_positive)
then the validation of the condition “is_positive(x - a)” should be translated to something like
`__PREDICATE__`(get("x", envir = `__PROMISES__`) - a)
and evaluated in an environment containing exactly two bindings, __PREDICATE__, __PROMISES__, and whose parent is the environment of the check item ~x - a. The binding __PREDICATE__ gets the predicate function is_positive, while the binding __PROMISES__ gets a (temporary) environment of promises of f.
In this example, the environment of the check item and the environment of the ambient formula are identical; in general, however, they could be quite different, e.g., localized check makers created in a package should not, when called, endow their check items with the same environment.
Alternative approach
Keep the current validation-evaluation framework as is, but allow check items to be quosures, cf. #39.
egnha
commented
7 years ago
When creating a firm closure, say
the predicate function is to be evaluated in the environment of the formula
list(check_item) ~ predicate.The scope of evaluation of the right-hand side of the formula
check_itemis a bit more delicate: the environment of the rhs ofcheck_itemmust be in scope, with precedence given, however, to arguments off, which are then found in an isolated (temporary) environment of promise objects. (In the “Tidy Evaluation” framework, we would say that the arguments overscope the context of the check item.)Thus, when validating a check item, three environments are in play:
fas they are called).check_item.list(check_item) ~ predicate.These are generally not linearly ordered, so creating the proper transformation of the validation expression, and the proper environment in which to evaluate it, requires care. Thus,
check_itemis a quosure, in the tidy-eval sense.One approach to ensuring that the validation occurs with the proper lexical scoping is as follows:
check_item.f) to the validation environment, which should contain no other bindings. (Potential name clashes in higher in the chain of environments can be virtually eliminated by using randomly generated names.)For example, if we were to do this
then the validation of the condition “
is_positive(x - a)” should be translated to something likeand evaluated in an environment containing exactly two bindings,
__PREDICATE__,__PROMISES__, and whose parent is the environment of the check item~x - a. The binding__PREDICATE__gets the predicate functionis_positive, while the binding__PROMISES__gets a (temporary) environment of promises off.In this example, the environment of the check item and the environment of the ambient formula are identical; in general, however, they could be quite different, e.g., localized check makers created in a package should not, when called, endow their check items with the same environment.
Alternative approach Keep the current validation-evaluation framework as is, but allow check items to be quosures, cf. #39.