Re: [Haskell-cafe] Compilers

On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote:

On Fri, Nov 28, 2008 at 7:30 PM, John Meacham wrote:

...

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.

This always seemed like a rather weak argument, first of all, it's not all that tricky to make autotools builds work on windows. Also, Windows users by far prefer binary distributions anyway. They are downloading the msi's rather than the source code. People who are actively developing a project generally have a more advanced toolchain anyway. Not that an easier windows build isn't useful, but that slightly easier windows build is outweighed by the much more complicated build system dependencies that are paid everywhere.

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.

This is sort of like splitting the baby, I don't think the effort is really that small. A build system is a fairly complicated piece of code, and it is also one of the parts I want more than anything to 'just work' and having to worry about two different systems would not be productive. A dumbed down build that is the intersection of both systems would be barely usable and a drain on development effort. I never was opposed to a cabal 'target' for jhc. I have 'make dist' 'make dist-rpm' and hopefully 'make msi' soon, adding a 'make dist-hackage' alongside is not a bad thing, however, it is if it complicates the standard build or comes to dominate development effort or can't be done without duplication of functionality. Cabal is not entirely conducive to being used in this way at the moment, but this can be improved on. Some of the issues arn't too hard and perhaps are being worked on, like adding a 'hackage release' field, and a separate 'hackage' and 'project' maintainer fields. Others are trickier, like the requirement to conform to hackages version numbering policy that might differ from the native one. workarounds are possible of course. But again, this is work. Even if the code isn't that much, it does place a support burden on me and other jhc developers, so it isn't something I'd do on a whim and without a clean design that does not introduce any cabal dependencies on the standard build or require ongoing support that is more than minimal, in fact, the only time cabal should be invoked is specifically the case of installing via cabal-install.

...

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.

I totally agree.

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.

Yeah, I should say that this wasn't really directed at Lemmih and the other lhc authors. There actually was some discussion between me and him, a fork was mentioned, I did not know it was followed through on though until I saw this thread. To reiterate, Lemmih has made some great contributions to jhc, I fully support diversity in projects, so welcome the new effort. As long as the codebases are still compatible I expect patches to flow both directions. However, the issues I raised with cabal are real ones that concern me. Not just when it relates to jhc, but to the future of the language as a whole. There have been a number of projects I have been involved with where things did get as bad as I implied above. If the only reason for the fork was cabal, then that is disapointing. But I don't think that is entirely the case. John -- John Meacham - ⑆repetae.net⑆john⑈