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

Reply via email to