March 2007 - Libraries

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

26 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

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

26 Mar '07

[Probably libraries(a)haskell.org is the right list for this message, so I'm fwding your message below, and will reply there.] | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Benjamin | Franksen | Sent: 23 March 2007 22:56 | To: haskell-cafe(a)haskell.org | Cc: haskell(a)haskell.org | Subject: [Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3] | | [sorry for the somewhat longer rant, you may want to skip to the more | technical questions at the end of the post] | | Twan van Laarhoven wrote: | > I would like to announce version 0.3 of my Data.CompactString library. | > Data.CompactString is a wrapper around Data.ByteString that represents a | > Unicode string. This new version supports different encodings, as can be | > seen from the data type: | > | > [...] | > | > Homepage: http://twan.home.fmf.nl/compact-string/ | > Haddock: http://twan.home.fmf.nl/compact-string/doc/html/ | > Source: darcs get http://twan.home.fmf.nl/repos/compact-string | | After taking a look at the Haddock docs, I was impressed by the amount of | repetition in the APIs. Not ony does Data.CompactString duplicate the whole | Data.ByteString interface (~100 functions, adding some more for encoding | and decoding), the whole interface is again repeated another four times, | once for each supported encoding. | | Now, this is /not/ meant as a criticism of the compact-string package in | particular. To the contrary, duplicating a fat interface for almost | identical functionality is apparently state-of-the-art in Haskell library | design, viz. the celebrated Data.Bytesting, whose API is similarly | repetitive (see Data.List, Data.ByteString.Lazy, etc...), as well as | Map/IntMap/SetIntSet etc. I greatly appreciate the effort that went into | these libraries, and admire the elegance of the implementation as well as | the stunning results wrt. efficiency gains etc.. However I fear that | duplicating interfaces in this way will prove to be problematic in the long | run. | | The problems I (for-)see are for maintenance and usability, both of which | are of course two sides of the same coin. For the library implementer, | maintenance will become more difficult, as ever more of such 'almost equal' | interfaces must be maintained and kept in sync. One could use code | generation or macro expansion to alleviate this, but IMO the necessity to | use extra-language pre-processors points to a weakness in the language; it | be much less complicated and more satisfying to use a language feature that | avoids the repetition instead of generating code to facilitate it. On the | other side of teh coin, usability suffers as one has to lookup the (almost) | same function in more and more different (but 'almost equal') module | interfaces, depending on whether the string in question is Char vs. Byte, | strict vs. lazy, packed vs. unpacked, encoded in X or Y or Z..., especially | since there is no guarantee that the function is /really/ spelled the same | everywhere and also really does what the user expects.(*) | | I am certain that most, if not all, people involved with these new libraries | are well aware of these infelicities. Of course, type classes come to mind | as a possible solution. However, something seems to prevent developers from | using them to capture e.g. a common String or ListLike interface. Whatever | this 'something' is, I think it should be discussed and addressed, before | the number of 'almost equal' APIs becomes unmanageable for users and | maintainers. | | Here are some raw ideas: | | 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. Oleg K. has shown that some if these limitations can be overcome w/o | changing or adding features to the language, however these tricks are not | easy to learn and apply. | | Another problem is the engineering question of how much to put into the | class proper: there is a tension between keeping the class as simple as | possible (few methods, many parametric functions) for maximum usability vs. | making it large (many methods, less parametric functions) for maximum | efficiency via specialized implementations. It is often hard to decide this | question up front, i.e. before enough instances are available. (This has | been stated as a cause for defering the decision for a common interface to | list-like values or strings). Since the type of a function doesn't reveal | whether it is a normal function with a class constraint or a real class | method, I imagine a language feature that (somehow) enables me to | specialize such a function for a particular instance even if it is not a | proper class member. | | 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? Can associated types | come to the rescue? | | Cheers | Ben | -- | (*) I know that strictly speaking a class doesn't guarantee any semantic | conformance either, but at least there is a common place to document the | expected laws that all implementations should obey. With duplicated module | APIs there is no such single place. | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

compare on Double
by Ian Lynagh 24 Mar '07

24 Mar '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1239 Consider: let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n) In GHC and YHC this gives (GT,False,False,False) while in hugs it gives (EQ,False,False,False) Neither of these is very satisfactory, as I would expect x `compare` y === EQ => (x == y) === True x `compare` y === GT => (x > y) === True and it's even less pleasant that the implementations differ for no good reason. The Haskell report isn't very helpful on how comparing exceptional Doubles should behave, as it doesn't even say you need to have NaN etc: http://haskell.org/onlinereport/basic.html#sect6.4 The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (_|_, semantically), a truncated value, or a special value such as infinity, indefinite, etc. I think that the right answer is that n `compare` n above (and more generally such a comparison for any incomparable Doubles or Floats) should raise an error (i.e. be _|_). The changes needed are simple, e.g. for GHC (D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | otherwise = GT becomes (D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | x >## y = GT | otherwise = error "Incomparable values" Deadline: 1 week after discussion ends. Thanks Ian

10 14

Proposal: Add Text.PrettyPrint.HughesPJ.zeroText
by Neil Mitchell 23 Mar '07

23 Mar '07

Hi I propose the addition of zeroText to the HughesPJ pretty printer. Ticket number 1217 has been opened for this issue. [Add zeroText to Text.PrettyPrint.HughesPJ Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**20070313023534] { hunk ./Text/PrettyPrint/HughesPJ.hs 177 - char, text, ptext, + char, text, ptext, zeroText, hunk ./Text/PrettyPrint/HughesPJ.hs 263 +-- | Some text, but without any width. Use for non-printing text +-- such as a HTML or Latex tags +zeroText :: String -> Doc + hunk ./Text/PrettyPrint/HughesPJ.hs 595 +zeroText s = textBeside_ (Str s) 0 Empty } Currently using the pretty printer it is impossible to output pretty HTML - <b>name</b> takes up 7+4 letters in width, instead of the 4 it really takes. With zeroText the "<b>" can be constructed to take up no space. This method is essential, and cannot otherwise be implemented without breaking the abstraction of the library. The Yhc project has cloned HughesPJ with this 5 line change as a result - moving back to the base version is preferable. Please discuss. Deadline is a week after discussion stops. Thanks Neil

5 6

[trac@galois.com: Re: [GHC] #1218: Add sortNub and sortNubBy to Data.List]
by dons＠cse.unsw.edu.au 23 Mar '07

23 Mar '07

I propose we *do not* change the api to add the special case: sortNub = sort . nub = map head . group . sort and instead add a rewrite rule to Data.List to provide this optimisation. {-# RULES "sort/nub" sort . nub = map head . group . sort #-} Along with a QuickCheck property to test it: prop_sortnub xs = sort (nub xs) == map head (group (sort xs)) -- Don ----- Forwarded message from GHC <trac(a)galois.com> ----- Date: Sun, 18 Mar 2007 23:51:50 -0000 From: GHC <trac(a)galois.com> To: glasgow-haskell-bugs(a)haskell.org Subject: Re: [GHC] #1218: Add sortNub and sortNubBy to Data.List #1218: Add sortNub and sortNubBy to Data.List ----------------------------+----------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by dons): How about rather than changing the api, purely for efficiency reasons, we just add a rewrite rule to Data.List for this optimisation? The rule would be: {{{ {-# RULES "sort/nub" sort . nub = map head . group . sort #-} }}} sort . nub will be rewritten to the optimised case, and we won't need to further complicate the API. Quite often now it is possible for the library author to expose only a small, generic API, while providing internal rules for specific optimised cases. This keeps the interface small, while still providing performance. Data.ByteString does this in a number of places, for example: {{{ {-# RULES "FPS specialise filter (== x)" forall x. filter (== x) = filterByte x #-} }}} I'd really not like to see more functions exposed in the list interface, only as optimisations, that could be better provided via RULES. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ----- End forwarded message -----

8 23

Re[2]: Adding System.FilePath
by Bulat Ziganshin 20 Mar '07

20 Mar '07

Hello Artem, Friday, March 16, 2007, 12:09:49 PM, you wrote: > Unlike a lot of other languages (like Java) which grow incrementally, > heaving the whole lot of old baggage in their library API, GHC base is > allowed to evolve its interfaces (and yes, that breaks compatibility). I > think it is a healthy approach, while the Java approach might bloat it > to death (sadly, as i'm a Java user; at least the bytecode seem remains > in good shape). > Sorry if it seem like offtopic, but i think the ability of GHC base to > evolve, instead of just bloating away, is vital. this creates problems for developers and users. for example, program developed 3 years ago, may be easily incompatible with current ghc version instead, i propose to keep evolving things outside of base, which will allow to use any version of any library with any ghc version. if you build something written in times of ghc 6.2 - you use old version of library. if you build something more modern - you use newer version. cabal automatically handles keeping of multiple versions of same library and using proper version for each build. this technology provides us *both* evolving of libraries and compatibility with old versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 13

Data.IntMap.findMax is missing
by Christian Maeder 18 Mar '07

18 Mar '07

recently I've switched from "Data.Map.Map Int" to "Data.IntMap.IntMap", but I was disappointed because I did not find a function that would yield the maximum key faster than in linear time, i.e. O(log n). In fact the whole "Min/Max" section is missing in Data.IntMap (resp. Data.IntSet) compared to Data.Map (resp. Data.Set). (The section "Indexed" is also only in Data.Map.) Would somebody care to fix this? Cheers Christian

2 2