January 2006 - Haskell

Re: [Haskell] A collection of related proposals regarding monads
by Cale Gibbard 05 Jan '06

05 Jan '06

On 05/01/06, David Menendez <zednenem(a)psualum.com> wrote: > Cale Gibbard writes: > > > I personally feel that the inclusion of 'fail' in the Monad class is > > an ugly solution to the problem of pattern matching, and gives the > > incorrect impression that monads should have some builtin notion of > > failure. Indeed, it's becoming common to type the result of some > > function in an arbitrary monad in order to indicate the potential for > > failure, which is strictly speaking, not the right thing to do. (In a > > lot of cases, it's going to be no better than complete program > > failure) > > > > We ought to be using MonadZero when we want to express failure, but > > it's gone! > > Yeah, I don't like fail either. In fact, I usually forget to define it, > even for instances of MonadPlus. > > There are typically three ways to indicate error in existing monad > libraries, e.g., > > mzero :: MonadPlus m => m a > fail :: Monad m => String -> m a > throwError :: MonadError e m => e -> m a > > I would say that fail and throwError essentially have the same meaning, > but I distinguish them from mzero. To my mind, 'mzero' means "no > answer", whereas fail and throwError mean "something's wrong". > > For example, my implementation of Nondet doesn't backtrack over errors: > > mzero `mplus` m = m > throwError e `mplus` m = throwError e > > Should a pattern match failure call mzero or throwError? I was > originally going to say throwError, but now I'm not so sure. First, > MonadError is severely non-H98 (fundeps). Second, we would either need > the error type to belong to some class which includes pattern match > failures, or have a dedicated throwPatternMatchFailure method in > MonadError. Finally, you can write sensible code which backtracks on > pattern-match failure, e.g., > > do ... > Just a <- lookup ... > ... > > > Even if this translation of do-syntax isn't accepted, I still think > > that we should have a separate MonadZero. > > I like the idea of a separate MonadZero. Do we know why it was combined > with MonadPlus? Were there efficiency concerns, or did people dislike > having to declare all those separate instances? > > > I'd also like to see the current use of MonadPlus split into MonadElse > > (or MonadOr) and MonadPlus, as described at the bottom of > > http://www.haskell.org/hawiki/MonadPlus > > as it helps to clarify the distinction between backtracking-type > > failure and immediate failure in types. We could even put this > > distinction to good use in many monads which do support backtracking > > anyway: > > > > instance MonadElse [] where > > [] `morelse` ys = ys > > (x:xs) `morelse` ys = (x:xs) > > With backtracking monads, you can use Oleg's msplit operator to get > morelse, soft-cut, and various other operations. > > class MonadPlus m => MonadChoice m where > msplit :: m a -> m (Maybe (a, m a)) > > mif :: MonadSplit m => m a -> (a -> m b) -> m b -> m b > mif p t e = msplit p >>= maybe e (\(x,xs) -> t x `mplus` (xs >>= t)) > > a `orElse` b = mif a return b > > With non-backtracking monads, you can use throwError or just use mplus > and remind people that non-backtracking monads don't backtrack. My main concern is that mplus means fairly different things in different monads -- it would be good to be able to expect instances of MonadPlus to satisfy monoid, left zero, and left distribution laws, and instances of MonadElse to satisfy monoid, left zero and left catch. It's just good to know what kinds of transformations you can do to a piece of code which is meant to be generic. > > > Lastly, it would be nice to have some standard name for the function: > > option :: (MonadPlus m) => [a] -> m a > > option = foldr (mplus . return) mzero > > which seems to come up quite a bit in my experience with nondet > > monads. > > Mine too. Someone else mentioned "choose", which seems nice. Or, > "fromList". > > Incidentally, would GHC optimize "msum (map return xs)" to "foldr (mplus > . return) mzero xs"? > > > P.S. Oh, and don't get me started about the whole Functor subclass > > thing, and the inclusion of join in the Monad class. Of course I want > > those too. :) > > For the recond, my ideal hierarchy would look something like this: > > class Functor f where > map :: (a -> b) -> f a -> f b > > class Functor f => Applicative f where > return :: a -> f a > ap :: f (a -> b) -> f a -> f b > lift2 :: (a -> b -> c) -> f a -> f b -> f c > > ap = lift2 ($) > lift2 f a b = map f a `ap` b > > class Applicative m => Monad m where > join :: m (m a) -> m a > (>>=) :: m a -> (a -> m b) -> m b > > join m = m >>= id > m >>= f = join (map f m) > > class Monad m => MonadZero m where > nothing :: m a > > class MonadZero m => MonadPlus m where > (++) :: m a -> m a -> m a > > class MonadPlus m => MonadChoice m where > msplit :: m a -> m (Maybe (a, m a)) > > I guess you could put "return" in its own class, PointedFunctor, between > Functor and Applicative, but I haven't seen a reason to. Even without > that, it's probably excessive. Well, me too :) Of course, this sort of thing (especially with the inclusion of PointedFunctor and Applicative) brings us back to wanting something along the lines of John Meacham's class alias proposal. I remember there was a lot of commotion about that and people arguing about concrete syntax. Was any kind of consensus reached? Do we like it? How does it fare on this hierarchy? I think we need some provision for simplifying instance declarations in this kind of situation. It seems to be a common scenario that you have some finely graded class hierarchy, and you really want to be able to declare default instances for superclasses based on instances for subclasses in order to not force everyone to type out a large number of class instances. Another idea I've had for this, though I haven't really thought all of the consequences out, (and I'm looking forward to hearing about all the awful interactions with the module system) is to allow for default instances somewhat like default methods, together with potentially a little extra syntax to delegate responsibility for methods in default instances. The start of your hierarchy could look something like: ---- class Functor f where map :: (a -> b) -> f a -> f b class Functor f => PointedFunctor f where return :: a -> f a instance Functor f where require map -- this explicitly allows PointedFunctor instances to define map class PointedFunctor f => Applicative f where ap :: f (a -> b) -> f a -> f b lift2 :: (a -> b -> c) -> f a -> f b -> f c ap = lift2 ($) lift2 f a b = map f a `ap` b instance Functor f where require map instance PointedFunctor f => Functor f where map = ap . return instance PointedFunctor f where require return class Applicative m => Monad m where join :: m (m a) -> m a (>>=) :: m a -> (a -> m b) -> m b join m = m >>= id m >>= f = join (map f m) instance Functor m where require map instance PointedFunctor m where require return map f x = x >>= (return . f) instance PointedFunctor m => Applicative m where ap fs xs = do f <- fs x <- xs return (f x) ---- This is a little verbose, but the intent is to have classes explicitly declare what default instances they allow, and what extra function declarations they'll need in an instance to achieve them. Here I used 'require' for this purpose. To be clear, in order to define an instance of Monad with the above code, along with all its superclasses, we could simply define return and (>>=) as we would in Haskell 98. Since a definition of return is then available, an instance of PointedFunctor would be inferred, with the default instance providing an implementation of map which satisfies the requirement for the default Functor instance for PointedFunctor. We then get a default implementation of Applicative for free due to the instance of PointedFunctor which we've been able to construct. An alternate route here would be to just define return, map, and join. The declaration for map leads to an instance of Functor. The default instance of PointedFunctor requiring return is used, but the default implementation of map there is ignored since the user has already provided an explicit implementation of map. Bind is defined by the default method provided using join and map, then an instance of Applicative is constructed using bind and return. Some things to note: * The goal should always be to take implementations as early as they become available, that is, if the user provides something it's taken first, then each subclass gets a shot at it starting with the bottom-most classes in the partial order and working up. We'll likely run into problems with multiple inheritance, but I think that simply reporting an error of conflicting instance declarations when two incomparable default instances would otherwise be available is good enough. Such situations are rare, and the user will always be able to simply provide their own instance and resolve ambiguities. * Class constraints on classes (like the Applicative constraint on the Monad class above) are used to deny instances only after it's been determined what instances are really available via defaulting. Since the class definition for Monad provides a default instance for Applicative, the user can avoid the trouble of declaring one, provided that an instance for PointedFunctor can be constructed. * What extra methods might be needed, and what defaults are available are specified directly in the classes, rather than simply allowing any instance to come along and mess with the class hierarchy by providing implementations of arbitrary superclass methods. - Cale

