From misc7 at emerose.org  Thu Feb 25 14:50:38 2010
From: misc7 at emerose.org (Ben)
Date: Thu, 25 Feb 2010 07:50:38 -0600
Subject: [Rd] proto and baseenv()
In-Reply-To: <4B8666E0.4070808@TU-Dresden.de>
References: <20100225043854.GA26106@klutometis.wikitex.org>
	<20100224233350.4e3da5db.misc7@emerose.org>
	<4B8666E0.4070808@TU-Dresden.de>
Message-ID: <20100225075038.79ca9b63.misc7@emerose.org>

I was disappointed in this behavior because it seems error-prone.
Suppose I declare an environment

> b <- 1
> p <- proto(expr={
    a <- 2
+   ...
+ })
> p$a
[1] 2
> p$b
[1] 1

Presumably if I ask for p$a or p$b later, it's because I'm interesting
in the value of "p$a" or "p$b" that I specifically put inside that
environment.  Otherwise I would just ask for "a" or "b".  If I'm
asking for "p$b" it the above case, that means I forgot to declare b
inside p.  In this case there should be an error telling me that, not
a silent substitution of the wrong quantity.

If someone wanted to do the y$ls() thing, they could always

> y <- proto(a=1)
> with(y, ls())
[1] "a"

Another reason is that there are plenty of other programming languages
that have similar structures and this behavior is very odd.  In
standard languages asking for "b" inside the "p" object gives you an
error, and no one complains.  Even in R, we have this behavior:

> z <- 1
> list(a=3)$z
NULL

(Actually I think the above should be an error, but at least it isn't
1.)  So anyway, I'm not saying that p$b being 1 is an outright 2+2=5
bug, but it does seem to be surprising behavior that leads to bugs.
But I'm sure you're right that there are historical/structural reasons
for this to be the case, so perhaps there's no solution.


-- 
Ben Escoto

----------------- Original message -----------------
From: Thomas Petzoldt <Thomas.Petzoldt at TU-Dresden.de>
To: Ben <misc7 at emerose.org>
Date: Thu, 25 Feb 2010 13:02:40 +0100
Am 25.02.2010 06:33, wrote Ben:
> 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
>
>

I would say that this behaviour is intentional and not "horrible". proto 
objects do simply the same as ordinary functions in R that have also 
full access to variables and functions at a higher level:

Try the following:

 > y <- proto(a=2)
 > y$ls()
[1] "a"


ls() is defined in package base and so would even work if you inherit 
from baseenv() so why it is surprising that proto objects (by default) 
inherit objects from other packages and from the user workspace?


Thomas P.



[Rd] proto and baseenv()
Ben