[Rd] a generic 'attach'?

[Peter Dalgaard]

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

attach(airquality)
airquality$Month <- factor(airquality$Month)
# oops, that's not going to work. You need:
detach(airquality)
attach(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")

or

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 

    attach(airquality)
    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