- Libraries - Haskell.org

Re: Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
by Benjamin Franksen 01 Apr '07

01 Apr '07

Jean-Philippe Bernardy wrote: > Please look at http://darcs.haskell.org/packages/collections/doc/html/Data-Collections.html > for an effort to make most common operation on bulk types fit in a > single framework. The last time I looked at this (shortly after you started the project) I wasn't sure if I would want to use it. Now it seems like an oasis in a desert to me. I am pretty much impressed, for instance, you managed to unify all the nine existing 'filter' types into a common type class. Cool. The only hair in the (otherwise very tasty) soup is "Portability: MPTC, FD, undecidable instances" which doesn't sound like it is going to replace the Prelude any time soon ;-) Never mind: I definitely consider using this instead of importing all these different Data.XYZ modules directly (and, heaven forbid, having to import them qualified whenever I need two of them in the same module). Do you forsee any particular obstacle to an integration (=providing the appropriate instances) of e.g. CompactStrings? I would even try to do this myself, as an exercise of sorts. How difficult is it in practice to work with 'undecidable instances'? Are there special traps one has to be careful to walk around? > Also, we expect indexed types to solve, or at least alleviate, some > problems you mention in your "rant". > http://haskell.org/haskellwiki/GHC/Indexed_types I have been hoping for that to resolve (some of) our troubles, but have been confused by the all the back and forth among the experts about whether they offer more, or less, or the same, as MPTCs+fundeps+whatever (and that they will probably not go into Haskell'). BTW, any reason I didn't find your collections library in the HackageDB (other than stupidity on my part)? (Just interested, I already found the darcs repo.) Cheers Ben PS: Since I read and post to the Haskell lists via gmane and a news client: Do mail clients usually respect the follow-up header, such as I insert when cross-posting, so as to restrict follow-ups to the intended list?

3 4

[Fwd: updateLookupWithKey confusion]
by Adrian Hey 31 Mar '07

31 Mar '07

Hello Folks, Jean-Philippe suggests I put this question to the libraries list. Any thoughts? -------- Original Message -------- Subject: updateLookupWithKey confusion Date: Mon, 26 Mar 2007 08:18:47 +0100 From: Adrian Hey <ahey(a)iee.org> To: Jean-Philippe Bernardy <jeanphilippe.bernardy(a)gmail.com> Hello Jean-Philippe, There seems to be some confusion over this between Haddock documentation and the two implementations in Data.Map and Data.Map.AVL. Is the 'looked up' value supposed to be the value bound to the corresponding key in the map before or after the update? The behaviour isn't specified in the Haddock of either version. In Data.Map implementation you could get the value present before or after the update (depending on whether or not the association is deleted). Surely that's wrong? In Data.Map.AVL you consistently get the value present before the update occurs, but I would have thought it be more useful to get the value after the update occurs (if any). Anyway, I think the behaviour needs specifiying and whichever implementation(s) is not consistent with that spec needs modifying. I'm working on Data.Map.AVL at the moment so I'll fix it if it's wrong (and make it more efficient too). Also, why don't we have a plain updateLookup? (without key), like we do for other funcions. Regards -- Adrian Hey

2 3

darcs patch: Turn off _SERVER64 and correct type of state field in ...
by Chris Mears 29 Mar '07

29 Mar '07

Fri Mar 30 07:14:05 EST 2007 Chris Mears <chris(a)cmears.id.au> * Turn off _SERVER64 and correct type of state field in Event structs. _SERVER64 should be defined only for compiling X server code, so we shouldn't use it here. Changed the type of the "state" member in the XKeyEvent, XButtonEvent and XMotionEvent structures from Modifier to CUInt. This now matches the type given in the X11 header files.

3 2

