...

...

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? Regards, Malcolm

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. Duncan

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

On Tue, Sep 05, 2006 at 02:13:33PM +0100, Malcolm Wallace wrote:

...

...

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.

OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and they are far from critical, so have reverted them to using simpler lookup structures.

Why not do it the other way round: #if __GLASGOW_HASKELL__ >= 604 || __NHC__ >= 118 || defined(__HUGS__) -- Data.Map, if it is available import Prelude hiding (lookup) import Data.Map (Map, lookup, fromList) #else -- otherwise, a very simple and inefficient implementation of a finite map type Map k a = [(k,a)] fromList :: [(k,a)] -> Map k a fromList = id -- Prelude.lookup :: k -> Map k a -> Maybe a #endif

On Tue, Sep 05, 2006 at 02:59:21PM +0100, Malcolm Wallace wrote:

Fair enough. Like I say, these lookup structures are not critical. For many simple XML documents, ordinary lists might actually be faster for lookups, despite their worse asymptotic complexity...

Does this mean you can re-instate HaXml as a package built by default with Hugs?

Done, though only in the kitchen sink version. Since the May 2006 release the minimal version has had only the base, haskell98 and Cabal packages.