[Haskell-cafe] Compilers

[Jason Dagit]

On Fri, Nov 28, 2008 at 7:30 PM, John Meacham <john at repetae.net> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081128/a5c48d70/attachment.htm