Re: [Haskell-cafe] GHCi infers a type but refuses it as type signature

newer
combining monads with IO

older
[ANN] full-sessions: yet another...

papa.eric＠free.fr

23 Jun 2009 23 Jun '09

4:20 a.m.

...

Simple: the definition of MonadState uses those extensions.

Thanks, yes it helps and explains all. :^) I suppose then that if -XFlexibleContexts is indeed required by the standard libraries, it is a "safe" extension, meaning supported by all compilers? Are many such extensions de-facto standard that anyone can enable by default?

Show replies by date

Luke Palmer

23 Jun 23 Jun

5:34 a.m.

New subject: GHCi infers a type but refuses it as type signature

On Tue, Jun 23, 2009 at 2:20 AM, wrote:

...

...
Simple: the definition of MonadState uses those extensions.

Thanks, yes it helps and explains all. :^)

I suppose then that if -XFlexibleContexts is indeed required by the standard libraries, it is a "safe" extension, meaning supported by all compilers? Are many such extensions de-facto standard that anyone can enable by default?

Now to answer your question, with 50% less idealistic ranting! There is definitely a canon of "safe" extensions in the community. Hierarchical libraries (that's not even an -X flag, it's just on), multiparam typeclasses, fundeps are among them. I can't say whether FlexibleContexts is. However, your question is rather moot here, as you are using the *mtl. *It uses UndecidableInstances, whose blessing into the de facto standard would require as a precondition the batshit-insanity of the de facto community. I personally use *transformers* as my monad library, as it is (as far as I know) the only Haskell 98 monad library on Hackage (you'll hardly notice the more explicit lifts, I promise!). However, looking a bit more optimistically into the future, I'd say *mmtl *is the "most likely to succeed", since it solves the combinatorical explosion problem which haunts all the other monad libraries (and at least avoids the extensions which are doomed to failure). Anyway, it is never too early to free yourself of mtl. Look at the monad libraries on hackage and weigh their pros and cons; the only thing special about mtl is its mediocrity. Luke

wren ng thornton

24 Jun 24 Jun

10:35 p.m.

New subject: GHCi infers a type but refuses it as type signature

Luke Palmer wrote:

...

On Tue, Jun 23, 2009 at 2:20 AM, wrote:

...
...
Simple: the definition of MonadState uses those extensions. Thanks, yes it helps and explains all. :^)

I suppose then that if -XFlexibleContexts is indeed required by the standard libraries, it is a "safe" extension, meaning supported by all compilers? Are many such extensions de-facto standard that anyone can enable by default?

Now to answer your question, with 50% less idealistic ranting!

There is definitely a canon of "safe" extensions in the community. Hierarchical libraries (that's not even an -X flag, it's just on), multiparam typeclasses, fundeps are among them. I can't say whether FlexibleContexts is.

I wouldn't say that fundeps are "safe". They're well supported on GHC and Hugs, but they're hard to implement and can be tricky to reason about. Also the haskell' committee isn't too fond of them. Hierarchical modules and the FFI are "safe" in that they're really old amendments to the H98 report; so they're as good as H98 for most folks. CPP isn't blessed thus, but it's ubiquitous and easy to support. It's worth noting here that most Haskell compilers other than GHC and Hugs don't have full H98 support (even though that is the goal). Other extensions which shouldn't cause anyone to bat an eyelash are TypeSynonymInstances, FlexibleContexts, FlexibleInstances, NoMonomorphismRestriction, NoImplicitPrelude. Some of these only make sense with MPTCs. MPTCs may cause certain folks to bat an eyelash (once) because they're flagrantly non-H98 and aren't widely supported; but they are widely used, most implementations want them, and haskell' likes them. The Flexible* extensions are almost required to make interesting use of MPTCs. The OverlappingInstances extension should make one wonder if there's a better way to implement things, but it's supported by both Hugs and GHC and it can make MPTCs do some really fun things. If you start needing IncoherentInstances, then you should become concerned and start looking for another way. Rank2Types, RankNTypes, ExistentialQuantification, ScopedTypeVariables, and GADTs are fairly benign ---though this is where you start loosing compatibility with non-GHC compilers. Arrows would be benign except that the syntax keeps changing. Fundeps are also in this category I'd say: not widely supported, but fairly well known. UndecidableInstances could also go here, though it should always make one cautious. Anything else (TypeFamilies, TemplateHaskell,...) puts you firmly in GHC-only land which is perilous to portability/maintainability. -- Live well, ~wren

