[Haskell-cafe] Real-time garbage collection for Haskell

John Van Enk vanenkj at gmail.com
Mon Mar 1 15:16:49 EST 2010

> The whole concept of lazy evaluation seems to run counter to the idea of
real-time systems.

Hi Thomas,

Lazy evaluation is okay since it has deterministic characteristics. We can
predict what will happen quite accurately (heck, we can model it in simpler
cases). It might take a while to get people comfortable with the concept,
but it wouldn't be a show stopper (actually, some people would benefit
greatly from lazy evaluation and referential transparency).

The GC throws a wrench in a system which would otherwise make it past
certification with enough effort. If we can write a GC that can be modeled,
we'd have an excellent case for using Haskell in aerospace.


On Mon, Mar 1, 2010 at 2:37 PM, Thomas Schilling <nominolo at googlemail.com>wrote:

> On 1 March 2010 16:27, Job Vranish <job.vranish at gmail.com> wrote:
> > My current area of work is on realtime embedded software programming for
> > avionics systems. We do most of our coding in Ada but I've been dreaming
> of
> > using haskell instaed.
> Do you really think this is realistic?  Garbage collector aside,
> Haskell's execution model is very difficult to predict, which I would
> suspect is crucial for even soft real-time systems.  The whole concept
> of lazy evaluation seems to run counter to the idea of real-time
> systems.  Lazy evaluation essentially says "do as little as possible
> *now*" at the expense of having to do it all later.  For a real-time
> system you want almost the opposite; you want to make sure that you
> complete all the required work in the current time slice.
> A possible workaround would be to sprinkle lots of 'rnf's around your
> code to make sure you don't build up a thunk or two that will delay
> you later.  And if you do this, aren't you essentially programming in
> a strict functional language (like SML or O'Caml)?  By careful
> profiling you and auditing you can probably rule out most of the
> potential bad cases, so it can be acceptable for a soft real-time
> system (Galois did something like this, I believe).  But for avionics
> systems you probably want to more assurances than that, don't you?
> --
> Push the envelope.  Watch it bend.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100301/1361a036/attachment.html

More information about the Haskell-Cafe mailing list