Re: [Rd] Inconsistency between eval and withVisible (with patch)
On Thu, Aug 15, 2013 at 5:59 AM, Simon Urbanek wrote: > Note that this is documented very explicitly: > > "eval evaluates its first argument in the current scope before passing it > to the evaluator" > But the same man page also describes "eval" like this: 'eval' evaluates the 'expr' argument in the environment specified by 'envir' and returns the computed value. So, does "eval" perform one round of evaluation, or two? Does "evaluates [some] argument" refer to the ordinary process of obtaining the argument's value value, or to the feeding of that value back to the evaluator? Does this "evaluation" take place in the environment passed as argument, or the calling environment? I'm familiar with what 'eval' actually does, but its description in the man page is incoherent. Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency between eval and withVisible (with patch)
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
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
> 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-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US
Re: [Rd] Inconsistency between eval and withVisible (with patch)
On Aug 15, 2013, at 3:06 AM, Gabriel Becker wrote:
> On Wed, Aug 14, 2013 at 11:14 PM, Peter Meilstrup > 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 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-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_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
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency between eval and withVisible (with patch)
On Wed, Aug 14, 2013 at 11:14 PM, Peter Meilstrup 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.
~G
>
> Peter
>
>
> On Wed, Aug 14, 2013 at 11:04 PM, peter dalgaard 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-8LC_COLLATE=en_US.UTF-8
>> > [5] LC_MONETARY=en_US.UTF-8LC_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
Re: [Rd] Inconsistency between eval and withVisible (with patch)
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(). Peter On Wed, Aug 14, 2013 at 11:04 PM, peter dalgaard 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-8LC_COLLATE=en_US.UTF-8 > > [5] LC_MONETARY=en_US.UTF-8LC_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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency between eval and withVisible (with patch)
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-8LC_COLLATE=en_US.UTF-8 > [5] LC_MONETARY=en_US.UTF-8LC_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
[Rd] Inconsistency between eval and withVisible (with patch)
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* With the attached patch this is no longer the case: > 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-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_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
