R devel - Jul 2023 - question about an R idiom: eval()ing a quoted block

In a few places in the R source code, such as the $initialize element 
of `family` objects, and in the body of power.t.test() (possibly other 
power.* functions), sets of instructions that will need to be run later 
are encapsulated by saving them as an expression and later applying 
eval(), rather than as a function. This seems weird to me; the only 
reason I can think of for doing it this way is to avoid having to pass 
back multiple objects and assign them in the calling environment (since 
R doesn't have a particularly nice form of Python's tuple-unpacking
idiom).

   Am I missing something?

  cheers
    Ben


https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52

https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171

On 11/07/2023 6:01 p.m., Ben Bolker wrote:
>     In a few places in the R source code, such as the $initialize element
> of `family` objects, and in the body of power.t.test() (possibly other
> power.* functions), sets of instructions that will need to be run later
> are encapsulated by saving them as an expression and later applying
> eval(), rather than as a function. This seems weird to me; the only
> reason I can think of for doing it this way is to avoid having to pass
> back multiple objects and assign them in the calling environment (since
> R doesn't have a particularly nice form of Python's tuple-unpacking
idiom).
> 
>     Am I missing something?
> 
>    cheers
>      Ben
> 
> 
>
https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52
> 
>
https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171
Those examples are very old (the second is at least 20 years old).  It 
may be they were written by someone who was thinking in S rather than in 
R.

As far as I recall (but I might be wrong), S didn't have the same 
scoping rules for accessing and modifying local variables in a function 
from a nested function.

Duncan Murdoch

In the case of power.t.test, there is a situation where you want to create 4
different functions with the same function body, in order to pass them to
uniroot(). I think that at the time, it just seemed convenient to express that
idea with a quote-eval (macro-like) construction, rather than figure out how to
do it with functions. I suppose that it could have been done neatly enough along
the lines of

g <- function(x1, x2, x3, x4)
{
  f <- function(x1, x2, x3, x4) {...body...}
  if (is.null(x1)
     x1 <- uniroot(function(x1) {target - f(x1, x2, x3, x4)}, ....)$root
  ....
}

This adds an extra layer of function call, but probably makes the byte compiler
happier!

You might also use the ... argument to uniroot() as in

x1 <- uniroot(f, x2=x2, x3=x3, x4=x4, ..other args..)$root

but that gets a bit clunky.

-pd
> On 12 Jul 2023, at 00:01 , Ben Bolker <bbolker at gmail.com> wrote:
> 
>  In a few places in the R source code, such as the $initialize element of
`family` objects, and in the body of power.t.test() (possibly other power.*
functions), sets of instructions that will need to be run later are encapsulated
by saving them as an expression and later applying eval(), rather than as a
function. This seems weird to me; the only reason I can think of for doing it
this way is to avoid having to pass back multiple objects and assign them in the
calling environment (since R doesn't have a particularly nice form of
Python's tuple-unpacking idiom).
> 
>  Am I missing something?
> 
> cheers
>   Ben
> 
> 
>
https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52
> 
>
https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171
> 
> ______________________________________________
> R-devel at 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
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com