2 2

monads, records, verbosity
by S. Alexander Jacobson 05 Jan '06

05 Jan '06

Much of the discussion here recently has been related to debate about complexifying the monad hierarchy. The fact that Haskell record syntax is abysmal and the verbosity of various possible solutions. They appear to interrelate. Would it be possible/reasonable to get rid of data, class, and instance declarations and rely on type inference for everything? Here is my strawman version: * functions definitions imply the data declarations required foo True = Just "abc" foo False = Nothing ==implies==> data A1 = True | False data A2 a = Just a | Nothing * all function definitions are actually instance declarations of an implicit class that implements that function so e.g. foo True = Just "abc" foo False = Nothing ==implies==> class Foo a b where foo::a->b instance Foo A1 A2 where foo True = Just "abc" foo False = Nothing * multiple definitions of the same function imply distinct instance declarations: foo 0 = Nothing foo x = Just (x+1) ==implies ==> class Foo a b where foo::a->b -- same as above definition of Foo instance Foo A1 (A2 A1) where ..... * field labels happen in context mkPot = Pot {profit=0,amounts=[]} updatePot p = p {profit \= (1+),amount \= (1:)} getProfit p = profit p == implies ==> data A3 = Pot Int [Int] class Profit a where profit::a->Int class Amounts a where amounts::a->[Int] instance Profit A3 where profit (Pot a _)=a instance Amounts A3 where amounts (Pot _ a)=a class UpdatePot a where updatePot::a->a instance UpdatePot A3 where updatePot (Pot a b) = Pot (1+a) (1:b) getProfit p = profit p * default instances are as follows foo a b c = b -- the default instance foo (a::Pot) b c = c -- the specialized instance Is this possible/reasonable? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 1

