cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries

[Simon Marlow]

Duncan Coutts wrote:
> On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote:
> 
>>On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote:
>>
>>>>>>  HaXml (no longer builds)
>>>>>
>>>>>In what way does HaXml fail to build for Hugs?  Is it easily
>>>>>fixable?
>>>>
>>>>... and there's the famous Data.FiniteMap.
>>>
>>>So does anyone have any objections if I go ahead and commit the
>>>replacement (compatibility) implementation of Data.FiniteMap to the main
>>>repository for packages/base?
>>
>>I'd rather see HaXml updated to use Data.Map, perhaps with a
>>compatibility layer for older GHCs.
> 
> 
> Using a compatibility layer is not that easy at the moment. There is a
> feature which will likely go into some upcoming version of Cabal that
> will make it easier to depend on different packages (eg a
> compat-finitemap) depending on what packages versions we are building
> against. For example you'd put something like the following in
> the .cabal file:
> 
> configuration: package(base >= 2.0)
> build-depends: compat-finitemap
> 
> However since this feature is not available yet it's rather hard to add
> a compatibility layer. Generating the .cabal file is a no-no.

No problem - compat-finitemap can provide Compat.Data.Map with a Data.Map-like 
interface, which it implements either in terms of Data.Map or Data.FiniteMap. 
Then you *unconditionally* depend on compat-finitemap, and use Compat.Data.Map 
everywhere.  Later, when you're ready to drop support for GHC 6.2.x, you drop 
the dependency on compat-finitemap and change every import Compat.Data.Map to 
Data.Map.

Alternatively, compat-finitemap can provide a FiniteMap-like interface.  This 
puts off the inevitable refactoring of the code to use the Data.Map-like 
interface until a later date.

Cheers,
	Simon