On Mon, Feb 6, 2012 at 10:42 PM, wren ng thornton
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