Haskell email
by Simon Peyton-Jones 05 Jan '06

05 Jan '06

John, Haskellers Thanks to Thomas Johnsson and Libor, I've put together a complete archive of the Haskell mailing list, from 11 Sept 1990 (birth, I think) to Oct 2000 (when the Haskell.org mailman archive takes over). It's available here http://research.microsoft.com/%7Esimonpj/haskell/haskell-email-11Sep1990 -27Oct2000.gz (or will be shortly). John: worth pointing to from Haskell.org? Others: it's a single giant text file. It'd be good to import it into mailman, so that there's exactly one place to look, if someone knows how to do that. Simon

1 0

RE: [Haskell] A collection of related proposals regarding monads
by Simon Peyton-Jones 05 Jan '06

05 Jan '06

Simon Marlow pointed me to mail-archive.com. For some reason Google doesn't seem to index this site, and it's not an easy site to navigate around. However, you can find the monadzero thread mostly on this page: http://www.mail-archive.com/haskell@haskell.org/thrd16.html (search for MonadZero) Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org | [mailto:haskell-bounces@haskell.org] On Behalf Of Simon Peyton-Jones | Sent: 05 January 2006 09:06 | To: Cale Gibbard; Haskell Mailing List | Subject: RE: [Haskell] A collection of related proposals | regarding monads | | | | What do people think of the following proposal? Remove fail from the | | Monad class. Reinstate MonadZero as a separate class as in Haskell | | 1.4. | | This was debated extensively during the Haskell 98 process. I'm not | saying that we made the right decision then, but here's a link to (a | part of) the discussion. | | http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=2 | | I'm hoping someone has an archive of the whole mailing list they can | let us have (see my other message) | | Simon | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: [Haskell] A collection of related proposals regarding monads
by Simon Peyton-Jones 05 Jan '06

05 Jan '06

| What do people think of the following proposal? Remove fail from the | Monad class. Reinstate MonadZero as a separate class as in Haskell | 1.4. This was debated extensively during the Haskell 98 process. I'm not saying that we made the right decision then, but here's a link to (a part of) the discussion. http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=2 I'm hoping someone has an archive of the whole mailing list they can let us have (see my other message) Simon

1 0

Haskell mailing list archive
by Simon Peyton-Jones 05 Jan '06

05 Jan '06

