> 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.
/jve
On Mon, Mar 1, 2010 at 2:37 PM, Thomas Schilling
<nominolo@googlemail.com> wrote:
On 1 March 2010 16:27, Job Vranish <
job.vranish@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.
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?
--