- Libraries - Haskell.org

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 04 Dec '07

04 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 04 Dec '07

04 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 03 Dec '07

03 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 03 Dec '07

03 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 03 Dec '07

03 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

Re: [Haskell-cafe] Possible Improvements
by Johan Tibell 03 Dec '07

03 Dec '07

> I agree that (in this context, beginning learning Haskell) it is a > somewhat minor issue. But I disagree that this is something you should > ignore until it becomes a problem and I do think that it should be part > of learning Haskell. Properly using strictness is an important part of > using Haskell. It makes the difference between code that stack > overflows and code that doesn't, code that takes 100 seconds and code > that takes 10, code that uses 3MB of RAM and code that uses 600. At > least the first of these is not, in my mind, the difference between > "optimized" and "unoptimized", but rather the difference between correct > and incorrect. Writing better code at the beginning is much easier than > trying to figure out what the problem is later. Furthermore, writing > better code is not more difficult. In this case it merely means adding > two characters. Of late, the "rules of thumb" for this sort of thing > are becoming more widely known. Such things need to be "instinctively" > part of how you write code, much like writing code tail-recursively or > not using (++) left associatively. It's not that you should immediately > know that this is better, but (more strongly) that you should not even > think of the worse ways to begin with in many cases. It would be great if someone could exemplify these "rules of thumb", e.g. "Primitive types such as Int should be strict unless in the three canonical examples X, Y and Z." My strictness radar is still quite poor and I feel I can't make informed decisions on when I need to make something more strict or lazy. -- Johan

2 1

more info on building the Unix package on cygwin
by Galchin Vasili 03 Dec '07

03 Dec '07

Hello, I put an ugly kludge(on my laptop) in the unix.cabal file For the includes-dir "attribute" I explicited specified the path to the cygwin include directory. The Unix package build gets farther and then gets errors. At this point, it appears that the cygwin sys/types.h has a "bug" .. id_t is not defined but id_t is referenced by sys/resources.h/(getpriority/setpriority). Please see see http://www.opengroup.org/onlinepubs/000095399/functions/setpriority.html for getpriority function signature. In any case, I want compare the Linux sys/types.h include. To summarize: 1) I am just learning about the .cabal file format from the Cabal .pdf. In any case, it appears that for the case of cygwin that unix.cabal is deficient. 2) It also appears that the cygwin sys/types.h failed to defined id_t which is needed by sys/resources.h which in turn is needed by System/Posix/DynamicLinker/Module.hsc (error at line 57 where HsUnix.h is refd .. and in HsUnix.h at line # 38 sys/resource.h is referenced.) I can provide a stderr "log". Kind regards, Vasya

1 0

Re: [Haskell-cafe] Possible Improvements
by Don Stewart 03 Dec '07

03 Dec '07

catamorphism: > On 12/2/07, Don Stewart <dons(a)galois.com> wrote: > > prstanley: > > > Hi > > > data Tree = Leaf Int | Node Tree Int Tree > > > > > > occurs :: Int -> Tree -> Bool > > > occurs m (Leaf n) = m == n > > > occurs m (Node l n r) = m == n || occurs m l || occurs m r > > > > > > It works but I'd like to know if it can be improved in any way. > > > > You could probably get away with: > > > > data Tree = Leaf !Int | Node Tree !Int Tree > > > > but that's a minor issue. > > > > IMO, there's no reason to even think about putting in the strictness > annotations unless you've identified this datatype as part of a > performance bottleneck in production code. Otherwise, there's no need > to clutter your code and your mind with them :-) Very true ("a minor issue"). However, *rarely* do you want lazines in the atomic types (Int,Char,Word,Integer, et al) A little test: main = do n <- getArgs >>= readIO . head let t = make (n*2) n print (check t) make :: Int -> Int -> Tree make i 0 = Node (Leaf 0) i (Leaf 0) make i d = Node (make (i2-1) d2) i (make i2 d2) where i2 = 2*i d2 = d-1 check :: Tree -> Int check (Leaf _) = 0 check (Node l i r) = i + check l - check r Fully lazy: data Tree = Leaf Int | Node Tree Int Tree $ time ./A 25 49 ./A 25 18.20s user 0.04s system 99% cpu 18.257 total ^^^^^^ 3556K heap use. Strict in the elements, lazy in the spine: data Tree = Leaf !Int | Node Tree !Int Tree $ time ./A 25 49 ./A 25 14.41s user 0.03s system 99% cpu 14.442 total ^^^^^^ 3056K heap use. You'll be hard pressed to do better in C here. Finally, strict in the spine and elements: data Tree = Leaf !Int | Node !Tree !Int !Tree $ time ./A 25 A: out of memory (requested 1048576 bytes) ./A 25 11.46s user 2.60s system 97% cpu 14.379 total 657M heap use ^^^^ Lesson: * Full strictness == teh suckness. * Mixed lazy and strict == flexible and efficient data types. Makes me wonder why Map is strict in the spine, data Map k a = Tip | Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a) Anyone know? Cheers, Don

1 2