Here's a snippet from the Roc FAQ.
> It's impossible for a programming language to be neutral on this. If the language doesn't support HKP, nobody can implement a Monad typeclass (or equivalent) in any way that can be expected to catch on. Advocacy to add HKP to the language will inevitably follow. If the language does support HKP, one or more alternate standard libraries built around monads will inevitably follow, along with corresponding cultural changes. (See Scala for example.) Culturally, to support HKP is to take a side, and to decline to support it is also to take a side.
https://www.roc-lang.org/faq.html#higher-kinded-polymorphism
By adding the feature you aren't actually excluding the people who don't want to use it. They are free to avoid it and maintain parallel ecosystems where HKP is avoided.
You are only excluding them if the standard library forces them to interact with HKP code, which arguably Haskell does, and it makes a PITA for teaching it. Haskell however isn't doing it with the intention of exclusion.
On the other hand, not adding the feature because you don't like the culture it brings is intentionally exclusionary. You're intentionally taking a side against certain kinds of people and the certain kinds of code they want to be able to express without repetition... and you're hamstringing the expressibility of your language to do it.
I completely understand wanting to avoid HKP for teaching purposes, but maybe that is a problem that could better be resolved by always providing monomorphic options for standard library functions....
But avoiding HKP to avoid a certain kind of culture? Well now it's personal!
Still, hopefully it's clear why a language designer might want to go down a different path. After all, it's also totally reasonable to prefer an ecosystem which isn't fragmented along these lines (the way it is in, say, Scala) even though it means fewer different programming styles are supported.
[1]: https://homepages.inf.ed.ac.uk/slindley/papers/effmondel-jfp...
https://www.roc-lang.org/tutorial#task-failure
The implementation detail that makes this error handling possible is that Roc uses anonymous sum types called "tags" (OCaml calls them polymorphic variants) that can accumulate on the fly:
So the biggest difference is that algebraic effects are a separate language feature, whereas Task (like IO in Haskell) is a plain old type in the standard library that happens to represent effeects.
Incidentally, the Task.await function in Roc is based on Elm's Task.andThen - we just tried out a different name and argument order for it:
https://package.elm-lang.org/packages/elm/core/latest/Task#a...
In Roc, you can put a "!" (bind) pretty much anywhere, whereas in do-notation it must be part of a binding.
current_user <- fetch_user
manager <- fetch_manager current_user
manager <- fetch_manager (!fetch_user)
manager <- fetch_manager =<< fetch_userI think this version would is less approachable for most developers.
do x <- getx; y <- gety; x+y
getx! + gety!
[0] https://github.com/ghc-proposals/ghc-proposals/issues/527
(+) <$> getx <*> gety await x + y (+) <$> getx <*> gety
* summing two reads in a Transaction,
* summing two parsed numbers in a Parser,
* summing two Nullable values into one Nullable value,
* producing a Validated<T> by validating two of its parts which require validation,
* and on and on.
It's even the cartesian product when run on lists:
let suits = ["♠", "♥", "♦", "♣"]
let nums = concat [["A"], map show [2..10], ["J","Q","K"]]
let cards = (++) <$> nums <*> suits
putStrLn (unwords (take 15 cards))
A♠ A♥ A♦ A♣ 2♠ 2♥ 2♦ 2♣ 3♠ 3♥ 3♦ 3♣ 4♠ 4♥ 4♦
Also, it looks like you can just do it with ! in Haskell: https://hackage.haskell.org/package/monadic-bang
Yes, although it's slightly clumsy.
example = do
let suits = ["♠", "♥", "♦", "♣"]
let nums = concat [["A"], map show [2..10], ["J","Q","K"]]
let cards = do pure (!nums ++ !suits)
putStrLn (unwords (take 15 cards))
ghci> example
A♠ A♥ A♦ A♣ 2♠ 2♥ 2♦ 2♣ 3♠ 3♥ 3♦ 3♣ 4♠ 4♥ 4♦
1. Each IO operation returns a special value which denotes an IO action
2. These IO actions can be sequenced using a function which feeds an IO action to a continuation
3. Syntax sugar to remove the annoyance of explicitly writing the sequencing function
Together, (1) and (2) make this a monad; (3) in this article is just ‘do’-notation. The only major difference from Haskell is that Roc doesn’t generalise the idea to other monads, which makes it far less powerful than Haskell’s Monad typeclass.