[Rd] Status of reserved keywords and builtins

[Duncan Murdoch]

On 13-12-13 8:36 AM, Justin Talbot wrote:
>>
>> 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?

I don't know of any examples of that, but I can easily imagine someone 
wanting to.  For example, some conditions take a long time to evaluate. 
  Maybe I would want to compute both TRUE and FALSE paths in parallel in 
anticipation of the result, if I have cores to spare.  That's pretty 
tricky to get right because of side effects, so prototyping in R code 
could make a lot of sense.

>
> 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.

That only breaks the language spec if the compiler doesn't detect cases 
where it is an invalid optimization.  It may be that that is currently 
the case (I haven't checked), but it needn't always be.  I would much 
prefer that the compiler code were made smarter about detecting this 
rather than adding exceptions to the language design.

Duncan Murdoch