[Rd] proto and baseenv()
murdoch at stats.uwo.ca
Fri Feb 26 13:55:32 CET 2010
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
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.)
> 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
More information about the R-devel