Dear Haskellers Does anyone have a complete archive of Haskell mailing list messages between May 1998 and October 2000 On the latter date we moved to mailman, hosted at haskell.org, so there are archives at haskell.org. I have a complete archive up to May 1998, courtesy of Thomas Johnsson. (I guess I should put it on haskell.org somewhere.) But there's a gap where there seems to be nothing. One reason for asking is that in 1998 there was a long debate about Monad/MonadZero, which is a current topic on the the Haskell list. We'd be better informed if we had the old threads to look at. Simon

1 0

Using MonadError within other Monads
by tpledger＠ihug.co.nz 05 Jan '06

05 Jan '06

(In reply to http://www.haskell.org/pipermail/haskell/2005-December/017109.html ) One of the key things about those nested monads is that *often* you don't have to write things like return $ throwError msg but can simply write throwError msg because the nest has all the features of its components. The IO monad doesn't participate fully in this, but the liftIO function (from the MonadIO class) serves as an adapter. > import Control.Monad.Error > f () = do n <- liftIO readLn > when (n == 2) (throwError "2-char string") > sequence (replicate n (liftIO getChar)) > `catchError` (throwError . ("g Error: "++)) (Pay no attention to the () parameter behind the curtain! I'm dodging the monomorphism restriction, and don't want to give an explicit type signature.) The inferred type is f :: (MonadError [Char] m, MonadIO m) => () -> m [Char] i.e. it's usable for any nest of monads that provides the MonadError String and MonadIO features. Now, how to run it? Your type signatures of the form IO (Either String String) are very reminiscent of the ErrorT monad transformer newtype ErrorT e m a = ErrorT {runErrorT :: (m (Either e a))} with IO as m and String as e and a. So, let's test f in ErrorT String IO. *Main> runErrorT (f ()) >>= print 0 Right "" *Main> runErrorT (f ()) >>= print 2 Left "I don't like strings with 2 characters." *Main> runErrorT (f ()) >>= print 4 Too Right "Too\n" Regards, Tom

1 0

Open source project idea
by Craig Ugoretz 04 Jan '06

04 Jan '06

Hello, My name is Craig Ugoretz. For the past eight months, I have been researching an approach to programming a mathematical software application. This application will be based upon a collection of books written by Dr. Florentin Smarandache on the subjects of neutrosphic logic and neutrosophic cognitive maps. The applications of these new mathematical ideas are to better model paradoxes and contradictions in reasoning and the combined opinions of experts regarding sociopolitical situations. The books of interest to me form a subset of the material found on the website http://www.gallup.unm.edu/~smarandache/eBooks-otherformats.htm. The reason that I have written this mailing list is that I am looking for knowledgable Haskell programmers to aid me in writing this software. I have yet to learn Haskell, although I did have some success learning its "functional cousin", OCAML. I picked Haskell for this project because functional programming languages model mathematics more easily, and because I may have a need for computer algebra functionality in the application - so the DoCon Haskell library may be needed, if I understand its purpose correctly. Additionally, if there are people experienced with architecting Haskell programs or managing a Haskell programming project, their help may be invaluable as I finalize the research approach. The final software will be open source, meaning that the binaries and source code will be freely available to the public. If you are interested in participating in this effort, please let me know. I personally find functional programming and the mathematics of neutrosophy to be most interesting, and I derive value from the fact that this software could be used for a purpose that would benefit society. I look forward to your response. If you have concerns about what I have written above, also please let me know. Sincerely, Craig Ugoretz craigugoretz(a)yahoo.com

1 0

Haskell Weekly News: January 3, 2005
by dons＠cse.unsw.edu.au 03 Jan '06

03 Jan '06

Haskell Weekly News: January 3, 2005 Greetings, and thanks for reading the 18th issue of HWN, a weekly newsletter for the Haskell community. Each Monday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. This issue brings a change to the Haskell Weekly News as Don Stewart takes over from John Goerzen as editor. Thanks goes to John for his excellent work on the first 17 editions! 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * Process library. Bulat Ziganshin announced a [3]new library abstracting over some of the process and concurrency functions in the standard libraries, using ideas from Unix pipes. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12728 * Djinn. Lennart Augustsson [4]released Djinn, a theorem prover/coding wizard, that generates Haskell code from a given type. A lambdabot plugin for Djinn was also written, for use in #haskell. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12747 * Ranged Sets. Paul Johnson released a [5]ranged sets library 0.0.1 and [6]0.0.2. Ranged sets allow programming with sets of values that are described by a list of ranges. A value is a member of the set if it lies within one of the ranges. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/12749 6. http://article.gmane.org/gmane.comp.lang.haskell.general/12827 * Hmp3. Don Stewart [7]announced a stable release of hmp3, an curses-based mp3 player written in Haskell. Portability has improved, and binaries are available for 5 architectures. 7. http://article.gmane.org/gmane.comp.lang.haskell.general/12787 * HSQL. Krasimir Angelov released [8]HSQL 1.7. New features include a driver for Oracle. 8. http://article.gmane.org/gmane.comp.lang.haskell.general/12798 * HDBC. John Goerzen announced the [9]0.5.0, [10]0.6.0 and [11]0.99.0 releases of Haskell Database Connectivity library. Patterned after Perl's DBI, it includes an Sqlite3 and a [12]PostgreSQL backend 9. http://article.gmane.org/gmane.comp.lang.haskell.general/12820 10. http://article.gmane.org/gmane.comp.lang.haskell.general/12833 11. http://article.gmane.org/gmane.comp.lang.haskell.general/1286 12. http://article.gmane.org/gmane.comp.lang.haskell.general/12843 * Shellac. Robert Dockins [13]released Shellac, a framework for building read-eval-print style shells. This should ease the burden of binding readline-style interactive shells in Haskell. 13. http://article.gmane.org/gmane.comp.lang.haskell.general/12823 * Lambda Shell. Robert Dockins also released v0.1 of [14]Lambda Shell, a shell environment for evaluating terms of the pure, untyped lambda calculus. A lambdabot interface for use in #haskell also exists. 14. http://article.gmane.org/gmane.comp.lang.haskell.general/12824 * Shaskell. David Mercer [15]announced version 0.21a of Shaskell, a SHA2 library for sha256 and sha512 hashes, written in pure Haskell. 15. http://article.gmane.org/gmane.comp.lang.haskell.general/12863 * hdbc-missingh. John Goerzen [16]announced the initial release of HDBC-MissingH, a library to add database features to MissingH, allowing the use of a SQL database as storage for a simple DBM-like key/value interface. 16. http://article.gmane.org/gmane.comp.lang.haskell.general/12896 Discussion * Making Haskell More Open. Simon Peyton-Jones reinitiated a [17]discussion on how to make Haskell more open, and in particular how to make it easier for Haskell users to contribute. 17. http://thread.gmane.org/gmane.comp.lang.haskell.general/12804 * The Unboxed Kind. Ashley Yakeley [18]asked about creating type variables with unboxed kind. This lead to an interesting discussion about the difficulties that result, including the problems of polymorphic functions over unboxed values. 18. http://thread.gmane.org/gmane.comp.lang.haskell.general/12849 Haskell Toolchain Fptools in Darcs. John Goerzen has [19]set up live darcs mirrors of fptools, ready for testing. With over 13,000 patches in fptools, you'll want to use --partial. 19. http://article.gmane.org/gmane.comp.lang.haskell.general/12694 Darcs Corner * Darcs 1.0.5. A stable release of [20]Darcs 1.0.5 was made. This release includes fixes for Windows, as well as some new features. 20. http://article.gmane.org/gmane.comp.version-control.darcs.user/9009 * darcsweb. Alberto Bertogli [21]announced darcsweb 0.13, a rather lovely web interface to darcs repositories. 21. http://article.gmane.org/gmane.comp.version-control.darcs.user/9072 Quotes of the Week <sieni> State? <sieni> There is no state :-) <shapr> Haskell separates Church and state. About Haskell Weekly News Want to continue reading HWN? You can help us create new editions of this newsletter. Please see the [22]contributing information, send stories to dons -at- cse.unsw.edu.au. The Darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 22. http://sequence.complete.org/hwn-contrib

1 0

HWN Editor Found
by John Goerzen 03 Jan '06

03 Jan '06

I'm pleased to announce that Donald Stewart has agreed to take over as editor of HWN and will be publishing his first issue shortly. Thank you very much, Donald! -- John

1 0