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 {-@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/