Hacker News Reader

Comment by rtpg | Hacker News Reader

One flaw I'd point out after working with Purescript a lot is that Haskell's "IO " is very large, to the point of not meaning anything.

printing to screen? IO

network connections? IO

launching the nukes? IO

You get this weird effect of having pure code, then _all_ your effectful code inhabiting the same types. Though this helps make you write more pure code, when you do write effectful code, it's not nearly as safe as one might want.

Purescript's effects is a nicer granular mechanism.

View on HN

While I agree that wrapping IO in newtypes for various purposes would be useful, from a somewhat more 'pure' standpoint, it's impossible to guarantee. Writing to a file could be network, it could be outputting to a screen somewhere, it could be launching the nukes, as far as I'm aware, it's essentially impossible to tell in many cases, so I think there's an argument for being 'honest' about this and not making type guarantees for things that aren't necessarily true.

> it's essentially impossible to tell in many cases, so I think there's an argument for being 'honest' about this and not making type guarantees for things that aren't necessarily true

I see what you mean, e.g. an innocent-looking message to stdout might be piped into a file, on a FUSE filesystem which could do anything. But I don't think that's really Haskell's problem; it's a case of Haskell conforming to an external interface, and anything plugged into that interface is the concern of the user/sysadmin.

The main reason that Haskell's IO is monolithic is that there's traditionally not been a nice way to combine monads (monad transformers get the job done, but there's always been a desire for something better).

Effect systems are becoming popular because they are more composable, and hence newer languages (PureScript, Idris, etc.) are favouring those over monads.

Right, it's not about what "really" happens, but more about what is ideally happening (I mean you can put IO effects in pure values through `unsafe` too).

My main gripe with monad transformers is that it doesn't really let you capture a "sum" of effects. Combining happens through a monad stack.

The effect systems let you describe "this and that" instead of "this in that", or "this, then that". For a lot of IO, "this and that" is much more useful.

You can build more granular effect systems on top of IO if you want, and many people have done.

True, this is maybe more about the ecosystem than the language itself.

You can also build IO on top of the effect system https://github.com/slamdata/purescript-io :)

At least half the value of "IO" is that it marks pure functions as being pure. If Haskell had a "Pure" typeclass instead of IO it would be much the same (except with the wrong default, and you'd have to type more!).

I like Purescript, and it might be worth making IO more granular as described. But my opinion is this would be focusing a lot of effort on the less valuable half of IO.

One way around this is to have typeclasses for all the different kinds of effects you'd like with instances for IO. Then for testing you can use a different instance that produces a value of a free monad.

That's what we attempted to remedy with `capabilities`[1]

[1] https://hackage.haskell.org/package/Capabilities

It's a good practice to wrap your IO with newtype.

It's almost as if programs are useless if they don't perform some IO and therefore, trying to encode this kind of side effects in the type system is theoretically interesting but practically inconvenient.

Yeah, but that's at the uppermost level. Having more granularity at least for functions in libraries between does nothing/does anything makes a lot of sense, considering the observable actions a function can take are often part of the documentation of an API.

> It's almost as if programs are useless if they don't perform some IO

You seem to have missed the point. At the moment, a CLI calculator has type "IO ()", a filesystem scanner has type "IO ()", an FTP library has type "IO ()", a random password generator has type "IO ()", etc.

It's very convenient that GHC points out when I try to, for example, perform arithmetic on lists, or insert unsanitised strings into templates. It would also be convenient if it points out when my CLI calculator is trying to perform network requests, when my filesystem scanner is trying to generate random numbers, when my random password generator is scanning the filesystem, etc.

In trying to advocate for fine-grained effect systems, i hope Haskell isn't presented as 'unsafe' according to an extremely high standard usually reserved for theorem proving languages. Pure functional programming is fighting an even more basic battle that side-effects should even be separated at all. I feel presenting Haskell's IO as unsafe throws out the baby along with the bathwater. Others have not reached the peaks you look down on.

are you saying they should check their haskell safety privilege? :^)

Reply on news.ycombinator.com