Added one other comment below.
On Fri, Feb 26, 2010 at 9:41 PM, Gabor Grothendieck
<ggrothendi...@gmail.com> wrote:
> On Fri, Feb 26, 2010 at 8:46 PM, Ben <mi...@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")
or if you just want to exlude the global environment but still include
any loaded packages:
Object <- as.environment(2)
(If you have not loaded any packages then the two Object<- statements
have the same effect but if there are loaded packages the second
includes them while the first excludes them.)
>> 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 <ggrothendi...@gmail.com>
>> To: Ben <mi...@emerose.org>
>> Date: Fri, 26 Feb 2010 09:28:46 -0500
>> On Fri, Feb 26, 2010 at 9:01 AM, Ben <mi...@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
>>
>>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
