On Thu, Jun 11, 2009 at 9:37 AM, Sittampalam, Ganesh wrote:

John Lato wrote:

...

...

From: Henning Thielemann

...

...

No, I think it is already bad enough, that (>>) has type (m a -> m b -> m b) instead of (m () -> m b -> m b). It is like automatically ignoring return values in C. It is too easy to ignore a result that is important.

I agree with Henning on forkIO and the like, but I think the current type of (>>) is right.  The name of the function is "anonymous bind" (at least that's what I learned), and its whole purpose of existence is to ignore the value of the first computation while maintaining the context.

It would be nice if there were greater differentiation between (>>) and (>>=), though.  Ideally, (>>) would be changed to something longer than (>>=) to prevent accidental mis-typing (i.e. on the keyboard). Not that I expect much support for this proposal!

The main issue (IMO) is that do notation uses (>>) in the desugaring, which in turn means that it supports statements that just throw away not () results.

How is that a problem? The whole *point* of (>>) is that it discards unneeded return values. -- Dave Menendez http://www.eyrie.org/~zednenem/

On Thu, 11 Jun 2009, Sittampalam, Ganesh wrote:

David Menendez wrote:

...

How is that a problem? The whole *point* of (>>) is that it discards unneeded return values.

I think we should avoid having syntax that implicitly does this. So

do getLine return 3

should be banned, and users should be forced to write something like

do getLine >> ignore return 3

or do ignore getLine return 3

or

do _ <- getLine return 3

On Thu, 11 Jun 2009, David Menendez wrote:

On Thu, Jun 11, 2009 at 1:53 PM, Sittampalam, Ganesh wrote:

...

do _ <- getLine   return 3

Ganesh

Again, why do you think that? I much prefer the current syntax.

http://haskell.org/haskellwiki/Restrict_type_of_monadic_binding http://haskell.org/haskellwiki/Do_notation_considered_harmful#Safety

On Thu, 11 Jun 2009, David Menendez wrote:

On Thu, Jun 11, 2009 at 2:57 PM, Henning Thielemann wrote:

...

On Thu, 11 Jun 2009, David Menendez wrote:

...

Again, why do you think that? I much prefer the current syntax.

http://haskell.org/haskellwiki/Restrict_type_of_monadic_binding http://haskell.org/haskellwiki/Do_notation_considered_harmful#Safety

Aside from assertions that this is a bad thing because you say so, what evidence do we have that this is a problem?

The example on the Wiki is ExitCode. It is commonly ignored, but it must be respected, since its value tells whether it makes sense to continue with other actions. Not a good example? I can also ask the question, what are commonly results that you like to ignore by default where ignoring is the right thing? It's quite easy to add 'ignore' where necessary and it safes us from ignoring a result by accident. Avoiding errors is the goal of using types, isn't it?

On Thu, 11 Jun 2009, David Menendez wrote:

I'd ask why system is indicating failure through an exit code instead of throwing an exception.

Yes, throwing exception would also be nice. However current Haskell IO system hides the possibility of exceptions and does not tell, which exceptions may occur. To this end, various monads were developed (transformers,mtl:Control.Monad.Error, explicit-exception:Control.Monad.Exception.Synchronous, control-monad-exception). Of course, under the hood they use return values.

...

It's quite easy to add 'ignore' where necessary and it safes us from ignoring a result by accident. Avoiding errors is the goal of using types, isn't it?

If that's all there is to it, then why aren't you using Agda or Coq?

I assumed, Haskell shall also be developed towards dependent types, which are intended for more safety, aren't they? Nonetheless, I find Agda an interesting project.

Henning, Felipe, In the end, neither solution (changing the type of (>>) to require explicit 'ignores' vs. coping with the occasionally discarded important result) is perfect, so the bikeshed is highly unlikely to be repainted, especially since due to it being initially painted the other way, the preponderance of existing monadic code would have to rewritten to make any shift in the typing of (>>). Even if we had a time machine and wanted to go back and re-spec Monad again without the burden of prior art, I'm not entirely sure I would be in favor of enforcing an explicit discard through typing. Somewhat tongue in cheek, it seems that a 'must keep or consciously discard' parameter is more of the domain of a substructural type system than a library. That said, I do support the creation of an explicit ignore method, if only because the '() <$' idiom is less obvious in its intent at first glance and that the applications of ignore go beyond (>>), because of the types of mplus and (<|>). -Edward Kmett On Thu, Jun 11, 2009 at 4:26 PM, Felipe Lessa wrote:

On Thu, Jun 11, 2009 at 04:14:22PM -0400, David Menendez wrote:

...

Aside from assertions that this is a bad thing because you say so, what evidence do we have that this is a problem?

The wiki mentions the problem with forgetting the results of an operation. Another problem is using functions that needlessly produce results because you're interested in the side effects only. For example,

do mapM something1 list something2

(Hmmm, would something like

{-# RULES "mapM/mapM_" mapM = mapM_ #-}

work nicely?)

-- Felipe. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

David Menendez wrote:

On Thu, Jun 11, 2009 at 4:26 PM, Felipe Lessa wrote:

...

On Thu, Jun 11, 2009 at 04:14:22PM -0400, David Menendez wrote:

...

Aside from assertions that this is a bad thing because you say so, what evidence do we have that this is a problem? The wiki mentions the problem with forgetting the results of an operation.

This is exactly what I'm talking about. That page is written almost entirely by Henning Thielemann, but because it's on the official Haskell wiki, it seems authoritative.

It's a wiki, I think it should document problems even if not everyone agrees about them; I think it's our tradition to scatter pages with conflicting viewpoints around our wiki (and even cross-link them to each other). Please don't think things on the haskell-wiki are authoritative; I think they're there so that there is the potential to collaborate on them. That page even has links to some other people expressing the same frustrations. Feel free to update it sympathetically if we've discussed something here that would strengthen it as a page (and/or, is there a "do notation considered helpful" page?). Maybe something about "ignore" would strengthen it?; I'm not sure; or references to stronger languages like Agda where "forgetting" is a more crucial concept. -Isaac

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Jun 12, 2009 at 7:49 AM, Simon Marlow wrote:

I think it would help if there was a standard box we could put at the top of these sort of pages, something like

This page addresses an aspect of Haskell style, and the viewpoints expressed here may not be universally accepted within the community. To discuss the contents of this page, use the libraries@haskell.org mailing list.

Cheers, Simon

Your wish is my command: {{essay}} http://haskell.org/haskellwiki/Template:Essay http://haskell.org/haskellwiki/?title=Restrict_type_of_monadic_binding&curid=3366&diff=28583&oldid=16749 http://haskell.org/haskellwiki/?title=Do_notation_considered_harmful&curid=3362&diff=28584&oldid=26327 - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkoyXlEACgkQvpDo5Pfl1oIkVwCfY9QJOGLiUiA75HyaenGquqJp szUAnjB5Hs1PfrLGKbO7EDa+FcFDO1ue =suLb -----END PGP SIGNATURE-----

John Meacham wrote:

And here I always get annoyed by types that specify '()' explicitly when a universally quantified type will do. (`when` and `unless` are particularly offensive in this regard). Forcing idioms to be more verbose than necessary obscures intent.

Do we have any data that accidentally ignoring return values is a problem in practice?

On the flip side, could you give some examples where ignoring return values is useful and natural? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Thu, 11 Jun 2009, John Meacham wrote:

On Thu, Jun 11, 2009 at 11:21:54PM +0100, Sittampalam, Ganesh wrote:

...

On the flip side, could you give some examples where ignoring return values is useful and natural?

certainly, the very useful parser example mentioned.

(char 'x' >> char 'y') - we want to parse x, then y

Are you really interested to only ignore the result of the first 'char' parser and maintain the result of the second one?

(char 'x' `mplus` char 'y') - we want to parse one of x or y, returning which one we got so we can change behavior based on it.

Indeed using the same 'char' parser in both cases is convenient. It seems that parser monads are different from IO monad, in that it is more common to ignore results. (Or parser monads are developed with the simplicity of ignoring results in mind.) With char :: Char -> Parser Char ignore :: Functor m => m a -> m Ignore (or m ()) ignore = fmap (const Ignore) we would have to write ignore (char 'x') >> char 'y' char 'x' `mplus` char 'y' With char :: Char -> Parser Ignore (or Parser ()) echo :: Functor m => (a -> m Ignore) -> (a -> m a) echo f x = fmap (const x) $ f x we would write char 'x' >> char 'y' echo char 'x' `mplus` echo char 'y' If the parser library anticipates frequent use of ignore it could define a type class. class IgnorableChar a where wrapChar :: Char -> a class IgnorableChar Ignore where wrapChar _ = Ignore class IgnorableChar Char where wrapChar = id char :: IgnorableChar char => Char -> Parser char Cumbersome to define, but as simple to use as today's 'char' with today's '>>'. Just as a compromise for parser libraries. Ok, all these suggestions make things more complicated. Convenience vs. safety - It's certainly a matter of taste which one is more important for you.

When using the 'Writer' monad or similar it comes up a whole lot. sometimes you are interested in the result, sometimes the written value, sometimes both.

I think one should use Monoid class directly whereever possible. I have seen frequently that people use Writer monad instead of Monoid only because of the do notation.

John Meacham wrote:

And here I always get annoyed by types that specify '()' explicitly when a universally quantified type will do. (`when` and `unless` are particularly offensive in this regard). Forcing idioms to be more verbose than necessary obscures intent.

Indeed. In my personal libraries for scripting Haskell I define: infixr 8 `returning` {-# INLINE returning #-} returning :: (Monad m) => (a -> m b) -> (a -> m a) f `returning` x = f x >> return x precisely to get around this annoyance. The one I find particularly offensive is MonadState.put. In general, I find the use of () for what C-like languages would call void is a sign of excessive imperativism. If C had any measure of compositionality then it wouldn't be returning void either. Indeed, you can often see this corrected in the style of OOP where putatively void method returns the current object instead, so that they support method chaining, aka applicative style. There are certainly functions which should return () ---e.g. with the OOP analogy again, methods to close a file handle, destroy an object, etc--- but functions which should accept only () seem quite rare.

Do we have any data that accidentally ignoring return values is a problem in practice?

There is the memory leak (or stack overflow) problems of using mapM or sequence when the result is unused. I'm not sure if these fall under your "confused someone once" category, but they can be pernicious. This is potentially solvable by the compiler rewriting to mapM_ and sequence_ when it detects the result is unused; though whether that's the best solution is unclear. -- Live well, ~wren

Hello Henning, Friday, August 14, 2009, 8:55:58 PM, you wrote:

...

Also, treating '()' specially as 'don't care' as opposed to any other unit type doesn't sit right with me either. Sure it is an obvious choice for a don't care value, but the fact you can use others is nicely consistent with the idea that other than having some syntatic sugar, built in types are not special in haskell.

Agreed, it would be certainly better to have a special type like:

data Ignore = Ignore

and what () means, as you think? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com