Editing Yhc/Erlang/Proof of concept (section)

===Lazy computations===
Erlang is a [http://en.wikipedia.org/wiki/Strict_evaluation strict] language. This means that functions always evaluate their agruments, and values get passed around already computed. In Haskell, due to its [http://en.wikipedia.org/wiki/Lazy_evaluation lazy/non-strict] nature, some values are passed around un-evaluated, and may be evaluated later as needed (or never at all). "Traditional" implementation of Haskell runtime often combine non-strict evaluation with [http://en.wikipedia.org/wiki/Memoization memoization] which serves to avoid redundant evaluation of the same expression several times.

However memoization is not possible when compiling Haskell into (Core) Erlang because of Erlang's [http://en.wikipedia.org/wiki/Single_assignment single assignment] nature. Once created, objects in Erlang are immutable (with few exceptions that are of no value to this experiment). As alternative to memoization, the following approach, based on strictness analysis is used.

[http://hackage.haskell.org/packages/archive/yhccore/0.9/doc/html/Yhc-Core-Strictness.html The Yhc Core Strictness Analyzer] is able to determine whether a function is strict on some (or none) of its arguments. This is done via analysis from the bottom up, with OS/platform primitives (strict on all arguments, which is true for Erlang primitives) being on the bottom. If a function passes its argument to another function which evaluates it, the former function is also strict on that argument. If a function unconditionally evaluates its argument as a case statement scrutinee, it is also strict on that argument, and this strictness propagates to other functions which call it.

After Yhc Core is linked and optimized, strictness analysis is run on it. All Erlang primitives (see [[#Haskell calling Erlang|below]] about possible ways to call Erlang functions from Haskell) are considered strict on all arguments (and they naturally are). If a function is determined to be strict on some of its arguments, for each such argument a code is inserted into the function's body to make sure these arguments will be evaluated as early as possible, and will be passed around evaluated. While this does not replace memoization, it is expected that such approach will at least eliminate some redundant computations.

Another consequence, for functions with side effects involved in sequential computations, the runtime implementation must carefully observe that value already computed is passed to the continuation, rather than an unevaluated thunk, since repeated evaluation of the thunk results in repeated side effect.