Determines whether the function with the given id is strict, i.e., whether calling it forces its arguments.
Ternary#Always says every call forces every parameter, Ternary#Never that no call forces
all of them, and Ternary#Maybe that it depends on the path taken, on the caller, or on a function
flowR could not resolve. A definition without parameters has nothing to leave unforced and is strict.
The analysis follows an argument that is handed on into the function receiving it, and treats a read in a
default, in a loop, in a branch, or in a nested definition as one that may not happen. What a built-in
does with an argument is not guessed from its name: an argument stated ArgProp.Nse or
ArgProp.Presence is never evaluated, one stated ArgProp.Forced always is, and the calls
reaching an argument only on the way the run takes are the ones flowR hands to the processor that says so
(switch picking a branch, try reaching a handler, a hook running at exit).
A body reading its own call or frame (CallProp.Frame: match.call(), nargs(),
as.list(environment())) reaches every parameter without naming one, so none of them is answered Never.
For a generic, the methods reached by S3 dispatch decide: they agree on a parameter or it is left open,
while the object the dispatch is on is forced by the dispatch itself. A NextMethod carries the same
question on to the methods it reaches, matched by the position the parameter is written in.
An argument in ... is followed to the parameter it binds to, whereas the method of an object flowR
cannot resolve (obj$m(x)) is one more thing it cannot claim anything about.
Cyclic dependencies between functions and calls flowR cannot resolve answer Ternary#Maybe, so this
only claims certainty where the code gives it.
What a built-in does with an argument comes from the ArgProp bits its signature states, so a
configured or overwritten built-in is the one that answers when the analyzer context is handed along.
Determines whether the function with the given id is strict, i.e., whether calling it forces its arguments. Ternary#Always says every call forces every parameter, Ternary#Never that no call forces all of them, and Ternary#Maybe that it depends on the path taken, on the caller, or on a function flowR could not resolve. A definition without parameters has nothing to leave unforced and is strict.
The analysis follows an argument that is handed on into the function receiving it, and treats a read in a default, in a loop, in a branch, or in a nested definition as one that may not happen. What a built-in does with an argument is not guessed from its name: an argument stated ArgProp.Nse or ArgProp.Presence is never evaluated, one stated ArgProp.Forced always is, and the calls reaching an argument only on the way the run takes are the ones flowR hands to the processor that says so (
switchpicking a branch,tryreaching a handler, a hook running at exit). A body reading its own call or frame (CallProp.Frame:match.call(),nargs(),as.list(environment())) reaches every parameter without naming one, so none of them is answeredNever. For a generic, the methods reached by S3 dispatch decide: they agree on a parameter or it is left open, while the object the dispatch is on is forced by the dispatch itself. ANextMethodcarries the same question on to the methods it reaches, matched by the position the parameter is written in. An argument in...is followed to the parameter it binds to, whereas the method of an object flowR cannot resolve (obj$m(x)) is one more thing it cannot claim anything about. Cyclic dependencies between functions and calls flowR cannot resolve answer Ternary#Maybe, so this only claims certainty where the code gives it. What a built-in does with an argument comes from the ArgProp bits its signature states, so a configured or overwritten built-in is the one that answers when the analyzer context is handed along.