[jhc] what to work on next?

[Isaac Dupree]

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 at haskell.org 
!) asking tough questions about what their tools need to do!

-Isaac