{"id":24,"date":"2008-06-19T22:26:14","date_gmt":"2008-06-20T03:26:14","guid":{"rendered":"http:\/\/www.ikriv.com\/blog\/?p=24"},"modified":"2008-06-19T22:26:14","modified_gmt":"2008-06-20T03:26:14","slug":"f-another-disappointment-lazy-evaluation","status":"publish","type":"post","link":"https:\/\/ikriv.com\/blog\/?p=24","title":{"rendered":"F# – Another Disappointment: Lazy Evaluation"},"content":{"rendered":"

After exploring “lazy<\/code>” keyword in F#, I was up for some disappointments:<\/p>\n

<DISCLAIMER><\/b> Fast forward to the year 2012: people from Microsoft’s “try F#”<\/a> team pointed out that I got some things wrong here, and they probably have a point. So, take whatever follows with a grain of salt. Also, take a look at the comments.<\/DISCLAIMER><\/b><\/font><\/p>\n

* lazy (bla)<\/code> cannot be transparently used in expressions instead of bla<\/code>
\n* Results of lazy evaluation are not cached
\n* Parameters of lazy functions are evaluated eagerly<\/p>\n

Let me explain each of these points.
\n<\/p>\n

Lazy values are not transparent<\/h2>\n

Lazy values such as lazy x<\/code> have a template type Lazy<'a><\/code>, or in C# terms Lazy<T><\/code>. This type does not inherit operations of T<\/code>. If you have two lazy integers, you cannot lazily add them via ‘+’: (lazy 2) + (lazy 3)<\/code> won’t work. To lazily add two lazy integers you will have to write a special function along the lines of:<\/p>\n

let lazy_add x y =\n lazy( Lazy.force(x) + Lazy.force(y) )\n<\/code><\/pre>\n
You must<\/b> explicitly call Lazy.force()<\/code> or similar function to obtain the value of the lazy expression.<\/p>\n
This all makes laziness in F# very explicit. You manually say when things are lazy, you manually say when you want to force the calculation, and you cannot manipulate lazy objects as if they were regular objects.<\/p>\n
Lazy Evaluation Results Are Not Cached<\/h2>\n
In purely functional languages like Haskell, lazy evaluation results are cached my default. If the system already calculated the value of foo(42)<\/code>, it will not calculate it again. This makes sense, since it is assumed that function don’t have side effects.<\/p>\n
F# does not cache lazy evaluated values. This can be demonstrated by the following code:<\/p>\n
#light\nopen System\n\nlet input x =\n lazy\n (\n  printf \"Please enter value for \"\n  print_any x\n  printf \": \"\n  Console.ReadLine()\n )\n\nlet a = (input 42) |> Lazy.force\nlet b = (input 42) |> Lazy.force\n<\/code><\/pre>\n
The code requests the input twice. If the value of input 42<\/code> were cached, it would request the input only once. This is exactly what happens if we cache the value manually:<\/p>\n
\nlet cache = input 42\nlet a = cache |> Lazy.force\nlet b = cache |> Lazy.force\n<\/code><\/pre>\n
Caching the values manually requires writing code, and it may lead to threading issues. Consider this memoization sample from “Expert F#” book<\/a>:<\/p>\n
let fibFast =\n let t = new System.Collections.Generic.Dictionary<int,int>()\n let rec fibCached n =\n  if t.ContainsKey(n) then t.[n]\n  else if n <= 2 then 1\n  else let res = fibCached(n-1) + fibCached(n-2)\n    t.Add(n,res)\n    res\n fun n -> fibCached n\n<\/code><\/pre>\n
This example uses a (local) dictionary, which would require locks if we wanted to parallelize fib_cached<\/code>.<\/p>\n
Parameters of Lazy Functions are Evaluated Eagerly<\/h2>\n
Consider:<\/p>\n
let lazy_add a b =\n lazy (a+b)\n\nlet use_lazy_add x =\n lazy_add func1(x) func2(x)\n<\/code><\/pre>\n
The calls to func1()<\/code> and func2()<\/code> will be evaluated eagerly. Only the addition of the results will be lazy. This is not very bad per se, but it hinders functional decomposition. If I have nested function calls, “laziness” must be applied on the very top level. Consider:<\/p>\n
let f1 x = ...\nlet f2 x = ...\n\n\/\/ use f1 lazily\nlet r1 = f1 42\nlet r2 = f2 18\n\nlet lazy_add x y =\n  lazy( x+y )\n\nlet add_result = lazy_add 10 20\nlet add_result2 = lazy_add r1 r2 \/\/ oops! this won't work\nlet add_result3 = lazy( r1+r2 ) \/\/ that won't work either\nlet add_reslut4 = lazy_add Lazy.force(r1) Lazy.force(r2) \/\/ will eagerly call f1, f2\nlet add_result5 = lazy (Lazy.force(r1) + Lazy.force(r2)) \/\/ this will do what we want\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
After exploring “lazy” keyword in F#, I was up for some disappointments: <DISCLAIMER> Fast forward to the year 2012: people from Microsoft’s “try F#” team pointed out that I got […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[10],"tags":[9],"class_list":["entry","author-ikriv","has-more-link","post-24","post","type-post","status-publish","format-standard","category-fsharp","tag-fsharp"],"_links":{"self":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/24","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=24"}],"version-history":[{"count":0,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/24\/revisions"}],"wp:attachment":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}