[Rd] assign("FALSE", TRUE)

[Martin Maechler]

>>>>> "PD" == Peter Dalgaard <P.Dalgaard at biostat.ku.dk>
>>>>>     on Tue, 18 Nov 2008 15:07:04 +0100 writes:

     PD> Martin Maechler wrote:
     >>>>>>> "PD" == Peter Dalgaard <p.dalgaard at biostat.ku.dk> on
     >>>>>>> Tue, 18 Nov 2008 00:00:40 +0100 writes:

       PD> Martin Maechler wrote:
       >> >> But in spite of all that I agree that I'd have liked
       >> >> `FALSE` <- <whatever> to signal an error about the
       >> >> fact that it is a reserved word.

	 RT> This is clearly not a very important issue, but it might
	 RT> bear some thinking about.

      >> >> Yes.  I'd propose that R-core look into how to make
      >> >> assignment to a reserved word an error.

    PD> I disagree. In a sense, this is the point of having the
    PD> backtick operator: allowing you to work with names that
    PD> would otherwise be syntax errors (notice that such names
    PD> are sometimes created outside your control, e.g. via
    PD> column names in data frames). If you start disallowing
    PD> some of them again, well, that way lies madness!

    >> No, no. I'm not against allowing names that are otherwise
    >> syntax errors.  They were always possible via assign().
    >> I just am convinced we should not allow reserved words.

    PD> Please unconvince yourself then... You are solving a
    PD> problem that isn't there: In R, you can assign to
    PD> `FALSE` and access it as `FALSE`. You can not access it
    PD> as FALSE because that is a keyword and you cannot assign
    PD> to FALSE either.

I now have been "unconvinced",
((so the following is just some clarification ...))

but notably not mainly by the above. I'd consider  the backtick
operator as -- very nice -- syntactic sugar for  
assign() and get().

And, for "normal" identifiers,

    foo   <- 1
    `foo` <- 1
    assign("foo", 1)

and 
    foo
    `foo`
    get("foo")

are each three-fold equivalent.  If a user does not *know* about
keywords/reserved words, (s)he can get a bit confused by 
how e.g. break or `break` e.g. are handled:
Recall that Joe Average User does not know about assign, get,
`..` etc, but does know about  ls()  and typing an object name:
If he does ls(), sees "break"  (which stems from previous
assign("break", 3) or `break` <- 3)
and then types 
  > break
  or 
  > str(break)
into the R console to inspect the variable he has "seen" in
ls(), the result will be a bit confusing to such
a user, and I had wanted that we'd evade that confusion.
The example with FALSE or `FALSE` is different but with similar
potential confusion.

    >> { S / S-plus does not either and gives a nice error
    >> message:
    >> 
    S> assign("FALSE", TRUE)
    >> Problem: The name "FALSE" is reserved -- assignments to
    >> it are not allowed }

    PD> But FALSE is not a keyword in S. In R this would
    PD> correspond to locking down F and T.

Hmm,... maybe.  Brian has already answered to that.

Martin


    PD> There's another issue, namely that some keywords do have
    PD> associated functions; e.g., `if` exists as a variable,
    PD> and walls do come tumbling down if you redefine it (to a
    PD> different function). However, that is a completely
    PD> different thing, more related to redefining "+".
    PD> (Incidentally, how hard would it be to ensure that such
    PD> symbols were always looked up in the base namespace?).


    PD> -- O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
    PD> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014
    PD> Cph. K (*) \(*) -- University of Copenhagen Denmark Ph:
    PD> (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)
    PD> FAX: (+45) 35327907

    PD> ______________________________________________
    PD> R-devel at r-project.org mailing list
    PD> https://stat.ethz.ch/mailman/listinfo/r-devel