R devel - Dec 2013 - Status of reserved keywords and builtins

According to
http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words

  if else repeat while function for in next break
  TRUE FALSE NULL Inf NaN
  NA NA_integer_ NA_real_ NA_complex_ NA_character_
  ... ..1 ..2 etc.

are all reserved keywords.


However, in R 3.0.2 you can do things like:
   `if` <- function(cond, val1, val2) val2
after which
   if(TRUE) 1 else 2
returns 2.

Similarly, users can change the implementation of `<-`, `(`, `{`, `||` and
`&&`.


Two questions:
  - Is this intended behaviour?

  - If so, would it be a good idea to change the language definition
to prevent this?  Doing so would both have the benefits that users
could count on keywords having their normal interpretation, and allow
R implementations to implement these more efficiently, including not
having to lookup the symbol each time.  It'd break any code that
assumes that this is valid, but hopefully there's little or no code
that does.

Thanks

Karl

On 12/12/2013 2:08 PM, Karl Millar wrote:
> According to
http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words
>
>    if else repeat while function for in next break
>    TRUE FALSE NULL Inf NaN
>    NA NA_integer_ NA_real_ NA_complex_ NA_character_
>    ... ..1 ..2 etc.
>
> are all reserved keywords.
>
>
> However, in R 3.0.2 you can do things like:
>     `if` <- function(cond, val1, val2) val2
> after which
>     if(TRUE) 1 else 2
> returns 2.
>
> Similarly, users can change the implementation of `<-`, `(`, `{`, `||`
and `&&`.
>
>
> Two questions:
>    - Is this intended behaviour?
I would say yes.
>
>    - If so, would it be a good idea to change the language definition
> to prevent this?
I would say not.  In the case of "if", what sophisticated users would 
expect to happen from

  if (TRUE) 1 else 2

is that the `if` function will be called with arguments TRUE, 1, 2.
> Doing so would both have the benefits that users
> could count on keywords having their normal interpretation, and allow
> R implementations to implement these more efficiently, including not
> having to lookup the symbol each time.  It'd break any code that
> assumes that this is valid, but hopefully there's little or no code
> that does.
>
It would have those benefits, but it would be harder to prototype 
changes by actually replacing the `if` function.  Implementations that 
want to optimize the calls have other ways to do it, e.g. the sorts of 
things the compiler does.

Duncan Murdoch

>
> It would have those benefits, but it would be harder to prototype
> changes by actually replacing the `if` function.  Implementations that
> want to optimize the calls have other ways to do it, e.g. the sorts of
> things the compiler does.
>
Does anyone actually prototype changes to the `if` function?

Allowing users to replace the definitions of reserved keywords and
builtins is horribly expensive performance-wise with or without
compilation. If you look at the compiler package, the way it optimizes
these function calls is by breaking the language spec. See the
beginnings of sections 5 and 6 of Luke's write up
(http://homepage.stat.uiowa.edu/~luke/R/compiler/compiler.pdf), noting
that the *default* optimization level is 2, at which level, "In
addition to the inlining permitted by Level 1, functions that are
syntactically special or are considered core language functions and
are found via the global environment at compile time may be inlined."

This is an area where a small change to the language spec would impact
essentially no users and would result in a language that could be
executed much more efficiently.

Justin Talbot