R-beta: dataframes again

[Peter Dalgaard BSA]

Jim Lindsey <jlindsey at luc.ac.be> writes:


> fcn2 <- function(){
> 	df <- fcn1()
> 	attach(df)}
> When this function is run and finishes, df has supposedly disappeared
> and indeed is not visible by ls(). However, typing resp shows the
> contents of that column of the disappeared dataframe. Using the
> function, factor, gives the warning that the nonfunction is ignored.
> If I run this function 20 times, I stack up 20 invisible copies of the
> dataframe, obviously not something to be programmed in a library.

It will show up on search() though, all 20 times, and ls(pos=...) will
show the contents. Whether this is sensible is of course debatable, as
are issues such as "modifying dataframe doesn't change the attached
version". One argument in favor of the current behaviour is that
things like attach(data.frame(x=1:5,y=6:10)) works, even though the
attached frame itself only exists for the duration of the expression
evaluation.

> The dataframe is
> attached globally in front of system functions but behind pre-existing
> global user variables.

Yes, this is a bit of a pain. Strange things happen when the global
environment contain variables of the same name as that of a dataframe.
One obvious problem is that attached dataframes are read-only, so even
stranger things would happen if you could attach them before the
global environment. Even if you made them writable, they would only
accept certain kinds of assignments.

>   Obviously the problem is that dataframes are using S-Plus scoping
> rules whereas everything (?) else is using R scoping rules (certain
> people on the list appear to have forgotten that the latter exist but
> they are the principal reason I use R).

Actually, search path traversal and scoping are two different
things. What you suggest is more or less to have the search path as a
local variable, resetting itself upon exit from functions. Using
explicit eval(expression,data) constructions is often the workaround.

>   Now that a couple of important S-Plus packages are running in R, is
> it not time to stop emulating the `features' of this virus (that have
> already mutated again, in v4) and develop a good, stable software
> package that S-plus will be forced to emulate?

Yes, but this is a difficult point. S(-plus) contains a certain amount
of misfeatures that we'd like to get rid of. The whole namespace
issue for one thing. On the other hand there are the portability
considerations. And, as a rule, one should be somewhat careful of
dismissing some aspects of S, just because it "looks weird". Every so
often I've found that more careful study of the possible alternatives
reveals that S has been doing The Right Thing all along...

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._