From murdoch.duncan at gmail.com  Thu Dec 12 21:22:45 2013
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 12 Dec 2013 15:22:45 -0500
Subject: [Rd] Status of reserved keywords and builtins
In-Reply-To: <CABz6aZeTjummNsA4cKBBf3MiZQLLvjHtnmAkSQJi+LoQ4ZXY8Q@mail.gmail.com>
References: <CABz6aZeTjummNsA4cKBBf3MiZQLLvjHtnmAkSQJi+LoQ4ZXY8Q@mail.gmail.com>
Message-ID: <52AA1B15.6020509@gmail.com>

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



[Rd] Status of reserved keywords and builtins
Duncan Murdoch