Re: [Haskell-cafe] expanded standard lib
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote:
On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote:
If you look at the stability tag of ghc libraries you will see that a lot of them are marked as "provisional" (Network.URI for example) or "experimental" (Control.Monad.Trans).
This may not refer to what most people care about; the "experimental" stability of Control.Monad.Trans is related to its use of fundeps and undecidable instances, and the possibility (likelihood?) of its being switched to type families (which "shouldn't" change its user-visible interface, as I understand it).
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please! /Björn
On Mon, Nov 19, 2007 at 11:31:51PM +0100, Bjorn Bringert wrote:
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please!
You mean something like http://darcs.haskell.org/packages/mtl-split ? The plan is to split Control.Monad.Identity, Control.Monad.Trans and Control.Monad.Trans.* off into a separate portable, low-level package.
-----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ross Paterson Sent: Monday, November 19, 2007 7:27 PM To: Haskell Libraries Subject: Re: [Haskell-cafe] expanded standard lib On Mon, Nov 19, 2007 at 11:31:51PM +0100, Bjorn Bringert wrote:
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please!
You mean something like http://darcs.haskell.org/packages/mtl-split ? The plan is to split Control.Monad.Identity, Control.Monad.Trans and Control.Monad.Trans.* off into a separate portable, low-level package. This demonstrates what I believe to be the only universally true statement about software engineering: If you have a great idea, someone else has already thought of it and has probably done something with it. :) Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Tue, 20 Nov 2007, Ross Paterson wrote:
On Mon, Nov 19, 2007 at 11:31:51PM +0100, Bjorn Bringert wrote:
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please!
You mean something like http://darcs.haskell.org/packages/mtl-split ? The plan is to split Control.Monad.Identity, Control.Monad.Trans and Control.Monad.Trans.* off into a separate portable, low-level package.
Nice, Control/Monad/Trans/State.hs is what I'm looking for! Yes it would be nice to have the low-level stuff separated from the multi parameter type classes.
On Tue, 20 Nov 2007, Ross Paterson wrote:
On Mon, Nov 19, 2007 at 11:31:51PM +0100, Bjorn Bringert wrote:
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please!
You mean something like http://darcs.haskell.org/packages/mtl-split ? The plan is to split Control.Monad.Identity, Control.Monad.Trans and Control.Monad.Trans.* off into a separate portable, low-level package.
I noticed that I frequently use (flip runReader, flip evalState) for point-free programming. What was the reason to choose the current order? What is the experience of other programmers?
On Thu, Nov 22, 2007 at 12:49:16PM +0100, Henning Thielemann wrote:
I noticed that I frequently use (flip runReader, flip evalState) for point-free programming. What was the reason to choose the current order? What is the experience of other programmers?
The flipped versions are also useful for pointy programming when the action is a large do-expression.
Henning Thielemann wrote:
I noticed that I frequently use (flip runReader, flip evalState) for point-free programming. What was the reason to choose the current order? What is the experience of other programmers?
I use both. Regards, Yitz
On Nov 22, 2007 12:49 PM, Henning Thielemann
On Tue, 20 Nov 2007, Ross Paterson wrote:
On Mon, Nov 19, 2007 at 11:31:51PM +0100, Bjorn Bringert wrote:
On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:
I like to see MTL split into a Haskell98 part and an advanced part. I mostly use functionality which would nicely fit into a Haskell98 interface and find it annoying that by importing MTL my code becomes less portable.
Yes! Please!
You mean something like http://darcs.haskell.org/packages/mtl-split ? The plan is to split Control.Monad.Identity, Control.Monad.Trans and Control.Monad.Trans.* off into a separate portable, low-level package.
I noticed that I frequently use (flip runReader, flip evalState) for point-free programming. What was the reason to choose the current order? What is the experience of other programmers?
The order of the run* functions comes from the fact that they are record selectors. This implies that they need to take the monadic computaion as their first argument. An example: newtype StateT s m a = StateT { runStateT :: s -> m (a,s) } I'm guessing that evalState and the other derived functions inherited the argument order from the run* functions. I also tend to the other order, with the monadic computation last. Cheers, Josef
Josef Svenningsson wrote:
The order of the run* functions comes from the fact that they are record selectors. This implies that they need to take the monadic computaion as their first argument. An example: newtype StateT s m a = StateT { runStateT :: s -> m (a,s) }
I'm guessing that evalState and the other derived functions inherited the argument order from the run* functions.
I also tend to the other order, with the monadic computation last.
I also tend to use them with 'flip', and was recently bemoaning this to myself! if records aren't constructed or pattern-matched with 'runStateT' (and why would they be?), it doesn't need to be a record selector... Isaac
participants (7)
-
Bjorn Bringert -
Henning Thielemann -
Isaac Dupree -
Josef Svenningsson -
Ross Paterson -
Seth Kurtzberg -
Yitzchak Gale