John Meacham wrote:
On Wed, Jun 24, 2009 at 10:10:53AM -0400, Isaac Dupree wrote:
Evangelism (the honest sort), so that you have some users.
I am not so good at Evangelism, it makes me feel a little dirty :)
yeah I know, me too :-) i'm explaining my "cooperative" perspective on it I guess :)
In your release announcement I would like to hear - that there are finally enough bugs fixed that JHC is usable. - that it's as easy to use as GHC for normal coding [can you make a Haskell-Platform-with-JHC to install?] getting a lot closer, the fact that containers,applicative,filepath and others compile without a hitch implies to me that it is getting quite usable as far as outstanding bugs go.
and it will naturally be incremental improvement like that. I mean, this is objective progress after all, it's worth listing in release notes (and online docs or wherever)
- Which extensions are implemented.
It supports quite a few extensions, but they don't always exactly line up with GHC.
not responding to this in particular, but, in general; I think a lot of the Haskell community (including me I guess) will be coming from somewhat of a GHC perspective. And most of the available libraries will too (e.g. extensions required by Hackage packages are sometimes excessive). Do treasure your differences, don't just throw them away wantonly, but don't underestimate the value of working together! You've made a wonderful tool that is a compiler, but just think all the horrors of Unicode and threading and Windows and who knows what bugs GHC and its base libraries have been dealing with in the past years! (I mean I've tried things like maintaining unicode code, but I'm only one person and I have a lot of interests! It's usually just better in the end to increase code sharing, therefore bug-reports and patches and all those good things.). so... I think where possible it'd be good to try and share a code-base for libraries, and put effort into improving that. (okay I admit it's frustrating too, since GHC momentum will make it harder to start getting involved hacking. But things are IMHO less bad than the ghc-6.4 days when I entered haskell) Anyway also for the extensions that do line up JHC-GHC, at least you can try and give them the same names/understanding, which it looks like you're doing.
some are CPP, UnboxedTuples, EmptyDataDecls, TypeSynonymInstances, Arbitrary Rank N Types, RULES pragmas
some more interesting ones in various stages of completion are:
fully impredicative type system, [forall a . a] is a valid type for instance.
first class existentials (exists a . a) is a valid type as well.
interesting. GHC has had such a hard time finding a *good* scheme for impredicative type inference, and there have been lots of papers written (so I hear) on the subject. Is JHC's current scheme described somewhere? (including limitations. Which mostly means "which type signatures you need to specify", IIRC).
unboxed values. working with unboxed values is almost as straightforward and elegant as working with boxed values.
a possible pitfall of making them more usable, is it may become less obvious where they're evaluated (since the point of unboxed values, was to make sure not to rely on the optimizer, I think?)
"strict" boxed values. values of kind !. they are boxed, but guarenteed evaluated. They are fully polymorphic unlike unboxed values.
yay! I want this in ghc :-P
...
Now, an issue is that even when jhc implements the same extension as ghc, it may not be exactly the same. as in, jhc's type system is different than ghcs. they both as rank-n types, but since there is no formal description of the ghc type system as it isn't in a language standard, I am sure there are programs ghc accepts and jhc doesn't and vice versa. In practice, these cases are probably rare but until haskell' is formalized they will be an issue.
yeah, that'll happen slowly now and then. Documenting individual extensions is a good thing, even when not part of finishing haskell'. I suspect haskell' won't exist until a non-GHC compiler looks likely to ever support it though!
We can have every package on cabal add explicit support for jhc, but those dependency lists are already getting complicated just to support a couple different versions of ghc. imagine 15 years down the road, with a half dozen new ghc versions, 3 uhc versions, 5 lhc ones and a dozen jhc releases that all need to be taken into account in every cabal file. Not scalable at all. Also, I couldn't bring myself to ask everyone to add explicit jhc support, it is just putting a band-aid on the problem and I don't like to do band-aids.
GHC/cabal folks seem to be moving towards a more portable model. e.g., separate "ghc-base" from "base" (which for GHC would depend on "ghc-base") so that Jhc could export an equivalent base (and maybe there the code divergence would be small enough that "base" itself could just use ifdefs, since most code would be in "jhc-base" or portable packages). More importantly IMHO, they *want* to be interoperable and if you try to cooperate with them, they'll be more than happy to have a non-GHC compiler with which to fix their bad assumptions!
All in all, cabal has a closed-world assumption which isn't true. It assumes all haskell code is on hackage
to some extent yes, the "hackage" centralisation seems like a bad thing, but it's also a great boon! (Any opinions on perl's CPAN and the like?)
and we can enumerate all compilers and language extensions in cabal itself. This makes haskell development more insular, rather than standardizing new versions of the language, people are dissuaded from using alternate versions by the design of the tools.
The overhead isn't that great, and it makes you document each language extension at least a bit, so that other compilers might at least have a *chance* of implementing the same thing...
So, the short answer is, cabal is tricky. But jhc can do something like 'cabal install' but much better and that is mainly what people want out of it.
that's true (but also think how many convenient features cabal is getting). I suspect the path through cabal to be the reasonable long term answer, as you'll then get smart people (e.g. libraries@haskell.org !) asking tough questions about what their tools need to do! -Isaac