Part of the confusion actually comes from the overspecificity of the documentation. When the actual majority of the verbiage in a manual page is given to how a function "evaluates" its argument, one tends to infer (by the flouting of Grice's maxim of quantity) that this term "evaluation" refers to something _other_ then the ordinary thing that the vast majority of R functions do. Really, withVisible just treats its argument the way you would expect any R primitive function to treat its argument unless noted otherwise. Problem is its man page spends a lot of time appearing to note otherwise.
Another confusion comes from using the same term "evaluate" to refer to both the ordinary case of a function obtaining the value of its argument and to the meta-level treatment of a value as more code to run. While it is an uncommon characteristic of R that functions can choose when and whether their arguments are evaluated, I don't think it is very felicitous to use the same term "evaluate" for the normal case _as well as_ for its violations. Literally, deleting 50% of withVisible's man page would make its intent more clear. Peter On Thu, Aug 15, 2013 at 5:59 AM, Simon Urbanek <simon.urba...@r-project.org>wrote: > > On Aug 15, 2013, at 3:06 AM, Gabriel Becker wrote: > > > On Wed, Aug 14, 2013 at 11:14 PM, Peter Meilstrup < > peter.meilst...@gmail.com > >> wrote: > > > >> I agree that the present behavior of withVisible is the Right Thing, but > >> the documentation is confusing. The documentation claims that > withVisible > >> "evaluates an expression." > >> > >> This may capture an inside view of how the .Internal function is > >> implemented, but is nonsense from the R user's standpoint, where > >> "expression" is a particular type of R object and "evaluate an > expression" > >> means to do something like eval(). > >> > > > > And particularly, if you pass withVisible a variable containing an > > expression, said expression is not evaluated. The expression/symbol > > pointing to the object where it is stored is, I know, but the expression > > itself is not. > > > > Furthermore, the exact same language ("evaluate an expression") appears > in > > the eval documentation, and that function DOES evaluate the actual > > expression. Thus my (apparently incorrect) assumption that they should > have > > the same behavior. > > > > I think the confusion comes from the misunderstanding of what gets > evaluated when. The simplest way to explain is that withVisible() is > equivalent to evalq(), but you're thinking of eval() which does two > evaluations (the argument is evaluated and then the value of the argument > is evaluated). Note that this is documented very explicitly: > > "evalÂ’ evaluates its first argument in the current scope before passing it > to the evaluator" > > whereas withVisible only does the first part: > > "The argument is evaluated in the caller's context." > > Cheers, > Simon > > > > > ~G > > > > > >> > >> Peter > >> > >> > >> On Wed, Aug 14, 2013 at 11:04 PM, peter dalgaard <pda...@gmail.com> > wrote: > >> > >>> > >>> On Aug 15, 2013, at 01:46 , Gabriel Becker wrote: > >>> > >>>> R-team, > >>>> > >>>> The $value element of the return value of *withVisible* does not agree > >>> with > >>>> the return value of *eval* when *withVisible* is passed a variable > >>> (symbol) > >>>> containing an expression object or anonymous code/expressions which > >>>> generates an expression object when evaluated (such as calls to > *parse* > >>> or * > >>>> expression*). > >>>> > >>>> I have attached a patch against the svn trunk which addresses this. > >>>> > >>>> Example (under devel r63577): > >>>> > >>>>> withVisible(parse(text="5+pi")) > >>>> $value > >>>> *expression(5+pi)* > >>>> > >>>> $visible > >>>> [1] TRUE > >>>> > >>>>> eval(parse(text="5+pi")) > >>>> *[1] 8.141593* > >>>> > >>> > >>> I don't think that is a bug, it is by design. The comparison should be > to > >>> what happens if you just type the expression at the prompt: > >>> > >>>> parse(text="5+pi") > >>> expression(5+pi) > >>> > >>> > >>>> With the attached patch this is no longer the case: > >>> > >>> ...so the patch introduces a bug since you can no longer withVisible() > >>> something that returns a language object. > >>> > >>>> > >>>>> withVisible(parse(text="5+pi")) > >>>> $value > >>>> *[1] 8.141593* > >>>> > >>>> $visible > >>>> [1] TRUE > >>>> > >>>> The patch changes only the withVisible function in eval.c. I'm happy > to > >>>> work with / at the direction of an R-core member to get the patch into > >>> an > >>>> different form/coding style/fix strategy/etc if its current form is > not > >>>> acceptable. > >>>> > >>>> Thanks, > >>>> ~G > >>>> > >>>>> sessionInfo() > >>>> R Under development (unstable) (2013-08-14 r63577) > >>>> Platform: x86_64-unknown-linux-gnu (64-bit) > >>>> > >>>> locale: > >>>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > >>>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 > >>>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 > >>>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > >>>> [9] LC_ADDRESS=C LC_TELEPHONE=C > >>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > >>>> > >>>> attached base packages: > >>>> [1] stats graphics grDevices utils datasets methods base > >>>> > >>>> > >>>> > >>>> -- > >>>> Gabriel Becker > >>>> Graduate Student > >>>> Statistics Department > >>>> University of California, Davis > >>>> ______________________________________________ > >>>> R-devel@r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >>> -- > >>> Peter Dalgaard, Professor, > >>> Center for Statistics, Copenhagen Business School > >>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark > >>> Phone: (+45)38153501 > >>> Email: pd....@cbs.dk Priv: pda...@gmail.com > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > >> > > > > > > -- > > Gabriel Becker > > Graduate Student > > Statistics Department > > University of California, Davis > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel