Well, my point here is that if we want to see GHC branch into other fields (mine being safety critical), and actually see the code generated by GHC be what's really running (rather than once-removed in the form of an EDSL), some changes will have to be made.<div>
<br></div><div>Being able to experiment with GHC's RTS and possibly being able to write your own (should the project require it) would go a long way to helping me make the case for GHC in safety critical.</div><div><br>
</div><div>Perhaps I'd be better off looking at UHC/LHC/JHC as a starting place.</div><div><br></div><div>/jve<br><br><div class="gmail_quote">On Thu, Feb 11, 2010 at 12:13 PM, Jason Dusek <span dir="ltr"><<a href="mailto:jason.dusek@gmail.com">jason.dusek@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Is JHC not suitable in this case? It won't compile all of<br>
Haskell but it does some to be doing the right things as<br>
regards a pluggable RTS.<br>
<br>
I think it's fair to say at this point that GHC can compile<br>
all the Haskell we want and that new Haskell pieces will come<br>
to GHC before anything else gets them. So going with a totally<br>
new system, front-to-back, is not really desirable when all<br>
you want is a new RTS; however, I don't think GHC was designed<br>
to be a "Haskell compiler superserver".<br>
<br>
--<br>
<font color="#888888">Jason Dusek<br>
</font></blockquote></div><br></div>