[Rd] proto and baseenv()

[Duncan Murdoch]

On 26/02/2010 7:09 AM, Gabor Grothendieck wrote:
> On Fri, Feb 26, 2010 at 12:41 AM, Peter Danenberg <pcd at roxygen.org> wrote:
>>> Also other object systems which are alternatives to proto seem less
>>> relevant than basic scoping and free variable lookup in functions.
>> Sorry, but that seems absurd; object systems are less relevant to each
>> other than the totally orthogonal question of scope?
> 
> Yes, if you are using one then obviously you have decided to use it in
> place of the other.  Also your example of S3 was misleading since it
> used lists which do not have inheritance and did not truly illustrate
> S3.  Free variables in S3 methods follow the same lookup procedure as
> ordinary functions and using S3 together with proto works well.  In
> fact, proto uses two S3 classes.
> 
>>> proto does that but uses the consistent default rather than the
>>> inconsistent default that you prefer.
>> $.proto falls back upon get(), I presume, because the authors didn't
>> feel like recursing up the parent hierarchy themselves; I'll continue
>> to believe that the scope pollution was an oversight until they
>> contradict me. At which point I'll probably switch object systems.
> 
> Here I think you are admitting that the basic facilities of R do work
> in the way proto does.
> 
> Also, your alternative likely would be unusable due to performance
> whereas proto is fast enough to be usable (see list of applications
> that use it at http://r-proto.googlecode.com/#Applications).  Its not
> as fast as S3 (though sometimes you can get it that fast by optimizing
> your code).  The development version of proto is even faster than the
> current version of proto due to the addition of lazy evaluation.
> 
>> Vague appeals to consistency, when you're really only talking about
>> naive get() semantics, don't mean much; especially after you've spent
>> hours debugging mysterious bugs resulting from scope pollution.
> 
> In end it seems that your real beef is with R so perhaps you should be
> using a different language.
> 
> With respect to proto its really just discussing whether to use
> 
> proto(baseenv(), ...) vs proto(...)

I would say the default behaviour makes more sense.  There are very few 
circumstances in R where scoping makes locals and base variables 
visible, *but nothing else*.  I think users would be surprised that

a$ls()

works, but

a$str()

fails (because str() is in utils, ls() is in base).  Effectively what 
the current default says is that objects inherit from the current 
environment.  That's how environments work in R.

One thing that I dislike about scoping in R is the fact that even in a 
namespace, searches eventually get to the global environment.  I'd 
prefer if namespace searches went through the imported namespaces and 
nothing else.  If that were the case, then the a$z example would never 
find a z in the global environment, and that example would only be a 
problem for people fiddling around in the console, not programming 
carefully in a package.  But again, this is a criticism of R, not of 
proto.  (I believe the reason for the current behaviour is to support 
finding S3 methods:  a user should be able to define a new class and an 
S3 method for it, and R should find it even if the writer of the 
original generic knew nothing about the new class or method.  This 
outside-the-namespace search is needed for that, but I'd prefer it if it 
were more limited.)

Duncan Murdoch

> 
> since the former gives you everything you want and the distinction
> seems pretty trivial given how easy it is to use one or the other.  If
> you used iolanguage or similar you would have to specify Object so
> there is not even a penalty in terms of compactness.
> 
> There have also been threads on how to "fix" scoping in R for
> individual functions and various manipulations of environments have
> been suggested but in the end no one does this in practice.  In proto
> at least you can do the part you want and its trivial to do so.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel