DData modules

newer
cabal posix build-depends issue

older
RE: haddock library?

Ross Paterson

13 Jan 2005 13 Jan '05

7:38 a.m.

On Thu, Jan 13, 2005 at 02:37:39AM -0800, Simon Marlow wrote:

...

simonmar 2005/01/13 02:37:39 PST

Modified files: libraries/base package.conf.in libraries/base/Data FiniteMap.hs Set.hs Added files: libraries/base/Data IntMap.hs IntSet.hs Map.hs Log: Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan Leijen's DData library, with some modifications by JP Bernardy and others on the libraries@haskell.org list. Minor changes by me to remove the last references to DData, and add a DEPRECATED copy of the old Data.Set interface to the new Data.Set.

Int{Map,Set} use the type Word, but I think it was decided a while ago that this type shouldn't be standard. Should that be reconsidered? Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable. One way out would be to replace that instance in Data.Monoid with one for data Endo a = Endo { runEndo :: a -> a }

Show replies by date

Jan-Willem Maessen

13 Jan 13 Jan

8:31 a.m.

On Jan 13, 2005, at 7:38 AM, Ross Paterson wrote:

...

On Thu, Jan 13, 2005 at 02:37:39AM -0800, Simon Marlow wrote:

...
simonmar 2005/01/13 02:37:39 PST

Modified files: libraries/base package.conf.in libraries/base/Data FiniteMap.hs Set.hs Added files: libraries/base/Data IntMap.hs IntSet.hs Map.hs Log: Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan Leijen's DData library, with some modifications by JP Bernardy and others on the libraries@haskell.org list. Minor changes by me to remove the last references to DData, and add a DEPRECATED copy of the old Data.Set interface to the new Data.Set.

Int{Map,Set} use the type Word, but I think it was decided a while ago that this type shouldn't be standard. Should that be reconsidered?

Please. I've had untold frustration in the past trying to impedence-match different implementations of fixed-width unsigned binary arithmetic.

...

Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable. One way out would be to replace that instance in Data.Monoid with one for

data Endo a = Endo { runEndo :: a -> a }

This is a huge frustration for the library writer: define the instance, and give up portability, or leave it out, and eliminate some obvious functionality? -Jan-Willem Maessen

...

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Malcolm Wallace

9:13 a.m.

Ross Paterson writes:

...

Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable.

In what sense is instance Monoid (a -> a) not Haskell'98? It looks perfectly OK to me. Is it because the two type variable arguments to (->) are the same? Regards, Malcolm

Ross Paterson

9:56 a.m.

On Thu, Jan 13, 2005 at 02:13:08PM +0000, Malcolm Wallace wrote:

...

Ross Paterson writes:

...
Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable.

In what sense is instance Monoid (a -> a) not Haskell'98? It looks perfectly OK to me. Is it because the two type variable arguments to (->) are the same?

Yes -- the Report even makes an example of instance C (a,a). But it seems that nhc98 implements this extension.

Ross Paterson

14 Jan 14 Jan

11:15 a.m.

New subject: instance heads (was Re: DData modules)

On Thu, Jan 13, 2005 at 02:56:31PM +0000, Ross Paterson wrote:

...

On Thu, Jan 13, 2005 at 02:13:08PM +0000, Malcolm Wallace wrote:

...
In what sense is instance Monoid (a -> a) not Haskell'98? It looks perfectly OK to me. Is it because the two type variable arguments to (->) are the same?

Yes -- the Report even makes an example of instance C (a,a). But it seems that nhc98 implements this extension.

Nhc98 doesn't really implement it. Try class C a where twist :: a -> a instance C (a,a) where twist (x,y) = (y,x) main = print (twist ('a',True)) which is incorrectly accepted, causing runtime trouble. Also, the other two examples in that section of the Report cause compile-time crashes: instance C (Int,a) instance C [[a]]

John Meacham

9:47 p.m.

On Thu, Jan 13, 2005 at 02:13:08PM +0000, Malcolm Wallace wrote:

...

...
Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable.

I'd wrap just that instance in a #ifdef _GHC_ or actually better, #ifdef NONLINEAR_INSTANCE_HEADS . I have actually written code (already ghc dependent) which counts on that instance being available. It is quite disasterous to not have 'obvious' instances declared in a common place as then each library author has to include their own version of said instance making the libraries unable to be combined without conflicting instances! to avoid this sort of problem one shouldn't declare instances unless at least one of 1. They are writing a standalone program and not a library 2. They declared the class 3. They declared the type they are making an instance holds. the gist of all this is we should make sure every 'sensible' instance for everything declared in the libraries is made for standard types to avoid encouraging this type of collision. John -- John Meacham - ⑆repetae.net⑆john⑈

7433

Age (days ago)

7435

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Jan-Willem Maessen
John Meacham
Malcolm Wallace
Ross Paterson

DData modules

Ross Paterson

Jan-Willem Maessen

Malcolm Wallace

Ross Paterson

Ross Paterson

John Meacham

tags

participants (4)