[jhc] what to work on next?

[John Meacham]

On Tue, Jun 23, 2009 at 05:29:23PM -0700, Corey O'Connor wrote:
> Outside of the compiler itself: A JHC equivalent to ghc-pkg would be
> nice. That, I'd imagine, would require some Cabal library integration.

The equivalent of ghc-pkg is delightfully simple. 

to list the packages you have installed, do a

ls ~/lib/jhc

to install new ones, simply do a 

cp package.hl ~/lib/jhc

(the ~/lib/jhc is configurable, that is just where I keep my jhc
packages)

Any hl files in jhc's search path are considered available, jhc has no
issues with package conflicts as it uses a hash of the API to uniquely
identify packages, the human readable name is just a convinience.  This
and the portability of jhc libraries  means the equivilant of something
like cabal-install would simply be to list the dependencies and 'wget'
them if they don't exist. 

This would probably be a pretty straightforward project if someone
wanted to work on it, you would just need to add simple hooks to jhc to
dump a list of package dependencies as hashes, and get the hash-name for
a given hl file. The downloader could be a separate program then, called
jhc-pkg. 


> As for the compiler:
> 
> 0. The performance of the jhc compiler is sometimes downright slow.
> Given your description of how JHC works it makes sense why the compile
> times can be long. Looking into optimizing this would be nice.

Indeed. This is a major issue that I have not payed enough attention
too. Back when lhc was a fork of jhc they did some very good profiling
work and found some bottlenecks and I backported their fixes into jhc.

I would love some help here. The makefile should generate a profiled
build of jhc, just do 'make jhcp'. I have no doubt there are a lot of
low hanging fruit that can be found and fixed.

> 1. Additional documentation of the compiler source. This isn't much of
> a problem given the code is quite clear.

Thanks! I tried to make it pretty clear, there are some huge ugly bits,
but hopefully they are sectioned off. distressingly, Main.hs is one of
those ugly files which can turn people off if they don't start looking
in other files. Cleaning up Main would be nice.

> 
> 2. Improved garbage collector? This might just be a documentation
> issue. The documentation states the region-based garbage collector
> leaks memory. And the configure script hints at being able to use a
> standard Boehm garbage collector library. Does the region based
> garbage collector still have issues? When should one be used over the
> other?

yeah, to compile with the boehm collector, simply add the -fboehm
command to the command line when compiling. alternatively you can add a
gc=boehm line to your targets.ini file to choose the collector on a
target by target basis.

This probably is the major issue with jhc right now. static analysis is
fine for short running programs, but no good if your program runs a
while. boehm works, but is pretty slow. This is tied in to #3 below
actually. For some potential back ends (JVM,cmm) garbage collection
becomes a lot easier to implement. So perhaps my time is better spent
working on alternate back ends, on the other hand, the gcc back end is
more 'universal' and works pretty well in practice. Now that jhc emits
loops directly rather than relying on tail calls, GC really is the only
thing that using gcc hurts. 

> 3. Direct code generator instead of relying on the C compiler. In
> addition to opening up some generated code optimization possibilities
> this may tie in with #0 above. Perhaps some compiler performance
> optimizations are only possible with a native code generator?

It probably won't help much with #0, We would still have to perform the
grin translations to get the code into a form we can send out as
assembly and actually calling 'gcc' doesn't take much time relative to
the rest of jhc. 

I definitely want to have multiple 'blessed' back ends in jhc. The main
ones I have been interested in are a c-- back end and at least one 'VM'
style back end. such as the JVM, .NET, or Dalvik. Dalvik actually looks
like it might be the easiest, but targeting JVM might be more useful.


> I would like to get involved in JHC more and see me mostly able to
> contribute to #0 and #1. Specifically I plan on attacking #0 and
> documenting everything I read in the source along the way.


That would be excellent!

If you find yourself writing a lot and want to add a chapter to the
manual, simply add comments like so

{- at ChapterName

markdown formatted text

-}

in the appropriate file then add ChapterName to utils/stitch.prl in the
list depending on where you want it to go. multiple sections with the
same chaptername are merged, you can add a section number after the
chapter name to force an explicit order on the sections during merging.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/