Re: [R] Evaluation of defaults in functions

From: Luke Tierney <>
Date: Fri 29 Sep 2006 - 16:00:44 GMT

On Fri, 29 Sep 2006, hadley wickham wrote:

>> There are not all that many other languages that use lazy evaluation.
>> Those that do are for the most part pure or nearly pure functional
>> languages--Haskell is probably the main example. These go much
>> further in their use of lazy evaluation than R. For analogs of the R
>> expressions
>> x <- f(x)
>> list(f(x))
>> x + f(x)
>> only the last one is guaranteed to result in f being called. This
>> makes many things conceptually cleaner and also automatically supports
>> lazy data structures, which allows one to express things like infinite
>> sequences. Some of the downsides are a more complex (or at least
>> very different) implementation and that I becomes very hard to reason
>> about performance. One of the reasons performance is hard to sort out
>> is that it is (deliberately, because of the declarative nature of
>> these languages) hard to know exactly when an evaluation will occur.
> You can argue similarly that adding state (eg. functions with side
> effects) increases the complexity of reasoning about the result of a
> calculcation.

Of course, hence the popularity of purely functional languages in csome circles. That's not the point. Reasoning about _performance_, even in a purely functional context, is complicated by lazy evaluations. You can read about this in various ML vs Haskell debates if you really want to.

>> Contrary to Hadley's comment R actually provides quite a lot of control
>> since
>> assignments are guaranteed to cause evaluation, e.g. in
>> g <- function(x) {
>> x <- x # forces evaluation
>> ...
>> }
>> the argument is guaranteed to be evaluated. The function force()
>> makes this a little more readable (avoids the need for a comment).
> Perhaps control wasn't the word I was looking for. Most lazy
> languages provide some way to force evaluation.

I actualy doubt that, except possibly as a back door the use of which is generally frowned upon. Again, it's not like there are hundreds of such languages out there, so "most" would mean something like 2 out of 3 (there are more but not that many more).

> Assignments forcing
> evaluation seems to be a disadvantage to me - I can't do anything with
> a promise apart from evaluate it.

You shouldn't be able to do anything with a promise, period (the internal R promise that is). It is an internal implementation trick that should not be accessible at the user level, and now with the removal of delay() is not. Having user level promise objects as in Scheme, for example, is very useful, but those are based on the notion that they are _only_ evaluated on explicit demand. Such objects can easily be implemented with the current R behavior.

Having assignments behave the way they do is most unfurtunate when it comes to reasoning about code (e.g. in code analysis or compilation). Analogs of

     x <- complicated expression
     f (x)


     f(complicated expression)

are equivalent in a language like ML with eager evaluation and they are equivalent in Haskell with pure lazy evaluation but they are not in R. So in R replacing one by the other is not a semantics-preserving transformation.



>> Lazy data structures can be implemented in R on top of the limited
>> lazy evaluation mechanism. I experimented with this for fun a one
>> point. Some code is in This
>> is out of date but not too hard to fix. Insuring memory efficiency is
>> still a bit tricky; some comments are int he notes at this site.
> Thanks, I will take a look at that.
> Regards,
> Hadley

Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:
Iowa City, IA 52242                 WWW:

______________________________________________ mailing list
PLEASE do read the posting guide
and provide commented, minimal, self-contained, reproducible code.
Received on Sat Sep 30 02:09:31 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Fri 29 Sep 2006 - 16:30:24 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.