News for hackers. Stuff that matters.
Re:Escaping Hell with Monads (2017) by julienfr112 on Friday February 23, 2018 @10:08AM (#16446696)
What happens when you mix what <- means :

do

  a <- getData // this is a awaiting a future

  b <- getMoreData a // this is looping a list

  c <- getMoreData2 b // this is null checking

  d <- getEvenMoreData a c // this is awaiting another future
  
  print d
Monads' hell, isn't it ?
Re:Escaping Hell with Monads (2017) by tominated on Friday February 23, 2018 @10:23AM (#16446825)
The do block syntax is actually just a syntax sugar for the `bind` function (also written `>>=`). The above would de-sugar to something like this (I may have syntax wrong):

  getData >>= \a ->
  getMoreData a >>= \b ->
  getMoreData2 b >>= \c ->
  getEvenMoreData a c >>= \d ->
  print d
The type signature of the `bind`/`>>=` function requires that both sides be the same type of monad, so it won't actually typecheck unless all of the get data functions return the same type of monad (future, list, optional, etc).

There's a number of ways to get around this in haskell (monad transformers, free/freer monads, etc) but they're all pretty complicated unless you're pretty familiar with the language.

(Disclaimer I'm probably a little wrong in my description - I'm still learning haskell)

Re:Escaping Hell with Monads (2017) by harpocrates on Friday February 23, 2018 @10:17AM (#16446771)
This is not possible in regular Haskell. For one, it isn't obvious how to do such a desugaring and, even if it were, this is pretty gross.

I remember a co-worker finding some weird combination of old extensions which allowed you to do something gross-ish of this form. I've _never_ seen such a thing in real life.

The only practical issue that comes close to this is sometimes trying to figure out _what_ monad a particular `do` block is running with (my mental type inference falls short of the compiler's).

Re:Escaping Hell with Monads (2017) by julienfr112 on Friday February 23, 2018 @10:22AM (#16446814)
i'm currently deciphering such code in scala ...
Re:Escaping Hell with Monads (2017) by hexointed on Friday February 23, 2018 @10:21AM (#16446808)
I believe that monad transformers can be used to solve this issue.
Re:Escaping Hell with Monads (2017) by mdellabitta on Friday February 23, 2018 @10:11AM (#16446719)
Being able to combine monads like this is part of the point.
Re:Escaping Hell with Monads (2017) by julienfr112 on Friday February 23, 2018 @10:20AM (#16446792)
it means that the fact that the monad is looping or checking for null or awaiting a future is coded in the function itself, and hidden when reading the for loop. When types are heavily overloaded, it can take minutes to know if we are looping a iterable, awaiting a futurable or checking for null a maybeable. And what about a Maybe(List) ? a Future of list ? Common, how is this not Hell ?
Re:Escaping Hell with Monads (2017) by igorbark on Friday February 23, 2018 @11:35AM (#16447370)
Haskell's type inference is optional: if you felt the above code is difficult to understand, you could manually specify the type of each statement.

In a language with a less powerful type system, you could write the same information in comments, but then the compiler wouldn't warn you if you accidentally changed the side effects of a statement.

Re:Escaping Hell with Monads (2017) by foldr on Friday February 23, 2018 @12:11PM (#16447632)
But you can't combine monads like that in Haskell.