[Haskell-cafe] Compilers

[John Meacham]

On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote:
> I spoke with the author of the fork a bit in IRC around the time it happened
> and my understanding is that:
> 1) John sternly objects to using cabal as the build system for JHC

This is a fairly silly reason to fork a project, especially jhc, for a
number of reasons. 

It is important to me that jhc be as widely accessible at possible. The
number of machines './configure && make install' will work on outnumbers
those that cabal install will work on hundreds or thousands to
one. I am pleased to have anyone experiment with jhc in the first place, I
don't want to make things harder for my users. This alone would be
enough of a reason all other things being equal, but other things arn't
equal to boot.

The quality of support I can provide is diminished with cabal. Someone
tries to compile jhc, they get a moderately tricky build error. they
send it to me, I take a look, figure out the workaround and release a
new version that same day. one day turnaround. A bug is found in the way
cabal does something.  I track down the bug, hope it is something
fixable, then further hope when I send a fix it is accepted. Maybe it
takes a week or two. Now, do I release a new version of jhc that
requires a development version of cabal? do I hold off and tell the user
they need a personalized workaround? do I demand that to use jhc you
have to use the latest cabal snapshots? Do I then have to support them
when the latest snapshots break something else of theirs? In any case.
it is not a situation I want to be in. 

Cabal just isn't elegant. let's put it in perspective, cabal has 4 times
as many lines of code as mk (a superset of make)*. That is four times as
many lines of haskell code as C. Given how much more dense and
expressive haskell code is than C, that is a huge amount. Yet cabal
can't handle what even mildly complicated make scripts can do.


Cabal is not flexible. I decide I want to include a nice graph of code
motion in jhc, so I add the following 2 lines to my makefile

> %.pdf: %.dot
>     dot $< -Tpdf -o$@

and done! my build system now understands how to create pdf documents
from graph description files. now, I _could_ add support for this to
cabal, I _could_ wait several months for the new version to propagate to
users. And I _would_ fully expect to have to go through the whole
process again the next time I want to do something slightly unorthodox.


Cabal is just a huge dependency I don't need. Every dependency I add to
a project is a bigger hassle for my users and for me. A fairly
complicated dependency like cabal would have to have fairly compelling
benefits. 


Now, I am saying these things so people don't think I am just being
stubborn. I have valid, compelling, and logical reasons to not want to
use cabal. I think it is the wrong tool for the job and it is that
simple. If you want me to switch to cabal, address its issues, and
then _in addition_ add a killer feature on top to put it ahead of other
systems to make the work involved in switching worth it. I have a goal
with jhc, to write a kick ass haskell compiler. Not to fight a build
system that is not suited to my task and that made some dubious design
decisions. Not to promote an agenda.

And before you respond, think about this. What if the ghc developers
were constantly bombarded with whining from the perl people that ghc
doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What
would your impression of the perl community be? 

What if people kept trying to convince _you_ to rewrite your haskell
project in java _and_ provide support for it because "they never had to
use referential transparency, so it can't be that important to you". 

Sometimes that is what it feels like, which is disapointing from this
community. We all came to haskell because we thought it was the better
choice at some point. The hegemony was pushing java, C++, or worse but
we didn't bite (or at least were still hungry).  Just because something
is popular, it doesn't mean it is good, just because it is written in
haskell, it doesn't mean it is elegant. So don't begrudge me for holding
out for something better. Perhaps franchise will be it, perhaps some
future version of cabal, perhaps nothing will replace make/autoconfs
sweet spot (though I would hope there is still some innovation in this
area the OSS community can explore).   


> I hope John doesn't take the fork as any sort of aggressive or insulting
> action.  He's made a compiler that is sufficiently interesting to have users
> that want to take over.

I am still actively working on jhc for the record. Actual code checkin
tends to be very spurty, but don't think the project is dead. More in a
design phase than anything else. There is no surer way to instigate
another spurt than by submitting some patches or bringing up discussion
of an interesting topic or paper on the jhc mailing list.

        John


* if you include the source of all the libraries mk depends on, cabal
  still has twice as many lines.


-- 
John Meacham - ⑆repetae.net⑆john⑈