[Rd] assign("FALSE", TRUE)

Prof Brian Ripley ripley at stats.ox.ac.uk
Tue Nov 18 15:33:50 CET 2008


On Tue, 18 Nov 2008, Peter Dalgaard wrote:

> 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.
>
> Please unconvince yourself then... You are solving a problem that isn't
> there: In R, you can assign to `FALSE` and access it as `FALSE`. You can
> not access it as FALSE because that is a keyword and you cannot assign
> to FALSE either.
>
>> { 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
>> }
>
> But FALSE is not a keyword in S. In R this would correspond to locking
> down F and T.

I think both F and FALSE are 'keywords' in S, as that appears to say.

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

You mean they are primitives, so 'variable' for some meaning such as 
'object'?  The obvious idea is for the parser to do the lookup, but then 
the deparser would need to be altered.  Otherwise the evaluator needs to 
special-case them, with a slight performance hit.

>
> --
>   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
>  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)              FAX: (+45) 35327907
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


More information about the R-devel mailing list