5 ms·

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

by rtpg 10y ago

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.

hota_mazi 10y ago
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.
- johncolanduoni 10y ago
  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.
- chriswarbo 10y ago
  > 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.
  - platz 10y ago
    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.
    - hnbroseph 10y ago
      are you saying they should check their haskell safety privilege? :^)
aninhumer 10y ago
You can build more granular effect systems on top of IO if you want, and many people have done.
- rtpg 10y ago
  True, this is maybe more about the ecosystem than the language itself.
  - taylorfausak 10y ago
    You can also build IO on top of the effect system https://github.com/slamdata/purescript-io https://github.com/slamdata/purescript-io :)
yyhhsj0521 10y ago
It's a good practice to wrap your IO with newtype.
danpalmer 10y ago
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.
- chriswarbo 10y ago
  > 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.
  - rtpg 10y ago
    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.
DanWaterworth 10y ago
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.
Buttons840 10y ago
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.
Iceland_jack 10y ago
That's what we attempted to remedy with `capabilities`[1] [1] https://hackage.haskell.org/package/Capabilities https://hackage.haskell.org/package/Capabilities

by rtpg 10y ago

hota_mazi 10y ago

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.

johncolanduoni 10y ago
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.
chriswarbo 10y ago
> 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.
- platz 10y ago
  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.
  - hnbroseph 10y ago
    are you saying they should check their haskell safety privilege? :^)

aninhumer 10y ago

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

rtpg 10y ago
True, this is maybe more about the ecosystem than the language itself.
- taylorfausak 10y ago
  You can also build IO on top of the effect system https://github.com/slamdata/purescript-io https://github.com/slamdata/purescript-io :)

yyhhsj0521 10y ago

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

danpalmer 10y ago

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.

chriswarbo 10y ago
> 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.
- rtpg 10y ago
  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.

DanWaterworth 10y ago

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.

Buttons840 10y ago

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.

Iceland_jack 10y ago

That's what we attempted to remedy with `capabilities`[1] [1] https://hackage.haskell.org/package/Capabilities https://hackage.haskell.org/package/Capabilities