[jhc] almost to 0.8.0 - feedback welcome

[John Meacham]

On Mon, Feb 6, 2012 at 10:42 PM, wren ng thornton <wren at freegeek.org> wrote:
>> I have a fix for the third issue done. will post it soon, in the
>> meantime you can find the call to qualifyInstMethod  in
>> src/FrontEnd/Rename.hs and just replace it and the hsDecls processing
>> for HsInstDecl with
>>
>>  >  hsDecls'<- rename hsDecls
>>
>> to just do a full renaming of the declarations.
> With that change it gets up to:
>
>    [14 of 21] Data.Record.HT.Private
>    tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:13
>        - Error: Ambiguous Name: compare
>    Could refer to:
>        (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare)
>    tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:14
>        - Error: Ambiguous Name: compare
>    Could refer to:
>        (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare)
>    tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:15
>        - Error: Ambiguous Name: compare
>    Could refer to:
>        (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare)
>    Running Command Failed! at utils/build_extlibs.prl line 26, <$fh> line
> 41.
>    make: *** [utility-ht-0.0.5.1.hl] Error 2

Yeah, I discovered that bug too. Not sure what exactly introduced it but i was
messing with the renamer. I temporarily disblede utility-ht until I get a
chance to look at it again.


> Unrelatedly, I'm curious, what is the reason for still using base-1.0? Is
> there any hope of getting a newer base to compile so that we can use Hackage
> effectively? If not, what are the impediments: technical issues, or just
> manpower?

Well, it isn't really base 1.0, it has no relation to the hackage/ghc version
other than the unfortunate shared name and the fact they implement similar
things which can be confusing. There is no correspondence between the version
numbers but it does support many of the interfaces that newer versions of ghcs
base has, so you can generally compile cabal projects by simply deleting their
build-depends and letting jhc loose on it.

probably not with 0.8.0, but with something soon I want to get rid of base and
just have 'haskell2010' and 'haskell98' as provided libraries that strictly
follow the standards then some packages that extend them, such as
'haskell-extras'. I was thinking I would mirror the namespaces of the standard
libraries for extended versions. like mallocPlainForeignPtrBytes would be in
Ext.Foreign.ForeignPtr, in general Ext.foo would be the haskell2010 version of
something with jhc extensions included. 'jhc' and 'jhc-prim' would also exist,
but generally wouldn't be used directly by users.

The good news is that jhc sidesteps most of the issues with package
incompatibility that plauge ghc, no need to make haskell98 incompatible with
later libraries as class aliases and module re-exports make it pretty easy to
support both seamlessly and provide custom views that look more like whatever
version of ghc or nhc or uhc you (or your programs) are used too :)

There is nothing in particular keeping cabal from supporting jhc, in fact, it
is a nicer target in a lot of ways, not requiring registering/hiding packages,
keeping track of interface hashes internally to allow many versions of
libraries to be used side-by-side, etc.. The issue is that cabal's model just
doesn't scale. By using version numbers the work scales non-linearly with the
number of _potential_ incompatibilites, rather than the actual ones. It can
barely handle keeping up with multiple versions of ghc, let alone throwing
another compiler into the mix. So, it is certainly possible to target jhc with
cabal and use the same inscrutible version numbers, I just don't think it is a
very productive use of peoples time. Every time someone has to update their
build-depends or I have to reverse engineer code to figure out that #if
MIN_VERSION_base(foo) is actually testing for the presence of Data.Typeable is
time lost that could have been spent programming. ah well. something better
will come along eventually, I'll just make jhc very easy to target and use and
hope for the best.

        John