Hacker News Reader

Comment by still_grokking | Hacker News Reader

The key word here was "mandatory usage".

BTW: Haskell uses its IO wrapper also only for a very narrow set of effects.

One of my favorite examples: `head []` will result in a crash at runtime. IO won't safe you. (Besides that the whole "effect wrapping" story in Haskell is anyway shallow at best. There is nothing like "none observable effects" at all as every computation needs to happen in space-time, leaving observable traces therein; you can't define away "side channels" and call the result "pure"; that's mocking reality).

View on HN

> One of my favorite examples: `head []`

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.

Yet it is the actual behaviour in the stdlib Prelude.

Yep. I think it is needed to satisfy some category theory thing but I never got a good answer on that. I like to use nri-prelude since I went from Elm to Haskell and it has the same idioms, to wit `head : List a -> Maybe a`.

Yes. Because it's hard to remove things from the stdlib. More languages suffer from that.

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.

From GHC 9.6 there will be a warning against using head or tail. We don't actually want to remove them (yet) since that would break a lot of code.

> This is realllly unidiomatic in real world Haskell.

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!

> Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).

Issit? I thought they track effects in a special part of the type system as to not do it monadically. Possibly both are possible.

Reply on news.ycombinator.com