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. Jonathan. --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = major = 1 minor = 1.1 year = 2000 month = August day = 15 language = R Search Path: .GlobalEnv, Autoloads, package:base -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
J.C.Rougier@durham.ac.uk wrote:> 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. >One thing we've been talking about a bit is adding some form of name space management. This would insure the the c referred to in rm would be the c in base. luke -- Luke Tierney University of Minnesota Phone: 612-625-7843 School of Statistics Fax: 612-624-8868 313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._