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

[Jules Bean]

Malcolm Wallace wrote:
> 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.

That's true but I'm not sure you need to solve that (hard, interesting) 
problem just to get *some* kind of timeliness guarantees.

For example the guarantee that a thread is woken up within 10us of the 
MVar it was sleeping on being filled doesn't require you to solve the 
whole problem. It requires you to be able to bound GC time, or preempt 
the GC, but that's feasible isn't it?

Then there is the possibility of a strict DSL (probably but not 
necessarily a Monad) within haskell which has strong timeliness guarantees.

Jules