There are good blogs/videos on why F# isn't lazy by Don Syme - basically, it doesn't mesh with .Net interop well, and can give surprisingly good perf for certain corner cases, but more "interesting" results for most programs.

There is another question: Why doesn't F# have controllable lazyness?

Now, F# does have Lazy<>, etc., but these are just thunks that are explicilty created and de-referenced, so saying that F# supports lazyness is the same as saying that C# or Java or any other language that supports delgates/fn pointers/lambads, etc., can support lazyness.

It seems to me that F# could simply do some compiler magic that would allow a "lazy" keyword:

let lazy x = Console.WriteLn("hi"); 42 // or just "lazy x = ..."
let y = x+1
let z = y x

this would get compiled to:

let x = lazy ( Console.WriteLn("hi"); 42 )
let y = x + 1
let y_lazy = x.Force() + 1 // a lazy "overload"
let z = y x // pick the right y here - in this case y_lazy

This would allow referential transparency when using lazy - now I can change from eager to lazy at the point of creation, and not modify my code, unless I want to control evaluation, in which case I can use the old form. Automatic inlinining could be done to force specialization of fn's to allow 'T or Lazy<'T> - and because we can't overload let-bound fn's at the moment, we'd need either a dynamic dispatch, or (better) speacial overload logic calling the _lazy version.)

It does mean, of course, that you have to be compiling the code that consumes that lazy value if you want to make sure the .Force() happens at the last possible moment - if you're passing into a library that expects 'T rather than either 'T or Lazy<'T>, then the compiler would be forced to call .Force() at that boundary.

I'm sure I'm missing something here, but this seems like the best of both worlds to me.