Joel Reymont wrote:
I think the issue wasn't using functional programming for large image processing, it was using Haskell. OCaml is notoriously fast and strict. Haskell/GHC is... lazy.
Everyone knows that laziness is supposed to be a virtue. In practice, though, I'm one of the people who either can't wrap their heads around it or just find themselves having to fight it from the start.
Perhaps laziness is more "foundational", in that you can write if2 c x y = if c then x else y However: 1) What's the advantage of being able to define if2? 2) Many control constructs, like >>=, foldl', map etc don't require laziness because they already take a function as argument rather than a plain expression. In fact, I can't think of any useful user defined control constructs that actually use laziness in the same way as if2, and the presence of laziness in foldr, foldl etc just seems to be a real pain leading to excessive heap consumption. (Counterexample? ) 3) "Lazy lists as glue" can easily be replaced by force/delay lists + an extension to pattern matching where pattern matching against [a] forces the argument and the syntax [h|t] is used as in Prolog, instead of h:t (This would also free : to be used for "with type" or "with partial type" instead of ::) 4) Other examples of the utility of laziness can turn out to be impractical chimera. For example, the famous repmin replaces the traversal of a tree twice with the dubious "advantage" of traversing it "only once" and the building up of a cluster of expensive thunks instead, and since the thunks effectively encode the structure of the tree, evaluation of them effectively constitutes the second traversal. So nothing's gained except difficulty of understanding the all-too-clever code (very bad software engineering practice imho), more heap consumption, and more time consumption.
Should we all switch to OCaml? I wish I had a criteria to determine when to use Haskell and when to use OCaml.
Everything else about Haskell is so great and well thought out (eg type classes, no side effects, higher rank polymorphism, existentials) it seems a pity to throw all this away just because of one unfortunate feature. An alternative would be to write a converter that reads a file of Haskell source which is to be interpreted strictly and outputs a file of lazy Haskell source with stictness annotations everywhere, with desugaring of [a] into force/delay representation (*). (Also in general, !x could mean "force x" ie x(), and ~x could mean \()->x (in value syntax) or ()->x (in type syntax), and !x could be allowed in patterns also (when the type at that position is ~x)) foo : ~Int -> Int -- also taking the opportunity to replace :: by : foo !x = x desugared to foo :: (() -> Int) -> Int foo cx = case cx () of x -> x The main challenge I think would be in converting bindings in let and where to appropriate case bindings to ensure that as far as possible, redundant bindings for a given path of control flow are not made, and analysis of mutually recursive bindings to ensure that everything is bound before being used. Some issues would need to be resolved about what the user can expect. For example whole program optimization could allow some expressions to be optimized out (eg by splitting a function returning a pair into two functions, one for each element) that would otherwise be non-terminating, whereas with lazy Haskell, there is an easy rule that (effectively) expressions are only evaluated when needed, regardless of optimization. Then an interesting investigation would be to see how easy it is to port lazy Haskell to the new, totally strict, language, and if there are any situations where existing code has used laziness (for algorithmic reasons or just for efficiency) without being aware of it. (*) So that eventually a new compiler could be written to take full advantage of the side-effect-free nature of the language + the strictness which means that values can be accessed without having to go through the "if unevaluated then evaluate, store, and return else return" for each unoptimized access. Because OCaml and SML have side effects, which limit optimizations due to possible aliasing etc, it might be possible to compile such a language to code which is certainly no slower, and possibly *even faster* than OCaml!!! :-) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com