[Rd] proto and baseenv()

[Gabor Grothendieck]

That is how R works with free variables, e.g.

z <- 1
f <- function() z
f() # 1

so the current behavior seems consistent with the rest of R.

Note that the example below could be done like this to avoid the error:

> z <- 1
> proto(baseenv(), a = z)$a
[1] 1

On Thu, Feb 25, 2010 at 12:33 AM, Ben <misc7 at emerose.org> wrote:
> Wow, thanks for the heads-up.  That is horrible behavior.  But using
> baseenv() doesn't seem like the solution either.  I'm new to proto,
> but it seems like this is also a big drawback:
>
>> z <- 1
>> proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
>
>
> --
> Ben
>
>
> ----------------- Original message -----------------
> From: Peter Danenberg <pcd at roxygen.org>
> To: r-devel at r-project.org
> Date: Wed, 24 Feb 2010 22:38:54 -0600
> I understand why the following happens ($.proto delegates to get,
> which ascends the parent hierarchy up to globalenv()), but I still
> find it anti-intuitive:
>
>  > z <- 1
>  > y <- proto(a=2)
>  > y$z
>  [1] 1
>
> Although this is well-documented behavior; wouldn't it uphold the
> principle of least surprise to inherit instead from baseenv() or
> emptyenv()? (See attached patch.)
>
> Spurious parent definitions have already been the source of bizarre
> bugs, prompting me to use proto like this:
>
>  > z <- 1
>  > y <- proto(baseenv(), a=2)
>  > y$z
>  Error in get(x, env = this, inherits = inh) : object 'z' not found
>
> It's cumbersome, but it ensures that parent definitions don't pollute
> my object space; I would rather that be the default behaviour, though.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>