March 2005 - Libraries

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

RE: [darcs-devel] [darcs #279] [wish] Use readline for line-editing
by Simon Marlow 21 Mar '05

21 Mar '05

To enable signals to be caught by Haskell code during a call to readline, you need to be using the threaded RTS (-threaded). This is because the call to readline will block the entire RTS in the non-threaded version. However, there's a rather large caveat: signal handling in the threaded RTS isn't really up to scratch, so results might be a bit unreliable. It's on my queue to fix this at some point. I do remember testing this with GHCi once. If you compile GHCi with -threaded then you can ^C at the prompt and it works (or did at one stage, anyway). Cheers, Simon On 19 March 2005 12:54, David Roundy wrote: > I'm CCing the libraries list on this, since it looks like it may be a > bug in signal handling with the readline module. Or at least a highly > unexpected interaction of sorts. > > Are we just out of luck, and should we just not use readline? Or is > there some way to interupt execution, and exit cleanly (such that the > cleanup portion of brackets is performed) in response to a sigINT > while readline is running? > > I took a quick look at this, and also couldn't figure out what's going > wrong. I know that signal handlers run in a separate haskell thread, > so it may be that perhaps the signal handler is just waiting until > the ffi function returns before running. :( I'm feeling pessimistic > at the moment, and thinking that perhaps we simply can't use readline > in darcs, since it's hard to imagine that a thrown asynchronous > exception will be able to interrupt a FFI call... > > On Fri, Mar 18, 2005 at 03:15:53PM -0500, Martin Bays via RT wrote: >> * Thursday, 2005-03-17 at 07:39 -0500 - David Roundy via RT >> <bugs(a)darcs.net>: >>> A quick look suggests that maybe you can use setCatchSignals? Alas, >>> the readline module seems almost 100% undocumented... :( >> >> I did try that, to no avail. Which is to be expected, as signals are >> meant to be set to be caught by default. >> >> There is indeed no documentation, but afaict the bits we're dealing >> with >> are just straight wrappers round the library calls. In particular >> >> readline :: String -> IO (Maybe String) >> readline prompt = do >> ptr <- withCString prompt readlineC >> flip maybePeek ptr $ \ptr' -> do >> line <- peekCString ptr' >> free ptr' >> return line >> foreign import ccall "readline" readlineC :: Ptr CChar -> IO (Ptr >> CChar) >> >>> It may be that the problem is that readline blocks asynchronous >>> exceptions, and if that's the case, I'm not sure what we can do, >>> since darcs responds to sigINT by throwing an asynchronous >>> exception, so that we can use block in sensitive code to make sure >>> hitting ctrl-C doesn't corrupt anything. >> >> I don't think that's the problem - it appears that the exceptions >> aren't being thrown until too late. What confuses me is just how >> late that >> is. AFAICT, the signals aren't being handled (in the sense of >> causing a throwDynTo) until some point well after the readline has >> finished. In particular, with the following cheap debugging >> redefinition in SignalHandler.lhs: >> >> ih :: ThreadId -> Signal -> IO () >> ih thid s = >> do installHandler s (Catch $ >> (\sig -> (print $ "throwing") >> >> throwDynTo thid sig) $ >> SignalException s) Nothing >> return () >> >> we get the following behaviour: >> >> What is the version name? ^C >> What is the version name? ao^C^Ceu >> "throwing" >> "throwing" >> "throwing" >> Interrupted! >> >> A signal is thrown for each SIGINT, but not until some point I >> haven't >> been able to determine. I do not understand this, so can't see how >> to fix it! >> >> I'm not sure exactly how this fits into the picture, but >> interestingly >> there are issues even with something as simple as >> >> import System.Console.Readline ( readline ) >> import Maybe ( fromMaybe ) >> main = do s <- readline "test" >> print $ fromMaybe "noda" s >> >> Here two INTs are required to actually exit... why, I can't figure >> out. >> >> I fear I don't know what's going on with any of this, nor how to fix >> it. Hopefully the above will be of some use to someone who does.

1 0

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

21 Mar '05

On 21 March 2005 01:46, Iavor Diatchki wrote: > On Mon, 21 Mar 2005 00:29:38 +0100, Thomas Jäger <thjaeger(a)gmail.com> >> It is already annyoing enough that `Funtor' isn't a subclass of >> `Monad' although every monad must also be functor. > > I think you are right. Does anyone remember why "Functor" is not a > superclass of "Monad"? I think it is because it doesn't need to be. The current situation is slightly more flexible: you don't *have* to provide a Functor instance for every Monad instance. On the other hand, it means you occasionally have to write an additional Functor context in types. You can always get around that by defining class (Functor m, Monad m) => Monad' m where {} Cheers, Simon

3 2

cabal: library archive index and Mac OS X?
by Isaac Jones 21 Mar '05

21 Mar '05

I've gotten a bug report that Mac OS X complains when trying to link against cabal-generated archives, because it lacks an index: > ghc --make Main -o prog > Chasing modules from: Test > Compiling Main ( Test.hs, Test.o ) > Linking ... > ld: archive: /usr/local/lib/uust-1.0/libHSuust-1.0.a has no table of > contents, add one with ranlib(1) (can't load from it) In reading the man page of ranlib (on Linux), it sounds like an optional optimization. It also looks like a "-s" flag to ar will generate the index, so that's easy enough to fix. Can anyone explain to me whether / why Mac OS X needs this index, and whether it'll hurt for any other arches? Should we just pass the -s flag to ar? peace, isaac

4 4

The FunctorM library
by Iavor Diatchki 21 Mar '05

21 Mar '05

Hello, I was just looking at the FunctorM library that was recently added. I have a few comments: * Why is this library under "Data" and the rest of the monadic stuff is under "Control" (Related to this, what does the Reader monad have to do with Control?) * A better name for this might be "forEach". This is what I added to the Prelude of my monad library: -- | Apply a monadic function to each element in a container. -- In theory speak, this is a class that identifies functors which -- distribute over all monads. class ForEach f where forEach :: Monad m => f a -> (a -> m b) -> m (f b) instance ForEach [] where forEach xs f = mapM f xs instance ForEach Maybe where forEach Nothing f = return Nothing forEach (Just x) f = Just # f x forEach_ :: (Monad m, ForEach f) => f a -> (a -> m b) -> m () forEach_ xs f = forEach xs f >> return () -Iavor

2 2