[Rd] a generic 'attach'?

Bill.Venables@csiro.au Bill.Venables at csiro.au
Sun Feb 5 13:23:17 CET 2006

What have I started?  I had nothing anywhere near as radical as that in mind, Peter...

One argument against making 'attach' generic might be that such a move would slow it down a bit, but I can't really see why speed would be much of an issue with 'attach'.

I've noticed that David Brahm's package, g.data, for example really has a method for attach as part of it, (well almost), but he has to calls it g.data.attach.

Another package that has an obvious application for a method for attach is the filehash package of Roger Peng.

And as it happens I have another, but for now I call it 'Attach', which is pretty unsatisfying from an aesthetic point of view.

I think I'll just sew the seed for now.  The thing about generic functions is that if they exist people sometimes find quite innovative uses for them, and if they come at minimal cost, and break no existing code, I suggest we thik about implementing them.

(Notice I have had no need to use a 'compatibility with another system' argument at any stage...)


Another, even more minor issue I've wondered about is giving rm() the return value the object, or list of objects, that are removed.  Thus

newName <- rm(object)

would become essentially a renaming of an object in memory.

For some reason I seem to recall that this was indeed a feature of a very early version of the S language, but dropped out (I think) when S3 was introduced.  Have I got that completely wrong?  (I seem to recall a lot of code had to be scrapped at that stage, including something rather reminiscent of the R with(), but I digress...)


-----Original Message-----
From: pd at pubhealth.ku.dk [mailto:pd at pubhealth.ku.dk] On Behalf Of Peter Dalgaard
Sent: Sunday, 5 February 2006 8:35 PM
To: Venables, Bill (CMIS, Cleveland)
Cc: r-devel at lists.r-project.org
Subject: Re: [Rd] a generic 'attach'?

<Bill.Venables at csiro.au> writes:

> Is there any reason why 'attach' is not generic in R?
> I notice that it is in another system, for example,

I wonder which one? ;-)

> and I can see some
> applications if it were so in R.

I suppose there is no particular reason, except that it was probably
"good enough for now" at some point in time. 

Apropos attach(), and apologies in advance for the lengthy rant that

There are a couple of other annoyances with the attach/detach
mechanism that could do with a review. In particular, detach() is not
behaving according to documentation (return value is really NULL). I
feel that sensible semantics for editing an attached database and
storing it back would be useful. The current semantics tend to get
people in trouble, and some of the stuff you need to explain really
feels quite odd:

airquality$Month <- factor(airquality$Month)
# oops, that's not going to work. You need:

(notice in particular that this tends to keep two copies of the data
in memory at a time).

You can actually modify a database after attaching it (I'm
deliberately not saying "data frame", because it will not be one at
that stage), but it leads to contorsions like

assign("Month", factor(Month), "airquality")


with(pos.to.env(2), Month <- factor(Month))

(or even with(pos.to.env(match("airquality",search())),....))

I've been thinking on and off about these matters. It is a bit tricky
because we'd rather not break codes (and books!) all over the place,
but suppose we 

(a) allowed with() to have its first argument interpreted like the 3rd
    argument in assign()

(b) made detach() do what it claims: return the (possibly modified)
    database. This requires that more metadata are kept around than
    currently. Also, the semantics of 

    assign("foo", function(bar)baz, "airquality") 
    aq <- detach(airquality)

    would need to be sorted out. Presumably "foo" needs to be dropped
    with a warning.

Potentially, one could then also devise mechanisms for load/store
directly to/from the search path.

Alternative ideas include changing the search path itself to be an
actual list of objects (rather than a nesting of environments), but
that leads to the same sort of issues.

   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907

More information about the R-devel mailing list