I don&#39;t know if you follow haskell cafe, but there was a lot of buzz over a new iPhone target. for GHC. It apparently took some hacks of the ghc source to get it into that state. There is a lot of interest in being able to easily target other platforms, if it supported JVM that would be huge. Compiling to C/Native for the arm platform would be pretty great as well. <br>
<br>I&#39;m sorry to hear about the region based GC. It would be neat if it worked. As an idea, it seems like the holy grail of GC. But everyone I&#39;ve talked to says that it seems easy at 1st, but bucketing objects into regions seems to frequently place too much into the global pool. <br>
<br>Timber sports a nice, incremental garbage collector that can be made to guarantee sub millisecond response times. Perhaps one could take some inspiration from it as a replacement for the current GC. <br><br><br><div class="gmail_quote">
On Tue, Jun 23, 2009 at 9:02 PM, John Meacham <span dir="ltr">&lt;<a href="mailto:john@repetae.net">john@repetae.net</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;">
<div class="im">On Tue, Jun 23, 2009 at 05:29:23PM -0700, Corey O&#39;Connor wrote:<br>
&gt; Outside of the compiler itself: A JHC equivalent to ghc-pkg would be<br>
&gt; nice. That, I&#39;d imagine, would require some Cabal library integration.<br>
<br>
</div>The equivalent of ghc-pkg is delightfully simple.<br>
<br>
to list the packages you have installed, do a<br>
<br>
ls ~/lib/jhc<br>
<br>
to install new ones, simply do a<br>
<br>
cp package.hl ~/lib/jhc<br>
<br>
(the ~/lib/jhc is configurable, that is just where I keep my jhc<br>
packages)<br>
<br>
Any hl files in jhc&#39;s search path are considered available, jhc has no<br>
issues with package conflicts as it uses a hash of the API to uniquely<br>
identify packages, the human readable name is just a convinience.  This<br>
and the portability of jhc libraries  means the equivilant of something<br>
like cabal-install would simply be to list the dependencies and &#39;wget&#39;<br>
them if they don&#39;t exist.<br>
<br>
This would probably be a pretty straightforward project if someone<br>
wanted to work on it, you would just need to add simple hooks to jhc to<br>
dump a list of package dependencies as hashes, and get the hash-name for<br>
a given hl file. The downloader could be a separate program then, called<br>
jhc-pkg.<br>
<div class="im"><br>
<br>
&gt; As for the compiler:<br>
&gt;<br>
&gt; 0. The performance of the jhc compiler is sometimes downright slow.<br>
&gt; Given your description of how JHC works it makes sense why the compile<br>
&gt; times can be long. Looking into optimizing this would be nice.<br>
<br>
</div>Indeed. This is a major issue that I have not payed enough attention<br>
too. Back when lhc was a fork of jhc they did some very good profiling<br>
work and found some bottlenecks and I backported their fixes into jhc.<br>
<br>
I would love some help here. The makefile should generate a profiled<br>
build of jhc, just do &#39;make jhcp&#39;. I have no doubt there are a lot of<br>
low hanging fruit that can be found and fixed.<br>
<div class="im"><br>
&gt; 1. Additional documentation of the compiler source. This isn&#39;t much of<br>
&gt; a problem given the code is quite clear.<br>
<br>
</div>Thanks! I tried to make it pretty clear, there are some huge ugly bits,<br>
but hopefully they are sectioned off. distressingly, Main.hs is one of<br>
those ugly files which can turn people off if they don&#39;t start looking<br>
in other files. Cleaning up Main would be nice.<br>
<div class="im"><br>
&gt;<br>
&gt; 2. Improved garbage collector? This might just be a documentation<br>
&gt; issue. The documentation states the region-based garbage collector<br>
&gt; leaks memory. And the configure script hints at being able to use a<br>
&gt; standard Boehm garbage collector library. Does the region based<br>
&gt; garbage collector still have issues? When should one be used over the<br>
&gt; other?<br>
<br>
</div>yeah, to compile with the boehm collector, simply add the -fboehm<br>
command to the command line when compiling. alternatively you can add a<br>
gc=boehm line to your targets.ini file to choose the collector on a<br>
target by target basis.<br>
<br>
This probably is the major issue with jhc right now. static analysis is<br>
fine for short running programs, but no good if your program runs a<br>
while. boehm works, but is pretty slow. This is tied in to #3 below<br>
actually. For some potential back ends (JVM,cmm) garbage collection<br>
becomes a lot easier to implement. So perhaps my time is better spent<br>
working on alternate back ends, on the other hand, the gcc back end is<br>
more &#39;universal&#39; and works pretty well in practice. Now that jhc emits<br>
loops directly rather than relying on tail calls, GC really is the only<br>
thing that using gcc hurts.<br>
<div class="im"><br>
&gt; 3. Direct code generator instead of relying on the C compiler. In<br>
&gt; addition to opening up some generated code optimization possibilities<br>
&gt; this may tie in with #0 above. Perhaps some compiler performance<br>
&gt; optimizations are only possible with a native code generator?<br>
<br>
</div>It probably won&#39;t help much with #0, We would still have to perform the<br>
grin translations to get the code into a form we can send out as<br>
assembly and actually calling &#39;gcc&#39; doesn&#39;t take much time relative to<br>
the rest of jhc.<br>
<br>
I definitely want to have multiple &#39;blessed&#39; back ends in jhc. The main<br>
ones I have been interested in are a c-- back end and at least one &#39;VM&#39;<br>
style back end. such as the JVM, .NET, or Dalvik. Dalvik actually looks<br>
like it might be the easiest, but targeting JVM might be more useful.<br>
<div class="im"><br>
<br>
&gt; I would like to get involved in JHC more and see me mostly able to<br>
&gt; contribute to #0 and #1. Specifically I plan on attacking #0 and<br>
&gt; documenting everything I read in the source along the way.<br>
<br>
<br>
</div>That would be excellent!<br>
<br>
If you find yourself writing a lot and want to add a chapter to the<br>
manual, simply add comments like so<br>
<br>
{-@ChapterName<br>
<br>
markdown formatted text<br>
<br>
-}<br>
<br>
in the appropriate file then add ChapterName to utils/stitch.prl in the<br>
list depending on where you want it to go. multiple sections with the<br>
same chaptername are merged, you can add a section number after the<br>
chapter name to force an explicit order on the sections during merging.<br>
<div><div></div><div class="h5"><br>
        John<br>
<br>
--<br>
John Meacham - ⑆<a href="http://repetae.net" target="_blank">repetae.net</a>⑆john⑈ - <a href="http://notanumber.net/" target="_blank">http://notanumber.net/</a><br>
_______________________________________________<br>
jhc mailing list<br>
<a href="mailto:jhc@haskell.org">jhc@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/jhc" target="_blank">http://www.haskell.org/mailman/listinfo/jhc</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>&quot;The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge.&quot; <br>- Daniel J. Boorstin<br>
<br>