Bulat Ziganshin

25 Jun 25 Jun

1:19 a.m.

New subject: Re[2]: GHCi infers a type but refuses it as type signature

Hello wren, Thursday, June 25, 2009, 6:35:36 AM, you wrote:

...

Rank2Types, RankNTypes, ExistentialQuantification, ScopedTypeVariables, and GADTs are fairly benign ---though this is where you start loosing compatibility with non-GHC compilers.

afair, except for GADTs these are supported by Hugs. actually, until a last few years, GHC and Hugs were pretty close on extensions list -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

wren ng thornton

7:25 p.m.

New subject: GHCi infers a type but refuses it as type signature

Bulat Ziganshin wrote:

...

Hello wren,

Thursday, June 25, 2009, 6:35:36 AM, you wrote:

...
Rank2Types, RankNTypes, ExistentialQuantification, ScopedTypeVariables, and GADTs are fairly benign ---though this is where you start loosing compatibility with non-GHC compilers.

afair, except for GADTs these are supported by Hugs. actually, until a last few years, GHC and Hugs were pretty close on extensions list

True. I couldn't remember whether Hugs supported RankNTypes or not. In my mind all these extensions are of roughly the same bleeding-edge-ness, which is to say more than MPTCs and fundeps, but less than Template Haskell and type families. That's not entirely fair since GADTs are more bleeding-edge than Rank2Types (as witnessed by being GHC-only and still undecided on by the haskell' committee), and fundeps are still difficult to implement correctly, but all the same. Haskell98 has a Hindley--Milner type system (more or less). My point was that once you start extending the type system as far as existential quantification, higher-order universal quantification, polymorphic components, existential components, GADTs, and the like then you've left HM so far behind that most Haskell compilers cannot keep up. UHC also supports Rank2Types/RankNTypes and ExistentialQuantification, though it doesn't support fundeps. I don't know how well nhc98, yhc, jhc, or lhc support options like these or what the timeline would be for offering such support. In short, this is where portability beyond GHC becomes spotty. -- Live well, ~wren

Wei Hu

12:17 p.m.

New subject: GHCi infers a type but refuses it as type signature

Could you or anyone else briefly explain how mmtl solves the combinatorical explosion problem? Reading the source code is not very productive for newbies like me. Thanks! On Tue, Jun 23, 2009 at 5:34 AM, Luke Palmer wrote:

...

On Tue, Jun 23, 2009 at 2:20 AM, wrote:

...
...
Simple: the definition of MonadState uses those extensions.

Thanks, yes it helps and explains all. :^)

I suppose then that if -XFlexibleContexts is indeed required by the standard libraries, it is a "safe" extension, meaning supported by all compilers? Are many such extensions de-facto standard that anyone can enable by default?

Now to answer your question, with 50% less idealistic ranting! There is definitely a canon of "safe" extensions in the community. Hierarchical libraries (that's not even an -X flag, it's just on), multiparam typeclasses, fundeps are among them. I can't say whether FlexibleContexts is. However, your question is rather moot here, as you are using the mtl. It uses UndecidableInstances, whose blessing into the de facto standard would require as a precondition the batshit-insanity of the de facto community. I personally use transformers as my monad library, as it is (as far as I know) the only Haskell 98 monad library on Hackage (you'll hardly notice the more explicit lifts, I promise!). However, looking a bit more optimistically into the future, I'd say mmtl is the "most likely to succeed", since it solves the combinatorical explosion problem which haunts all the other monad libraries (and at least avoids the extensions which are doomed to failure). Anyway, it is never too early to free yourself of mtl. Look at the monad libraries on hackage and weigh their pros and cons; the only thing special about mtl is its mediocrity. Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Wei Hu

12:22 p.m.

New subject: GHCi infers a type but refuses it as type signature

OK, I found two papers by the author, Mauro Jaskelioff, that seem relevant. One paper "Modular Monad Transformers" is all category theoretical. Maybe I should read the other one "Monatron: An Extensible Monad Transformer Library". On Thu, Jun 25, 2009 at 12:17 PM, Wei Hu wrote:

