December 2007 - Libraries

who are the contributors to the Unix package?
by Galchin Vasili 07 Dec '07

07 Dec '07

Hello, Who started this effort? Who is currently doing work on the Unix package? Kind regards, Vasya

2 1

Re: Bounded and floating types
by Conal Elliott 06 Dec '07

06 Dec '07

Oops -- I'd incorrectly assumed that Haskell guarantees Float & Double to have infinities. Thanks, - Conal On Dec 2, 2007 9:50 AM, Lennart Augustsson <lennart(a)augustsson.net> wrote: > But that only makes sense for floating point types that have -Infinity and > +Infinity. > > On Dec 2, 2007 5:39 PM, Conal Elliott <conal(a)conal.net> wrote: > > > Currently Float & Double do not have standard Bounded instances. Is > > there any reason not to use the following? > > > > instance Bounded Float where { minBound = -1/0; maxBound = 1/0 } > > instance Bounded Double where { minBound = -1/0; maxBound = 1/0 } > > > > If I don't hear objections, I'll submit a ticket and re-send a proposal > > note. > > > > - Conal > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > >

6 9

System.Random: enumRandomR, boundedEnumRandom
by Henning Thielemann 06 Dec '07

06 Dec '07

Did you also already need Random instances of enumerations? Wouldn't it be nice to have some helper functions in System.Random: enumRandomR :: (Enum a, RandomGen g) => (a,a) -> g -> (a,g) enumRandomR (l,r) = mapFst toEnum . randomR (fromEnum l, fromEnum r) boundedEnumRandom :: (Enum a, Bounded a, RandomGen g) => g -> (a,g) boundedEnumRandom = enumRandomR (minBound, maxBound) mapFst :: (a -> c) -> (a,b) -> (c,b) mapFst f ~(x,y) = (f x, y) Example application: instance Random Day where random = boundedEnumRandom randomR = enumRandomR

1 0

