- Libraries - Haskell.org

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

30 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 30 Mar '07

30 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 29 Mar '07

29 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 28 Mar '07

28 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

Usability of System.Posix.Terminal
by David Brown 27 Mar '07

27 Mar '07

I was wondering if there are any applications that make use of System.Posix.Terminal? I'm trying to write some code to communicate over a serial port, and am trying to figure out how these functions are intended to be used. There are a bunch of 'with...' and 'without...' functions, but I'm not sure how to easily combine them to modify some terminal attributes. The best I've come up with is: flip withoutMode IgnoreBreak . flip withoutMode InterruptOnBreak . flip withMode LocalMode . flip withInputSpeed B9600 $ originalMode and so on. Am I missing something here? Thanks, David Brown

3 2

Namespace question
by Olivier Thauvin 27 Mar '07

27 Mar '07

Hi, I do plan to write some haskell module specific to mandriva software or specification, for example a toolbox to parse the tree on mirror using media.cfg, or a tools to create rpm specfile following rpm scheme. Then I do plan to push thoses modules into hackage database, because I think it is the best way to have publicity, code review, bug report, etc... My question is related to namespace to use for such modules ? MDV.modules ? FOO.MDV.modules where FOO is an already existing namespace ? Also this question apply for more generic modules, eg which namespace should use an haskell RPM module ? Is it possible to create a new main namespace ? I think a FAQ is needed about this. Regards.

4 3

RE: [Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
by Simon Peyton-Jones 27 Mar '07

27 Mar '07

| One reason why I think type classes have not (yet) been used to reduce the | amount of API repetition is that Haskell doesn't (directly) support | abstraction over type constraints nor over the number of type parameters | (polykinded types?). Often such 'almost equal' module APIs differ in | exactly these aspects, i.e. one has an additional type parameter, while yet | another one needs slightly different or additional constraints on certain | types. Interesting observation. Can you give a few examples in support of it? | Or maybe we have come to the point where Haskell's lack of a 'real' module | system, like e.g. in SML, actually starts to hurt? Great though ML modules are, it's not clear to me how they help in this case. Can you illustrate how the repetition could be avoided if you had ML modules? Simon

2 1