...

Could you or anyone else briefly explain how mmtl solves the combinatorical explosion problem? Reading the source code is not very productive for newbies like me. Thanks!

On Tue, Jun 23, 2009 at 5:34 AM, Luke Palmer wrote:

...
On Tue, Jun 23, 2009 at 2:20 AM, wrote:

...
...
Simple: the definition of MonadState uses those extensions.

Thanks, yes it helps and explains all. :^)

I suppose then that if -XFlexibleContexts is indeed required by the standard libraries, it is a "safe" extension, meaning supported by all compilers? Are many such extensions de-facto standard that anyone can enable by default?

Now to answer your question, with 50% less idealistic ranting! There is definitely a canon of "safe" extensions in the community. Hierarchical libraries (that's not even an -X flag, it's just on), multiparam typeclasses, fundeps are among them. I can't say whether FlexibleContexts is. However, your question is rather moot here, as you are using the mtl. It uses UndecidableInstances, whose blessing into the de facto standard would require as a precondition the batshit-insanity of the de facto community. I personally use transformers as my monad library, as it is (as far as I know) the only Haskell 98 monad library on Hackage (you'll hardly notice the more explicit lifts, I promise!). However, looking a bit more optimistically into the future, I'd say mmtl is the "most likely to succeed", since it solves the combinatorical explosion problem which haunts all the other monad libraries (and at least avoids the extensions which are doomed to failure). Anyway, it is never too early to free yourself of mtl. Look at the monad libraries on hackage and weigh their pros and cons; the only thing special about mtl is its mediocrity. Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

David Menendez

1:10 p.m.

New subject: GHCi infers a type but refuses it as type signature

On Thu, Jun 25, 2009 at 12:17 PM, Wei Hu wrote:

...

Could you or anyone else briefly explain how mmtl solves the combinatorical explosion problem? Reading the source code is not very productive for newbies like me. Thanks!

It's a good question, since from what I can tell mmtl does not solve the problem. Some quick background: If you have M monad transformers and N classes of operations, you normally need M*N instance declarations, i.e., one per transformer per class. Each instance either provides the functionality directly, such as the MonadState instance for StateT, or promotes it from the underlying monad, such as the MonadState instance for ReaderT. mmtl instead provides 2*M instances. For each transformer, it has one direct instance (such as MonadState (StateT s m)) and one instance which promotes through any transformer (such as MonadState (t (StateT s m))). The problem is that this limits you to using at most two transformers at a time. For example, the type ErrorT String (ReaderT Int (StateT Int m)) is an instance of MonadError and MonadReader, but not MonadState because it doesn't have the form t (StateT s m). -- Dave Menendez http://www.eyrie.org/~zednenem/

Wei Hu

2:51 p.m.

New subject: GHCi infers a type but refuses it as type signature

On Thu, Jun 25, 2009 at 1:10 PM, David Menendez wrote:

...

On Thu, Jun 25, 2009 at 12:17 PM, Wei Hu wrote:

...
Could you or anyone else briefly explain how mmtl solves the combinatorical explosion problem? Reading the source code is not very productive for newbies like me. Thanks!

It's a good question, since from what I can tell mmtl does not solve the problem.

Some quick background: If you have M monad transformers and N classes of operations, you normally need M*N instance declarations, i.e., one per transformer per class. Each instance either provides the functionality directly, such as the MonadState instance for StateT, or promotes it from the underlying monad, such as the MonadState instance for ReaderT.

mmtl instead provides 2*M instances. For each transformer, it has one direct instance (such as MonadState (StateT s m)) and one instance which promotes through any transformer (such as MonadState (t (StateT s m))).

The problem is that this limits you to using at most two transformers at a time. For example, the type ErrorT String (ReaderT Int (StateT Int m)) is an instance of MonadError and MonadReader, but not MonadState because it doesn't have the form t (StateT s m).

-- Dave Menendez http://www.eyrie.org/~zednenem/

Very well explained. Thanks.

5811

Age (days ago)

5813

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Bulat Ziganshin
David Menendez
Luke Palmer
papa.eric＠free.fr
Wei Hu
wren ng thornton