Re: [Haskell-cafe] expanded standard lib

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] expanded standard lib

Bjorn Bringert-2
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



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] expanded standard lib

Ross Paterson
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: [Haskell-cafe] expanded standard lib

sethk


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] expanded standard lib

Henning Thielemann
In reply to this post by Ross Paterson

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Parameter order of runReader, evalState (Was: expanded standard lib)

Henning Thielemann
In reply to this post by Ross Paterson

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?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Parameter order of runReader, evalState (Was: expanded standard lib)

Ross Paterson
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Parameter order of runReader, evalState (Was: expanded standard lib)

Yitzchak Gale
In reply to this post by Henning Thielemann
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Parameter order of runReader, evalState (Was: expanded standard lib)

Josef Svenningsson
In reply to this post by Henning Thielemann
On Nov 22, 2007 12:49 PM, Henning Thielemann
<[hidden email]> wrote:

>
> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Parameter order of runReader, evalState (Was: expanded standard lib)

Isaac Dupree
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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries