> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">The whole concept of lazy evaluation seems to run counter to the idea of real-time systems.</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Hi Thomas,</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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).</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">/jve<br>
</span></font><br><div class="gmail_quote">On Mon, Mar 1, 2010 at 2:37 PM, Thomas Schilling <span dir="ltr"><<a href="mailto:nominolo@googlemail.com">nominolo@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 1 March 2010 16:27, Job Vranish <<a href="mailto:job.vranish@gmail.com">job.vranish@gmail.com</a>> wrote:<br>
> My current area of work is on realtime embedded software programming for<br>
> avionics systems. We do most of our coding in Ada but I've been dreaming of<br>
> using haskell instaed.<br>
<br>
</div>Do you really think this is realistic? Garbage collector aside,<br>
Haskell's execution model is very difficult to predict, which I would<br>
suspect is crucial for even soft real-time systems. The whole concept<br>
of lazy evaluation seems to run counter to the idea of real-time<br>
systems. Lazy evaluation essentially says "do as little as possible<br>
*now*" at the expense of having to do it all later. For a real-time<br>
system you want almost the opposite; you want to make sure that you<br>
complete all the required work in the current time slice.<br>
<br>
A possible workaround would be to sprinkle lots of 'rnf's around your<br>
code to make sure you don't build up a thunk or two that will delay<br>
you later. And if you do this, aren't you essentially programming in<br>
a strict functional language (like SML or O'Caml)? By careful<br>
profiling you and auditing you can probably rule out most of the<br>
potential bad cases, so it can be acceptable for a soft real-time<br>
system (Galois did something like this, I believe). But for avionics<br>
systems you probably want to more assurances than that, don't you?<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Push the envelope. Watch it bend.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>