I really like the idea of the region based mem management (and other GC options) in JHC. It could potentially remove the need for any runtime at all, which is nice. <br><br>Two fundamental differences of Timber is that it is purely strict, and not pure functional. <br>
This makes the implementation and use of IO intensive systems slightly more straightforward IMO. <br><br>Also, when I tested JHC, I couldn&#39;t get it to compile my test case. Note that I am not qualified to speak on the quality of the compiler since my Haskell skills are mediocre at best.<br>
<br>One big advantage of JHC once it matures is that it will be able to leverage the cornucopia of haskell libs in hackage, wheras Timber will have to start pretty much from scratch.<br><br><br><br><div class="gmail_quote">
On Fri, Apr 24, 2009 at 2:19 PM, Bulat Ziganshin <span dir="ltr">&lt;<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Rick,<br>
<br>
Friday, April 24, 2009, 10:12:42 PM, you wrote:<br>
<br>
what you think about JHC? it seems that Timber is close to it<br>
<div><div></div><div class="h5"><br>
&gt; You may wish to look at Timber. It is a Haskell descendant designed for embedded systems.<br>
&gt; Its current default output is C which is then compiled. It is a<br>
&gt; very young language, but given the current list of use cases, I am<br>
&gt; sure that it will never abandon it&#39;s C output model, because most<br>
&gt; people in embedded disciplines seem to prefer it. It does, like<br>
&gt; Haskell, include a runtime, but it is small, and light. Since it is<br>
&gt; targetted towards embedded systems the garbage collector is one that<br>
&gt; can be interacted with to guarantee response times on the microsecond level.<br>
&gt;<br>
&gt; <a href="http://timber-lang.org/" target="_blank">http://timber-lang.org/</a><br>
<br>
&gt; I too write software for time critical applications and multiple<br>
&gt; platforms (such as the iPhone). I surveyed over a dozen compilers in<br>
&gt; multiple languages, and my search ended with Timber. As I mentioned,<br>
&gt; it is very young, it has very little standard library to speak of, but it has strong possibilities.<br>
&gt;<br>
<br>
&gt; On Fri, Apr 24, 2009 at 1:34 PM, Bulat Ziganshin<br>
&gt; &lt;<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>&gt; wrote:<br>
&gt;  Hello Sam,<br>
&gt;<br>
&gt;  Friday, April 24, 2009, 9:09:43 PM, you wrote:<br>
&gt;<br>
&gt;  well, GHC generates .o files. so you may solve some of your questions.<br>
&gt;  if you can absolutely ignore performance, you can use so-called<br>
&gt;  non-registerized compilation what generates ansi-compatible C code<br>
&gt;<br>
&gt;  most Haskell libs are written for ghc, so for other compilers you will<br>
&gt;  need to write almost self-contained code<br>
&gt;<br>
<br>
 &gt;&gt; I need a list of .c and .h files as an end result of the Haskell<br>
 &gt;&gt; compilation stage. I expect these c files will need to include Haskell<br>
 &gt;&gt; runtime C code to operate, and therefore have some dependencies in order<br>
 &gt;&gt; to compile and link.<br>
&gt;<br>
 &gt;&gt; Afaict, GHC as it stands does not allow me to do this, even though it<br>
 &gt;&gt; presumably generates C in the process of compiling binary objects.<br>
&gt;<br>
 &gt;&gt; Actually having C source as an end result is critical as I need control<br>
 &gt;&gt; over exactly how the source is compiled and linked. For example:<br>
 &gt;&gt; - I need to compile to different targets: either a static C lib, exe,<br>
 &gt;&gt; dll or C++ lib.<br>
 &gt;&gt; - I need to support multiple compilers.<br>
 &gt;&gt; - I might want to produce a custom runtime.<br>
&gt;<br>
 &gt;&gt; In short, I&#39;d like to use Haskell as a code-generator.<br>
&gt;<br>
 &gt;&gt; I can&#39;t see that this would be unachievable, particularly given it&#39;s<br>
 &gt;&gt; generating C already. Have I missed something?<br>
&gt;<br>
 &gt;&gt; Cheers,<br>
 &gt;&gt; Sam<br>
&gt;<br>
 &gt;&gt; -----Original Message-----<br>
 &gt;&gt; From: Bulat Ziganshin [mailto:<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>]<br>
 &gt;&gt; Sent: 24 April 2009 17:53<br>
 &gt;&gt; To: Sam Martin<br>
 &gt;&gt; Cc: <a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
 &gt;&gt; Subject: Re: [Haskell-cafe] compilation to C, not via-C<br>
&gt;<br>
 &gt;&gt; Hello Sam,<br>
&gt;<br>
 &gt;&gt; Friday, April 24, 2009, 8:36:50 PM, you wrote:<br>
&gt;<br>
 &gt;&gt;&gt; I work in Games middleware, and am very interested in looking at how<br>
 &gt;&gt;&gt; Haskell could help us. We basically sell C++ libraries. I would like<br>
 &gt;&gt; to<br>
 &gt;&gt;&gt; be able to write some areas of our libraries in Haskell, compile the<br>
 &gt;&gt;&gt; Haskell to C and incorporate that code into a C++ library.<br>
&gt;<br>
 &gt;&gt; well, you can intercept these files. once i wrote simple 4-line<br>
 &gt;&gt; haskell utility (it may be 20 lines of C++ or so) and compiled it down<br>
 &gt;&gt; to C. results was 300 lines or so which it&#39;s impossible to understand<br>
&gt;<br>
 &gt;&gt; so, if you just need haskell-C++ interaction, you may look into using<br>
 &gt;&gt; FFI [1,2]. if you believe that you can compile some<br>
 &gt;&gt; java/ruby/haskellwhatever code down to C++ and incorporate it into<br>
 &gt;&gt; your function - sorry, they all have too different computing model<br>
&gt;<br>
 &gt;&gt; btw, my own program [3] goes this way - i combine fast C++ and complex<br>
 &gt;&gt; Haskell code via FFI/dll to produce fast, feature-rich application<br>
&gt;<br>
&gt;<br>
 &gt;&gt; [1] <a href="http://www.haskell.org/haskellwiki/GHC/Using_the_FFI" target="_blank">http://www.haskell.org/haskellwiki/GHC/Using_the_FFI</a><br>
 &gt;&gt; [2] <a href="http://www.haskell.org/haskellwiki/FFI_cook_book" target="_blank">http://www.haskell.org/haskellwiki/FFI_cook_book</a><br>
 &gt;&gt; [3] <a href="http://freearc.org" target="_blank">http://freearc.org</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;  --<br>
&gt;  Best regards,<br>
&gt;   Bulat                            mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br>
&gt;<br>
&gt;  _______________________________________________<br>
&gt;  Haskell-Cafe mailing list<br>
&gt;  <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;  <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Best regards,<br>
 Bulat                            mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>We can&#39;t solve problems by using the same kind of thinking we used when we created them. <br>    - A. Einstein<br>