- Libraries - Haskell.org

Data.Map questions
by Johannes Waldmann 30 Mar '05

30 Mar '05

Data.Map (in ghc-6.4) has instances for Ord and of Show (which FiniteMap didn't have). What does Ord guarantee? I hope it is a total ordering compatible with (==) (so that Maps could be elements of Sets etc.) If so, perhaps there should be a comment in the documentation. From reading the source ghc-6.4/libraries/base/Data/Map.hs it is not clear why Eq uses toAscList but Ord uses toList - so perhaps there is some hidden magic? What if I don't like the Show instance? (That seems to be a fundamental question of library design/usage.) I prefer to have show x return some string that can be pasted back into the source code (!) and gives the correct result. So, for FiniteMap I had sth. like show fm = "listToFM [ (1, True), (2, False) ]" It seems I cannot hide the Show instance from Data.Map (it is always in scope, http://www.haskell.org/onlinereport/modules.html#sect5.4) Perhaps it would be better to have the Show instance in a separate module (that is not automatically imported). Because if I want to use a Map with my preferred Show instance now, I would have to declare my own newtype and instantiate that. - Maybe that's better design anyway (not exposing the concrete implementation). It still fixes one implementation, though. The next step would be to use a type class, but this severely blows up the type signatures. With this respect, "corresponding" Java programs really look better, allowing Map<Foo,Bar> f = new HashMap<Foo,Bar>(); where Map is the interface, and HashMap is one implementation, and the rest of the program only knows that f implements the interface. Yes I know that syntax is only possible because their type classes (interfaces) have exactly one parameter ... Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

SDL bindings.
by Lemmih 29 Mar '05

29 Mar '05

Greetings, I've hacked up a simple binding to SDL and some of the addons. Darcs repo at http://www.scannedinavian.org/~lemmih/SDL/ -- Friendly, Lemmih

1 0

RE: The FunctorM library
by Simon Marlow 29 Mar '05

29 Mar '05

On 20 March 2005 23:30, Thomas Jäger wrote: > Aside from naming issues, there seem to be some problems with the way > FunctorM is currently implemented. > > First of all, `FunctorM` should be a superclass of `Functor' because > there is an obvios implementation of fmap in terms of fmapM >> import Data.FunctorM >> import Control.Monad.Identity >> >> fmap' :: FunctorM f => (a -> b) -> f a -> f b >> fmap' f = runIdentity . fmapM (return . f) > It is already annyoing enough that `Funtor' isn't a subclass of > `Monad' although every monad must also be functor. > > Now, FunctorM should be based on the simplest operations possible, > which in this case is the distributive law and not a monadic version > of fmap (which might be provided for efficiency reasons). > >> class Functor f => FunctorM' f where >> dist' :: Monad m => f (m a) -> m (f a) >> fmapM' :: Monad m => (a -> m b) -> f a -> m (f b) >> >> dist' = fmapM' id >> fmapM' f = dist' . fmap f >> >> -- for example >> instance FunctorM' [] where >> dist' = sequence >> fmapM' = mapM Does anyone else have any comments on the suggestions from Iavor and Thomas in this thread? I'm happy to make changes, but only if there's a concensus. The proposals so far seems to be 1) add dist method 2a) make Functor a superclass of FunctorM 2b) make Functor a *sub*class of FunctorM 2c) make Functor a subclass of Monad 2d) make Functor a superclass of Monad 3) rename FunctorM class to ForEach 4) rename FunctorM module to Control.Monad.FunctorM(?) (1) is easy and not controversial (but is 'dist' the best name?). AFAICT, 2a, 2b, 2c, and 2d have all been suggested (eg. the quoted message above suggests 2a, 2b and 2c). Perhaps some of the suggestions were typos, but at this point I'm a bit confused! Cheers, Simon

12 14

Relax the Either monad
by Yitzchak Gale 28 Mar '05

28 Mar '05

An instance of Monad (Either a) is defined in Control.Monad.Error. Unfortunately, that instance requires the type "a" to be an instance of Error. In fact, using Either for exception handling is only a special case. The Either monad is more generally useful for any complex calculation that needs to exit in the middle and return a value, including multi-level exit. (And no thank you, I would not like to obfuscate my code by using Cont and callCC for that. The Either monad is simple and clean.) It is annoying to work around this problem, since one often has to import Control.Monad.Error. Could this restriction be removed? The Error instance is not used, except to define fail. I don't think it is really important to have a Monad instance where fail references the Error instance; throwError is much more clear. But if others disagree, perhaps a synonym could be used for Either in the context of exceptions. Anyway the namespace there is a bit of a mess; one expects Error to be the non-transforming version of ErrorT, but it is not. How about Throws or Thrown, so I can say: myFun :: a -> b -> c -> Error1 `Thrown` Error2 `Thrown` Error3 `Thrown` ReturnType -Yitz

3 3

RE: The FunctorM library
by Simon Marlow 25 Mar '05

25 Mar '05

On 21 March 2005 10:24, Thomas Hallgren wrote: > Superclasses are never really needed, are they? But they are useful > because they make types smaller and more readable. Well, superclasses might be required by default methods. > For a given type T which has a Monad instance, you can always declare > > instance Functor T where fmap = liftM > > so it is not a big burden to have to declare a Functor instance to > accompany a Monad instance. I don't really have a strong view about this, I'm happy to defer to those who know more about it. But I have a slight preference for not having to define Functor instance if I don't need one - lots of little monads in my code would be affected. Also, Monad dictionaries would get slightly larger. > And the Haskell libraries already contain superclass relationships > that make less sense than the Functor=>Monad relationship. This is true. Here's some good background reading that Google turned up: http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=444 I think this was part of the original Haskell 98 discussion. Cheers, Simon

3 2

RE: The FunctorM library
by Simon Marlow 24 Mar '05

24 Mar '05

On 23 March 2005 15:51, Ross Paterson wrote: > On Wed, Mar 23, 2005 at 09:49:43AM -0000, Simon Marlow wrote: >> Does anyone else have any comments on the suggestions from Iavor and >> Thomas in this thread? I'm happy to make changes, but only if >> there's a concensus. The proposals so far seems to be >> >> 1) add dist method >> 2a) make Functor a superclass of FunctorM >> 2b) make Functor a *sub*class of FunctorM >> 2c) make Functor a subclass of Monad >> 2d) make Functor a superclass of Monad >> 3) rename FunctorM class to ForEach >> 4) rename FunctorM module to Control.Monad.FunctorM(?) >> >> (1) is easy and not controversial (but is 'dist' the best name?). > > fsequence:sequence = fmapM:mapM = fmap:map ? > > As long as we remember that it's not always a distributive law (join > law fails, e.g. for []), and fmapM doesn't always define a functor > (doesn't preserve composition of Kleisli arrows). > > 2a) is needed to provide the default definition > > fmapM f = fsequence . fmap f The options are now boiled down a bit: 1) FunctorM remains as it is, and we add fsequence :: (Monad m, FunctorM f) => f (m a) -> m (f a) (John Meacham's suggestion) 2) class Functor f => FunctorM f where fsequence :: Monad m => f (m a) -> m (f a) fmapM :: Monad m => (a -> m a) -> f a -> m (f a) fsequence = fmapM id fmapM f = fsequence . fmap f the difference is quite small, mainly an efficiency tradeoff, but also if defining fsequence is easier than fmapM you might prefer (2). > The placement in the hierarchy is a bit wierd. Another possibility > (that you suggested earlier) is Data.Functor. Data.Functor would export both Functor and FunctorM? Cheers, Simon

1 0

RE: The FunctorM library
by Simon Marlow 24 Mar '05

24 Mar '05

On 23 March 2005 21:28, Iavor Diatchki wrote: > Hello, > > On Wed, 23 Mar 2005 15:51:04 +0000, Ross Paterson > <ross(a)soi.city.ac.uk> wrote: >> On Wed, Mar 23, 2005 at 09:49:43AM -0000, Simon Marlow wrote: >>> Does anyone else have any comments on the suggestions from Iavor and >>> Thomas in this thread? I'm happy to make changes, but only if >>> there's a concensus. The proposals so far seems to be >>> >>> 1) add dist method >>> 2a) make Functor a superclass of FunctorM >>> 2b) make Functor a *sub*class of FunctorM >>> 2c) make Functor a subclass of Monad >>> 2d) make Functor a superclass of Monad > > Just to avoid confusion I think the suggestions were: > class Functor f => Monad f where ... > class Functor f => FunctorM f where ... > > I know the first one differs from the Haskell report, but perhaps this > is a flaw in the library design that should be fixed. The practical > concern is compatability with existing programs, but if a program > breaks at all it should be very easy to fix --- at most one line per > monad instance, and a Haskell implementation will be able to pinpoint > the missing instances. This means making a pretty big step: we would be deliberately removing support for some valid Haskell 98 programs. That's a bit radical IMHO. We could make Monad.Monad (the Haskell 98 version) a different class from Control.Monad.Monad to keep support for Haskell 98 code. This would break some code too - but maybe that's not such a bad thing, we want people to move away from the Haskell 98 non-hierarchical libraries anyway. In fact, I think (for GHC users at least) we should be advocating writing new code using the option -hide-package haskell98 which removes the Haskell 98 libraries from the namespace. Cheers, Simon

1 0

RE: Help needed with Data.Version
by Simon Marlow 23 Mar '05

23 Mar '05

This is the right behaviour: the parser isn't greedy. You just need to take a parse in which the remainder is empty. See for example Distribution.ParseUtils.runP. Cheers, Simon On 23 March 2005 15:19, Krasimir Angelov wrote: > What I need is to have simple function of type (String -> Version). > How I can do that with the current implementataion? > > > On Wed, 23 Mar 2005 15:16:09 +0000, Ross Paterson > <ross(a)soi.city.ac.uk> wrote: >> On Wed, Mar 23, 2005 at 02:55:47PM +0000, Krasimir Angelov wrote: >>> I have found a bug in Data.Version. The expression: >>> >>> readP_to_S parseVersion "1.0" >>> >>> produces: >>> >>> [(Version {versionBranch = [1], versionTags = []},".0"),(Version >>> {versionBranch= [1,0], versionTags = []},"")] >>> >>> With other words the parser is ambiguous. >> >> It's no more ambiguous than >> >> readP_to_S (many1 (satisfy isDigit)) "1234" >> [("1","234"),("12","34"),("123","4"),("1234","")] >> >> It just needs to be used in context. >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

Help needed with Data.Version
by Krasimir Angelov 23 Mar '05

23 Mar '05

Hi All, I have found a bug in Data.Version. The expression: readP_to_S parseVersion "1.0" produces: [(Version {versionBranch = [1], versionTags = []},".0"),(Version {versionBranch= [1,0], versionTags = []},"")] With other words the parser is ambiguous. Could someone with more experience with ReadP parser combinators fix that? Cheers, Krasimir

2 2

RE: cabal: library archive index and Mac OS X?
by Simon Marlow 22 Mar '05

22 Mar '05

On 21 March 2005 07:55, Isaac Jones wrote: > Wolfgang Thaller <wolfgang.thaller(a)gmx.net> writes: > > (snip) >> The index stores a time stamp; if the .a file's modification date is >> newer, then ld will refuse to load from it until you re-run >> ranlib. This commonly happens when you first build your .a files and >> then touch their modification date while installing. > > Owch. That's some odd behavior; any links to an explanation for why > it works that way? Does this happen on other arches? > > I don't see a cabal-side workaround... maybe GHC should run ranlib > before linking? Is there any drawback to that? Are there any flags > to ln to change this behavior? Can't you run ranlib after install? It wouldn't be right for GHC to run ranlib, because the libraries might not be writable by the current user. Cheers, Simon

3 2