On Sat, Oct 4, 2008 at 10:45 AM, laurent [EMAIL PROTECTED] wrote:
On Sat, 2008-10-04 at 12:00 +0200, [EMAIL PROTECTED] wrote:
Message: 18
Date: Fri, 3 Oct 2008 15:35:18 -0500 (CDT)
From: Luke Tierney [EMAIL PROTECTED]
Subject: Re: [Rd] Attributes of top level environments clobbered (was
Re: [R] possible bug in function 'var' in R 2.7.2?)
To: Gabor Grothendieck [EMAIL PROTECTED]
Cc: r-devel@r-project.org r-devel@r-project.org, Martin Maechler
[EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 3 Oct 2008, Gabor Grothendieck wrote:
On Fri, Oct 3, 2008 at 12:46 PM, Luke Tierney [EMAIL PROTECTED] wrote:
On Fri, 3 Oct 2008, Gabor Grothendieck wrote:
On Fri, Oct 3, 2008 at 11:43 AM, Luke Tierney [EMAIL PROTECTED] wrote:
[...]
I do appreciate the excellent R software; however, there are a few points
like
those addressed on the proto home page which do need to be addressed in R
for it to be fully functional.
There are some interesting poins on that page that are worth looking
into. Over time I suspect all but the current 3. will be addressed,
but 3., which is a variant on the unclass issue, is not likely to be.
You can call this a deficiency in R if you like, and I would agree in
the sense that I think it is inappropriate to allow attributes to be
set but not in a reliable way because they can be inadvertenly
removed. We should have done this differently. THere were/are two
choices:
Make reference values, including environments, special in that they
may not have attributes. This woud have been fairly easy (modulo one
use made in decorating the frames on the search path) and could be
done now to clean things up.
Make R-visible environments in two parts--a wrapper that is passed by
value like standard R objects and could have attributes, and an
internal part that is essentially the current environment object.
This is analogous to the way that character vectors, even of length 1,
consist of an STRSXP wrapper containing CHARSXPs that hold the string.
The STRSXP's are visible at the R level, the CHARSXPs are not. This
would have been messier to implement, and unfortunately would be very
messy to retro-fit at this point, so it isn't likely to happen unless
there is some other compelling reason to do so.
Couldn't the two options be merged into one for a start ?
- Make reference values either attribute-free entities (seems important,
as the poor reliability of assigning attributes to environment is
probably not widely known), or generate warnings upon assignment of
attributes.
Some specifics need to be added to the poor reliability phrase relating to
of attributed environments. The proto package changes the class attribute
of environments (but no other attribute of environments) and proto in turn
underlies large widely used packages which likely exercise it thoroughly yet
through this experience the only places where this was noticeable were
points #1 and #3 of the Avoiding R Bugs section of the proto home page
at http://r-proto.googlecode.com
Neither of these are two points are deal breakers as
- #1 has an easy workaround (just change one line in your DESCRIPTION file) and
if the promised fix is made even this won't be necesary,
- #3 mostly seems mostly harmless in the context of proto as the only attribute
change is from a class of enviornment to c(proto,
environment). Artificial
examples can be constructed where this is a problem but substantial experience
with it suggests that it is not a problem in practice.
(The remaining R problems listed are all related to promises, not environments.)
- Create an R-level class that contains an environment (Environment ?,
envobj ?) and implements an environment-like interface by delegation
(somehow like your option 2. above).
Gabor could certainly create his own class, but having this administered
at the R-core level would have the following potential benefits:
- Anyone with similar needs will think twice before starting to
implement his own solution.
- That one class can be moved to a lower level in the internals
(C-level, with a new given SEXPTYPE) if it proves a working solution,
and as time permits.
Just a thought,
Actually, I see the main benefit of this or other approach as
providing the missing
elements of S3 support to environments thereby potentially streamlining the
implementation of every package that needs it (proto, tcltk, R.oo, ...) or more
perhaps more accurately allowing tcltk and R.oo and other such packages to
become as streamlined as proto already is.
Each of these packages could then use inheritance rather than
containment thereby
leveraging the S3 OO facilities that one really expects R to provide.
It would be important that the new class whose objects contain environments is
sufficiently indistinguishable in terms of its
