[Haskell-cafe] What *not* to use Haskell for

[Malcolm Wallace]

Jules Bean <jules at jellybean.co.uk> wrote:

> GHC's scheduler lacks any hard timeliness guarantees.
> 
> This is probably not a fundamental problem with haskell. It's a
> problem  with the compiler/RTS which we happen to be using.

Actually, I would say it is much worse than that.  It is not merely a
question of implementation.  We do not have _any_ predictable theory of
resource usage (time, memory) for a lazy language.  There is no analysis
(yet) which can look at an arbitrary piece of Haskell code and tell you
how long it will take to execute, or how much heap/stack it will eat.
What is more, it is very hard to do that in a modular way.  The
execution time of lazy code is entirely dependent on its usage/demand
context.  So you can't just apply WCET to single functions, then combine
the results.

It's a question I'd love to be able to solve, but I note that those who
are currently working on predictable execution of functional languages
(e.g. the Hume project) have already ditched laziness in favour of
eager execution.

Regards,
    Malcolm