On 23/05/07, David House wrote:

Why should it compile? Expressions in a do-block have to have the type m a for some monad m, don't they?

Further developments on #haskell: dmhouse: where in the report does it say that do blocks constrain types inherently? <dmhouse> SamB_XP: I was under that impression, nothing more. dmhouse: ah. well, you would kind of think it would. but it looks like do is defined by translation, and like the Monad constraint only comes from >> and >>= <dmhouse> SamB_XP: right, so do (1 :: Int); (2 :: Int) is illegal as it doesn't match the type of (>>), but do (1 :: Int) isn't? dmhouse: so it would seem -- -David House, dmhouse@gmail.com

On Wed, 23 May 2007 19:54:27 +0100 "Neil Mitchell" wrote:

Hi

...

...

foo = do (1 :: Int)

While intuitively this should be disallowed, it seems a pity that desugaring couldn't be totally separated from typechecking. Hmm.

You can always desugar as:

do x ==> return () >> x

Although then you are relying on the Monad laws more than you possibly should. You could also have:

monady :: Monad m => m a -> m a monady x = x

do x ==> monady x

How about: do x ==> (x :: Monad m => m a) Or even: do x ==> (asTypeOf x (return ())) Cheers, Spencer Janssen

While we're on the topic of coupling/cohesion of types and syntactic sugar (and because sometimes problems are made easier by generalizing them), I have a question. What is the rationale for disallowing the following code? main = print "Type 'True' on three lines or I will quit." >> foo foo = [ () | line1 <- readLn, line1, line2 <- readLn, line2, line3 <- readLn, line3] Obviously this example is contrived, and you'd never want to use the list comprehension syntax for the IO monad. But you might want to for, say, the probability monad. Isn't that enough reason enough to decouple the sugar from the typing? (Though I agree with Claus that cryptic error messages are a bad thing.) On 5/23/07, Stefan Holdermans wrote:

Spencer,

...

How about:

do x ==> (x :: Monad m => m a)

That one does not do it, because now you demand x to be polymorphic in all monad types m and all monad-element types a, which I guess restricts x to

undefined

and

return undefined

and combinations thereof, glued together by monadic binds.

...

do x ==> (asTypeOf x (return ()))

Again, no, for now you restrict the element type to () and, hence, you preclude, for instance,

do return False

Cheers,

Stefan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

if you want to go down that route: Prelude> let monadic m = m `asTypeOf` return undefined Prelude> :t monadic undefined monadic undefined :: (Monad m) => m a Prelude> :t monadic $ undefined >> return () monadic $ undefined >> return () :: (Monad m) => m () Prelude> :t monadic $ undefined >> [ () ] monadic $ undefined >> [ () ] :: [()] Prelude> :t monadic $ undefined >> [ undefined ] monadic $ undefined >> [ undefined ] :: [a] btw, ghc says: Prelude> :t do undefined do undefined :: t t1 while hugs says: Hugs> :t do undefined do {...} :: Monad a => a b claus

On Wed, 23 May 2007, Ian Lynagh wrote:

On Wed, May 23, 2007 at 06:27:32PM +0100, Neil Mitchell wrote:

...

foo = do (1 :: Int)

While intuitively this should be disallowed, it seems a pity that desugaring couldn't be totally separated from typechecking. Hmm.

Disallow it by beating people around the head if they do it without good cause? Besides, this way round probably opens up a nice trick or two for people gutting the prelude who want to use the syntax for something slightly more general. -- flippa@flippac.org 'In Ankh-Morpork even the shit have a street to itself... Truly this is a land of opportunity.' - Detritus, Men at Arms