>>>>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
>>>>> on Tue, 18 Nov 2008 15:07:04 +0100 writes:
PD> Martin Maechler wrote:
>>>>>>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> 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 ~~~~~~~~~~ - ([EMAIL PROTECTED])
PD> FAX: (+45) 35327907
PD> ______________________________________________
PD> R-devel@r-project.org mailing list
PD> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
