On 29 Jan 2012, at 22:25, Ertugrul Söylemez wrote:
> A strict-by-default Haskell comes with the
> implication that you can throw away most of the libraries, including the
> base library. So yes, a strict-by-default Haskell is very well
> possible, but the question is whether you actually want that. I
> wouldn't, because a lot of my code relies on the standard semantics.
At work, we have a strict version of Haskell, and indeed we do not use the
standard libraries, but have built up our own versions of the ones we use.
However, our compiler is smart enough to transform and optimise the source code
*as if* it were non-strict: it is only at runtime that things are evaluated
strictly. This means that, in general, you can rely on the standard semantics
to a surprisingly large extent. For instance,
maybe (error "foo") lines (Just "hello\nworld")
will succeed without calling error, just like in Haskell. Even if the final
argument is supplied only at runtime, not statically, it will still do the
right thing.
However, the downside of being strict at runtime is frequently poorer
performance. Stack overflows are common if you use explicit recursion: it is
better to use higher-order functions (map, fold, until) that are implemented at
a lower level in C (i.e. not directly using explicit recursion themselves).
This is a good thing of course - thinking of data structures in the aggregate,
rather than piecemeal.
However, bulk operations do transform the entire data structure, not merely the
fragments that are needed for the onward computation, so it can often be a net
performance loss. The standard lazy computational paradigm of
generate-and-test is therefore hideously expensive, on occasion.
Regards,
Malcolm
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
