Cautionary tale about c (PR#695)
J.C.Rougier@durham.ac.uk writes:
This situation arose in a computer practical this morning. A student overwrote "c" with a function. This messes up lots of things, but it is difficult to remove the function "c" from the global environment because it is used as a function in both "rm" and "remove". [The solution was to reassign "c" as a number, and then remove it.] Would it be reasonable in "rm" and "remove" to insist that the "c" function is got from the base? The same might apply to ".Internal" and "as.character", which are also used.
Hmm. This would seem to be doable by having line 2 of rm() as
get("c","package:base")(list, names)
You do have to be circumspect: there are calls to match(),
as.character(), and pos.to.env() in that construction, but neither
uses c().
Currently, get("c", envir=NULL) also works, but (for other reasons)
I'm on the warpath against using NULL for the base environment.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel 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-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._