headers
Ross Paterson | 3 Sep 2006 13:26
Picon
Favicon

cvs commit: hugs98/tests/rts enum.output

ross        2006/09/03 04:26:47 PDT

  Removed files:
    tests/rts            enum.output 
  Log:
  remove used file
Permalink | Reply | 0 comments |
headers
Ross Paterson | 5 Sep 2006 12:04
Picon
Favicon

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

ross        2006/09/05 03:04:28 PDT

  Modified files:
    .                    Makefile RPM.mk 
    libraries/tools      convert_libraries 
  Log:
  drop HaXml (no longer builds)

  Revision  Changes    Path
  1.80      +1 -3      hugs98/Makefile
  1.53      +0 -1      hugs98/RPM.mk
  1.44      +1 -1      hugs98/libraries/tools/convert_libraries
Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 5 Sep 2006 12:35
Picon

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

Ross Paterson <ross <at> soi.city.ac.uk> wrote:

>   Modified files:
>     .                    Makefile RPM.mk 
>     libraries/tools      convert_libraries 
>   Log:
>   drop HaXml (no longer builds)

In what way does HaXml fail to build for Hugs?  Is it easily fixable?

Regards,
    Malcolm
Permalink | Reply | 0 comments |
headers
Ross Paterson | 5 Sep 2006 12:58
Picon
Favicon

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

On Tue, Sep 05, 2006 at 11:35:03AM +0100, Malcolm Wallace wrote:
> Ross Paterson <ross <at> soi.city.ac.uk> wrote:
> 
> >   Modified files:
> >     .                    Makefile RPM.mk 
> >     libraries/tools      convert_libraries 
> >   Log:
> >   drop HaXml (no longer builds)
> 
> In what way does HaXml fail to build for Hugs?  Is it easily fixable?

There's the use of the cpp symbol VERSION, fixable by adding

	cc-options: -DVERSION="1.16"

or putting the definition in an include file, and there's the
famous Data.FiniteMap.
Permalink | Reply | 1 comment |
headers
Malcolm Wallace | 5 Sep 2006 13:12
Picon

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

> > >   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
Permalink | Reply | 2 comments |
headers
Ross Paterson | 5 Sep 2006 13:19
Picon
Favicon

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

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.
Permalink | Reply | 2 comments |
headers
Ross Paterson | 5 Sep 2006 14:35
Picon
Favicon

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

On Tue, Sep 05, 2006 at 02:21:31PM +0200, 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:
> > > 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.

It's not that hard.  Cabal itself does it for several packages,
including Data.Map.
Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 5 Sep 2006 15:13
Picon

Re: 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.

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.

As far as I can tell, none of my other software now depends on FiniteMap
either, so I withdraw the threat to resuscitate it.  (Sorry Duncan!)

Regards,
    Malcolm
Permalink | Reply | 0 comments |
headers
Ross Paterson | 5 Sep 2006 15:35
Picon
Favicon

Re: FiniteMap

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
Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 5 Sep 2006 15:59
Picon

Re: FiniteMap

Ross Paterson <ross <at> soi.city.ac.uk> wrote:

> 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

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?

Regards,
    Malcolm
Permalink | Reply | 0 comments |

Gmane