From ggrothendieck at gmail.com  Sat Feb 27 03:41:33 2010
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Fri, 26 Feb 2010 21:41:33 -0500
Subject: [Rd] proto and baseenv()
In-Reply-To: <20100226194635.1bfa3e50.misc7@emerose.org>
References: <20100225043854.GA26106@klutometis.wikitex.org> 
	<20100226022322.GB19263@klutometis.wikitex.org>
	<971536df1002251931r4972bcdes9c6910423fc52af6@mail.gmail.com> 
	<20100226041617.GB21674@klutometis.wikitex.org>
	<971536df1002252042q40b9b00do23b24370ea919482@mail.gmail.com> 
	<20100226054154.GA23715@klutometis.wikitex.org>
	<971536df1002260409ud3ca15od596bf7af753d8be@mail.gmail.com> 
	<20100226080112.72341a14.misc7@emerose.org>
	<971536df1002260628g663800c8pbb531a7565586b03@mail.gmail.com> 
	<20100226194635.1bfa3e50.misc7@emerose.org>
Message-ID: <971536df1002261841q6bfc95a5q167799d9cdb954c@mail.gmail.com>

On Fri, Feb 26, 2010 at 8:46 PM, Ben <misc7 at emerose.org> wrote:
> Maybe I'm still not getting something fundamental, but I didn't intend

I think you are missing the R search path.  Try this:

search()

That shows you the search path.  Normally it starts searching at the
beginning and moves forward.

> my "proto(baseenv(), expr={a <- z})$a" example to be realistic. ?In
> practice "a <- z" would be replaced with hundreds of lines of code,
> where many functions are called. ?In theory you could track down every
> function that's global or from another package and track them down,
> but then you would have to put dozens of extra lines of boilerplate.
> It's actually worse than that, as this example shows:
>
>> proto(baseenv(), f = function(.) sd(1:3))$f()
> Error in get("f", env = proto(baseenv(), f = function(.) sd(1:3)), inherits = TRUE)(proto(baseenv(), ?:
> ?could not find function "sd"
>> proto(baseenv(), sd = sd, f = function(.) sd(1:3))$f()
> Error in sd(1:3) : could not find function "var"

That's because sd is in stats, not in base and you told it to start
searching at the end of the search path rather than the beginning.
Try this:

> Object <- as.environment("package:stats")
> proto(Object, f = function(.) sd(1:3))$f()
[1] 1

>
> Not only would every external function have to be specifically
> declared with a separate argument, even unused functions may need to
> be declared. ?That means any change in the implementation of an
> external function could break this code.
>
> Again, I may be missing something since I'm new to proto, but I don't
> see why you're dismissing this example as "user error".
>
>
> --
> Ben Escoto
>
> ----------------- Original message -----------------
> From: Gabor Grothendieck <ggrothendieck at gmail.com>
> To: Ben <misc7 at emerose.org>
> Date: Fri, 26 Feb 2010 09:28:46 -0500
> On Fri, Feb 26, 2010 at 9:01 AM, Ben <misc7 at emerose.org> wrote:
>>
>>> In end it seems that your real beef is with R so perhaps you should
>>> be using a different language.
>>
>> In my case you may be right. ?I do think there are a million things
>> wrong with R. ?For instance, I was looking for a package that
>> overcomes two of the problems R IMHO has: namespace pollution and the
>> lack of an easy-to-use standard object system.
>>
>> Should I be using R? ?I do keep asking myself that same question...
>>
>>> With respect to proto its really just discussing whether to use
>>> proto(baseenv(), ...) vs proto(...)
>>
>> Unfortunately this doesn't fix the problem as was noted earlier:
>>
>>> z <- 1
>>> proto(baseenv(), expr={a <- z})$a
>> Error in eval(expr, envir, enclos) : object "z" not found
>>
>
> As already mentioned lets not confuse user error with actual problems
> pertaining to proto and R. ?It should have been written like this if
> that is what was wanted:
>
>> z <- 1
>> proto(baseenv(), a = z)$a
> [1] 1
>
>



[Rd] proto and baseenv()
Gabor Grothendieck