This is realllly unidiomatic in real world Haskell. Even removed from Elm and PureScript.
Idris maybe has better effect handling for your taste. Also see: Koka, Frank (mainly a paper)
This is realllly unidiomatic in real world Haskell. Even removed from Elm and PureScript.
Idris maybe has better effect handling for your taste. Also see: Koka, Frank (mainly a paper)
Whether idiomatic or not does not matter. It proves my point:
IO won't save you, and even very mundane effects are not part of the game…
Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).
Koka is a toy, and Frank mostly "only a paper" (even there is some code out there).
The "Frank concept" is to some degree implemented in the Unison language, though:
https://www.unison-lang.org/learn/fundamentals/abilities/
Having a notion of co-effects (or however you please to call them) is imho actually much more important than talking about effects (as effects are in fact neither values nor types—something that all the IO kludges get wrong).
I think the first practicable approach in the mainstream about this topic will be what gets researched and developed for Scala. The main take away is that you need to look at things form the co-effects side first and foremost!
In case anybody is interested in what happens in Scala land in this regard:
https://www.slideshare.net/slideshow/embed_code/key/aLE9M37d...
https://docs.scala-lang.org/scala3/reference/experimental/cc...
But also the development in OCaml seems interesting:
https://github.com/ocaml-multicore/eio#design-note-capabilit...
Look mom, "effects", but without the monad headache!
Issit? I thought they track effects in a special part of the type system as to not do it monadically. Possibly both are possible.
Yet it is the actual behaviour in the stdlib Prelude.
What's nice is that the Haskell community offers several alternative Preludes; mostly fixing the problem you describe.
Hence I find the example a bit disingenuous.