darcs patch: Changing Int to CInt and building with -D_XSERVER64 (w...
by thedward＠antejentacular.org 29 Mar '07

29 Mar '07

Wed Mar 28 01:24:53 CDT 2007 thedward(a)antejentacular.org * (Graphics.X11) Updates for (better) 64-bit compatibility Changing Int to CInt and building with -D_XSERVER64 (when appropriate) I went through and weeded out all the Ints I could find, replacing them with CInts, adding fromIntegral calls as necessary. I modified configure.ac and X11.buildinfo.in to support detecting 64-bit systems. (inspired by the test in the xorg build). All these changes seem to make X11 much more useful on 64-bit systems. Most importantly, I've got xmonad up and running beautifully.

6 7

Proposal: Add First and Last wrappers around Maybe to Data.Monoid
by Jeffrey Yasskin 29 Mar '07

29 Mar '07

I've created http://hackage.haskell.org/trac/ghc/ticket/1189 to suggest adding two Monoid instances around Maybe that, instead of accumulating things like most monoids, just pick the first or last piece of data they see. Would a week (March 12) be enough time to discuss this? Thanks, Jeffrey Yasskin

7 12

darcs patch: (X11.Graphics) More Int -> CInt cleanup ; Will break e...
by thedward＠antejentacular.org 29 Mar '07

29 Mar '07

Wed Mar 28 20:05:33 CDT 2007 thedward(a)antejentacular.org * (X11.Graphics) More Int -> CInt cleanup ; Will break existing programs. This patch takes care of the rest of the Int usages. These changes break API compatibility. Existing programs will likely require (minor[1]) changes to compile once these changes are applied. [1]Mostly just switching from Int to CInt or using fromIntegral as appropriate.

2 1

Re: Re: Why the Prelude must die
by Benjamin Franksen 28 Mar '07

28 Mar '07

Nicolas Frisby wrote: > Regarding type variable naming, a few of my more hardware minded > friends I've asked to try Haskell often tease me about the opaque type > variable names in the Prelude--it seems greater consideration of type > variable names in the Prelude might behoove new users. I think that single letter names are very a good idea for most of the things in the Prelude. 'a', 'b' etc. are good for very general things like the basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc). I also like the 'm' for Monads of all kinds, but I would suggest to use 'mt' for monad transformers. For collections I think 'c' is nice and 'k' for keys seems to be sort of standard, but I would like to propose using 'e' as generic name for elements of collections, if there are more element types, then 'e1', e2' etc. There are more complicated cases where a multi-letter name seems apropriate, but there appear to me none of them in the Prelude. Cheers Ben

1 0

Control.Monad.Cont documentation
by Andriy Palamarchuk 28 Mar '07

28 Mar '07

Documentation for the Continuation monad. Right now this module does not have any haddock comments. Per Jeff Newbern's gracious permission included relevant information from his cool tutorial "All About Monads" http://www.nomaware.com/monads/, created a couple of examples. The source of the module and haddock output for it are attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/1169 Here is the generated haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1169/Control-Monad-Co… Deadline for the proposal - 2 weeks. Questions, comments, suggestions? Andriy Palamarchuk ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited

3 2

Re: [Haskell-cafe] Re: Why the Prelude must die
by Arthur van Leeuwen 27 Mar '07

27 Mar '07

On 27-mrt-2007, at 20:17, Nicolas Frisby wrote: > Gut feeling: the quick'n dirty script case occurs far less than the > whole module case. Thus I think the benefit of automatically importing > the Prelude if the module declaration is omitted should not happen: > the Principle of Least Surprise out-weighs the small benefit to a rare > case. In my experience quick'n'dirty scripts tend to end up as full-blown modules later on in their life. This, to me, is a strong indication to make importing the prelude explicit. Furthermore, the arguments against explicit importing seem to be easier teaching and shorter code, as one needs much of the Prelude almost everywhere. However, Java seems to offer a reasonable datapoint in this argument: almost everything in the language needs to be explicitly imported, but for java.lang. Ofcourse, java.lang is quite annoyingly big... so a good example it is not. > Regarding type variable naming, a few of my more hardware minded > friends I've asked to try Haskell often tease me about the opaque type > variable names in the Prelude--it seems greater consideration of type > variable names in the Prelude might behoove new users. Good point. It would also make the Prelude sources (and Haddock docs) *much* easier to understand. Doei, Arthur. -- /\ / | arthurvl(a)cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching

1 0

restructuring the mtl
by Ross Paterson 27 Mar '07

27 Mar '07

I propose that we restructure and split the mtl into two packages: mtl-base: a Haskell-98 package containing the monad transformers and non-overloaded versions of the operations, e.g. module Control.Monad.Trans.State where newtype StateT s m a = StateT { runStateT :: s -> m (a,s) } type State s = StateT s Identity instance (Functor m) => Functor (StateT s m) instance (Monad m) => Monad (StateT s m) instance (MonadPlus m) => MonadPlus (StateT s m) instance (MonadFix m) => MonadFix (StateT s m) get :: (Monad m) => StateT s m s put :: (Monad m) => s -> StateT s m () liftStateT :: Monad m => m a -> StateT s m a mtl (depending on mtl-base): multi-parameter+FD type classes with instances for the transformers in mtl-base, e.g. module Control.Monad.State where import qualified Control.Monad.Trans.Error as Error import qualified Control.Monad.Trans.Reader as Reader import qualified Control.Monad.Trans.State as State import qualified Control.Monad.Trans.Writer as Writer class (Monad m) => MonadState s m | m -> s where get :: m s put :: s -> m () instance (Monad m) => MonadState s (StateT s m) instance (Error e, MonadState s m) => MonadState s (ErrorT e m) instance (MonadState s m) => MonadState s (ReaderT r m) instance (Monoid w, MonadState s m) => MonadState s (WriterT w m) One benefit is that it would be possible to use monad transformers in portable programs, at the cost of a little explicit lifting of operations. Often when I use a stack of monad transformers, I define aliases for the new monad and its operations, so this wouldn't be much extra effort. A second benefit is that one could introduce other packages with other interfaces, e.g. one using associated types. The revised mtl would be almost compatible with the existing one, except 1) The monad transformer and corresponding monad would have the same strictness (this has already been done in the HEAD). 2) It wouldn't be possible to declare instances for the corresponding monad.

7 9