Proposal: Bounded instance for IntSet (ticket #1953)
by David Benbennick 05 Dec '07

05 Dec '07

>From http://hackage.haskell.org/trac/ghc/ticket/1953 : I propose to add a Bounded instance to IntSet.hs. IntSet is in Ord, and there are only finitely many instances of IntSet. Therefore there is a min IntSet and a max IntSet. It turns out these bounds are very simple: instance Bounded IntSet where minBound = empty maxBound = singleton maxBound Suggested deadline: December 16, 2007.

9 22

GHC's CPP and Cabal's unlit
by Alistair Bayley 05 Dec '07

05 Dec '07

I'm doing some testing with GHC 6.6.1 and Cabal 1.3, and I'm trying to figure out what happens with CPP and Cabal's unlit. I start with file Test.lhs: > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" and run command: ghc -E -x hs -cpp Test.lhs -o Test2.lhs which gives me Test2.lhs: {-# LINE 1 "Test.lhs" #-} # 1 "Test.lhs" # 1 "<built-in>" # 1 "<command line>" # 1 "Test.lhs" > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" So I'm wondering: where does the {-# LINE #-} comment come from, and also the # 1 lines? AFAICT the # 1 lines are ignored by GHC; I can compile Test2.lhs without errors. Is there anything in GHC's docs about this? More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this: {-# LINE 1 "Test.lhs" #-} > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" which is not a valid .lhs file, because we have a code line next to a comment. I also note in Cabal the haddock command runs CPP before unlit. GHC does it the other way around i.e. run unlit first then CPP, and I'm wondering if Cabal shouldn't do the same thing? Thanks, Alistair

3 8

Maybe Monoid spilt milk
by Conor McBride 05 Dec '07

05 Dec '07

Hi folks I realise I should have been paying more attention last March, and as such have no reason to expect any sympathy, let alone action. I would, however, like to comment on the fact that the Data.Monoid instance for (Maybe x) prioritises monoidal structure from x over monoidal structure from Maybe. This makes it hard to use generic monoidal operations to support choice in the Maybe monad. I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose. I have only myself to blame, and I'm not proposing that the Maybe behaviour is changed. I suppose people are busy enjoying the instance as it now stands, and that it would be damaging to change. What a pity Conor http://www.cs.nott.ac.uk/~ctm This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

5 5

Proposal: add "writer" Monad instance (,) o (Ticket #1951)
by Conal Elliott 04 Dec '07

04 Dec '07

I'd like to have a (,)-style writer instance alongside the (->)-based reader instance for Monad in Control.Monad.Instances. Here's the current reader: instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r and my proposed writer: instance Monoid o => Monad ((,) o) where return = pure (o,a) >>= f = (o `mappend` o', a') where (o',a') = f a where the return definition relies on the Applicative instance of ((,) o). Written out explicitly, return a = (mempty,a) Control.Monad.Instances will also need two new imports: import Data.Monoid (Monoid(..)) import Control.Applicative (pure) Suggested review period: two weeks (ending Dec 16). Comments? - Conal

3 2

Proposal: Max and Min for Monoid (ticket # 1952)
by Conal Elliott 04 Dec '07

04 Dec '07

I'd like to add two instances to Data.Monoid, alongside of All/Any, Sum/Product, and First/Last. Here's a current instance (as a style example): -- | Boolean monoid under conjunction. newtype All = All { getAll :: Bool } deriving (Eq, Ord, Read, Show, Bounded) instance Monoid All where mempty = All True All x `mappend` All y = All (x && y) My proposed addition: -- | Ordered monoid under 'max'. newtype Max a = Max { getMax :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Max a) where mempty = Max minBound Max a `mappend` Max b = Max (a `max` b) -- | Ordered monoid under 'min'. newtype Min a = Min { getMin :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Min a) where mempty = Min minBound Min a `mappend` Min b = Min (a `min` b) I have a niggling uncertainty about the Ord & Bounded instances for Min a? Is there a reason flip the a ordering instead of preserving it? Suggested review period: two weeks (ending December 16). Comments? - Conal

4 6

Re: Proposal: add "writer" Monad instance (,) o (Ticket #1951)
by Conal Elliott 04 Dec '07

04 Dec '07

Hi Chris. I don't think that version could type-check. Try it out. - Conal On Dec 3, 2007 8:52 AM, Chris Kuklewicz <chrisk(a)mightyreason.com> wrote: > In State, the tuple order that is use is > > newtype State s a = State { > > runState :: (s -> (a, s)) > > } > > So I would expect you to use the same order for writer. This only > changes (>>) > below: > > > instance Monoid o => Monad ((,) o) where > > return = (a,mempty) > > (a,o) >>= f = (a',o `mappend` o') where (a',o') = f a > > -- > Chris > >

1 0

Using Ord for keys of maps and sets
by Yitzchak Gale 04 Dec '07

04 Dec '07

Henning Thielemann wrote: > I already told about by scepticism about using Ord for keys of maps and > sets: > http://www.haskell.org/pipermail/libraries/2007-April/007411.html Yes. There are a number of different scenarios for the ordering that you want to use for indexing: 1. A default ordering for the type that is a natural ordering. 2. A default ordering for indexing that is not a natural ordering. 3. An application-specific ordering. 4. More than one ordering for the same type, determined statically. 5. More than one ordering for the same type, determined dynamically, i.e., parameterized orderings. My experience has been that all of these cases do come up quite often in real life. One solution would be to have Data.Map.Indexable, etc. as alternatives using Indexable instead of Ord, so that we could avoid newtype wrapping in case 2. We could allow for case 3 by not providing any default instances for Indexable. Or we could provide default instances in a separate module, Data.Indexable.Instances (or something), that you could choose whether or not to import. Newtype wrapping is still required in case 4, so Indexable doesn't add much here. We have not yet said anything helpful about case 5. -Yitz

2 2