Re: [Rd] a generic 'attach'?

From: Peter Dalgaard <>
Date: Sun 05 Feb 2006 - 10:35:27 GMT

<> 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 follows:

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: detach(airquality)

(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(, Month <- factor(Month))

(or even with("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
~~~~~~~~~~ - (                  FAX: (+45) 35327907

______________________________________________ mailing list
Received on Sun Feb 05 21:41:37 2006

This archive was generated by hypermail 2.1.8 : Sun 05 Feb 2006 - 20:20:52 GMT