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&#39;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&#39;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&#39;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">&lt;<a href="mailto:jason.dusek@gmail.com">jason.dusek@gmail.com</a>&gt;</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&#39;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&#39;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&#39;t think GHC was designed<br>
  to be a &quot;Haskell compiler superserver&quot;.<br>
<br>
--<br>
<font color="#888888">Jason Dusek<br>
</font></blockquote></div><br></div>