On Fri, Nov 28, 2008 at 7:30 PM, 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 command './configure && make install' only works in Windows if the user bother to install some form of unix environment emulation like msys or cygwin. I don't know if windows platform support matters to jhc, but if it does that's one reason to want to provide an alternative to the autotools build option.
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.
Your arguments make it sound as though providing an option for building with cabal is out of the question. Since I'm not invovled with JHC or LHC in any way I don't know how you would answer this question: Would you consider a cabal based build inaddition to the autotools one? Personally, I look at it this way. Both build systems have different advantages that the other cannot provide but they are not mutually exclusive. Also, the effort to keep them both working for the respective groups of users is rather small in practice.
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.
The reason to provide a .cabal file is exactly the one Don wrote about. This is possible both using make as the build system or in a way that is independent of the make based build system.
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?
I don't recall if I've expressed this publicly before or not, but I'm not fond of the language specific reimplementations of make. I think it's silly that every language has 2-3 language specific build systems and package formats. But, it's too late for me to stop Cabal from existing. Hackage is too useful to ignore. Using it increases my productivity. Tools that use the Cabal format save me time and give me cool features for free. I can easily run haddock or module graphs for example. So, in short, if the perl community had a compelling argument based on what GHC is missing out on, then I think it would be fine for them to bring that to the attention of GHC HQ. Now, the next point. I think you're getting carried away here. This fork was created without you being aware of it. That makes me think the author of the fork didn't bombard you with whining. So, I think we need to keep some perspective on that. It's natural that you should have a fair bit of emotional attachment to the JHC -- you'd be weird if you didn't -- but as I've said before, I don't think any of this is an attack on you or JHC. Rather I think it's a fondness for JHC plus a desire to try different things.
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".
When this comes up on the Darcs mailing list we tend to explain why we like Haskell and then encourage them to try a reimplementation in their favorite language if they want to. I think that parallels the situation here. Someone thought he could do better by doing X and Y and instead of expecting you to support that went off and made a fork where he can support that.
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).
Well, I came to Haskell because I had university courses that introduced me to it, then I started using Darcs and realized I wanted to contribute to Darcs so I learned more Haskell. In the process, my old favorite language Common Lisp was replaced by my new favorite Haskell. I tell people that I now prefer Haskell because: a) The static guarantees you can get really are useful b) the language and paradigm fit the way I think c) the community is full of exteremely intelligent people that care about the quality of the code they write d) the community is friendly and growing. I think animonsity towards Java and C++ is silly. Those languages have their merit, their strengths and their place. I don't see how using Cabal for it's strengths today and make for its strengths prevents you from using the next cool thing when it gets here.
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.
That's good to hear. Thanks for your time, and I wish both projects well with lots of collaboration! Jason