[Rd] Cautionary tale about c (PR#695)

Thomas Lumley thomas@biostat.washington.edu
Fri, 13 Oct 2000 08:32:36 -0700 (PDT)

On 13 Oct 2000, Peter Dalgaard BSA wrote:

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

You can use .Primitive("c")(list, names) in this case, which doesn't rely
on any other functions.

Trying to do something similar for, say, as.character, assumes that
as.character is more likely to be redefined than `get', which I don't


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