
Dear Cafe, I was surprised to see ghc accept this code ghci> do let {x = False}; not x True because I initially thought: there's a `do`, so there must be some monad, but which is it? some implicit Identity monad perhaps? But the type is indeed plain `Bool`, and the explanation is (I think): there is a `do` but there is no monad, since the translation according to ( https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.1... ) does never produce `(>>=)`. So, all is fine, nothing to see here. Perhaps keep in mind as an edge case, useful to confuse students. Actually, to motivate them to read the language standard ... - J.W.

Yeah, it's a bit confusing; I think some tutorials/books do go over the `do` simplification steps. I guess conceptually `do` doesn't mean `Definitely a Monad`, it means `Maybe a Monad` or more `Probably should be a Monad, and if not, just remove the do!`. On Wed, 21 Feb 2024 at 09:18, Johannes Waldmann < johannes.waldmann@htwk-leipzig.de> wrote:
Dear Cafe,
I was surprised to see ghc accept this code
ghci> do let {x = False}; not x True
because I initially thought: there's a `do`, so there must be some monad, but which is it? some implicit Identity monad perhaps?
But the type is indeed plain `Bool`, and the explanation is (I think): there is a `do` but there is no monad, since the translation according to ( https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.1... ) does never produce `(>>=)`.
So, all is fine, nothing to see here. Perhaps keep in mind as an edge case, useful to confuse students. Actually, to motivate them to read the language standard ...
- J.W. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Noon van der Silk http://silky.github.io/ "My programming language is kindness."

To my surprise, hlint (version 3.3.6) did not suggest taking out the do. I ran the following through hlint.
jk :: Booljk = do let x = False not x
On Wednesday, February 21, 2024 at 04:23:49 AM EST, Noon van der Silk

Notably, it is not always useful to suggest removing the `do`, e.g. I will often write that exact same `do` block with a let in it in tests, because it is very often the case that later down the line I do end up wanting to use binds/stop using binds in the `do` block, and I personally think the syntactic noise in the git diffs is not worth the (purely aesthetic?) benefit of not having the `do`. It's also useful if you're a fan of "abusing"(?) BlockArguments+`do` to turn f (foo bar baz) (u v) to f do foo bar baz do u v On 2/21/24 17:27, Mark McConnell via Haskell-Cafe wrote:
To my surprise, hlint (version 3.3.6) did not suggest taking out the do. I ran the following through hlint.
jk :: Bool jk = do let x = False not x
On Wednesday, February 21, 2024 at 04:23:49 AM EST, Noon van der Silk
wrote: Yeah, it's a bit confusing; I think some tutorials/books do go over the `do` simplification steps. I guess conceptually `do` doesn't mean `Definitely a Monad`, it means `Maybe a Monad` or more `Probably should be a Monad, and if not, just remove the do!`.
On Wed, 21 Feb 2024 at 09:18, Johannes Waldmann
wrote: Dear Cafe,
I was surprised to see ghc accept this code
ghci> do let {x = False}; not x True
because I initially thought: there's a `do`, so there must be some monad, but which is it? some implicit Identity monad perhaps?
But the type is indeed plain `Bool`, and the explanation is (I think): there is a `do` but there is no monad, since the translation according to ( https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.1... ) does never produce `(>>=)`.
So, all is fine, nothing to see here. Perhaps keep in mind as an edge case, useful to confuse students. Actually, to motivate them to read the language standard ...
- J.W. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- Noon van der Silk
"My programming language is kindness." _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

ghci> :set -XBlockArguments ghci> let be = id in do be do be do () () On Wed, Feb 21, 2024 at 3:18 AM Johannes Waldmann < johannes.waldmann@htwk-leipzig.de> wrote:
Dear Cafe,
I was surprised to see ghc accept this code
ghci> do let {x = False}; not x True
because I initially thought: there's a `do`, so there must be some monad, but which is it? some implicit Identity monad perhaps?
But the type is indeed plain `Bool`, and the explanation is (I think): there is a `do` but there is no monad, since the translation according to ( https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.1... ) does never produce `(>>=)`.
So, all is fine, nothing to see here. Perhaps keep in mind as an edge case, useful to confuse students. Actually, to motivate them to read the language standard ...
- J.W. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (5)
-
Brent Yorgey
-
Georgi Lyubenov
-
Johannes Waldmann
-
Mark McConnell
-
Noon van der Silk