4 ms·

OCaml isn't purely functional, so it misses some of the most important benefits of Haskell. It's also not entirely honest (in the fact that you can do things th

by sparkie 14y ago

OCaml isn't purely functional, so it misses some of the most important benefits of Haskell. It's also not entirely honest (in the fact that you can do things that the type system doesn't tell you about.)

dllthomas 14y ago
With unsafePerformIO, Haskell is also not "entirely honest"...
- danieldk 14y ago
  That's certainly true and always be true given the mutability underlying architectures and operating systems. However, in Haskell, unsafePerformIO is normally only used when it can be shown that a function is referentially transparent. When this is not the case, a function ought to return an IO value. The general rule is: don't use unsafePerformIO unless your name is Simon ;). Haskell succeeded in isolating side effects to a great extend. It has its advantages, referential transparency leads to predictable and understandable code. And disadvantages - you have to keep state via argument passing (which can be hidden nicely using the State monad) and when implementing inherently mutable algorithms you usually end up using the ST monad. Still, on the outside, a function will be pure and pretty :).
  - dllthomas 14y ago
    This is all correct, and I do think it's an important difference between Haskell and OCaml, I just didn't like the way it was phrased ("lies") because that's not really the difference. The difference is that Haskell has a place for you to document (in the type system) whether functions have certain types of effects (and if you cooperate just a little, the compiler will make sure this documentation is correct). The cost is the (conceptual) overhead of actually doing this - which is small when you know what you're building but can require some re-plumbing of a chunk of your code when things change. This difference isn't inherently a win for Haskell - that OCaml doesn't bear the cost of significant restructuring because you find you need to do some IO based on results internal to a function several layers down is a big win in the short term. Whether it's a win in the long term, and how much the short matters versus the long, would seem to depend very much on the particular problems you're solving. Having come to Haskell from C by way of OCaml, my personal preference is to get as much out of the type system as one can - but one should always be aware of the trade-offs.
- applicative 14y ago
  With `{-#LANGUAGE Safe#-}` it is.
- Peaker 14y ago
  unsafePerformIO for an IO action that is not actually pure is considered a bug, and the compiler makes sure you can't abuse unsafePerformIO without being bitten very very hard.

by sparkie 14y ago

dllthomas 14y ago

With unsafePerformIO, Haskell is also not "entirely honest"...

danieldk 14y ago
That's certainly true and always be true given the mutability underlying architectures and operating systems. However, in Haskell, unsafePerformIO is normally only used when it can be shown that a function is referentially transparent. When this is not the case, a function ought to return an IO value. The general rule is: don't use unsafePerformIO unless your name is Simon ;). Haskell succeeded in isolating side effects to a great extend. It has its advantages, referential transparency leads to predictable and understandable code. And disadvantages - you have to keep state via argument passing (which can be hidden nicely using the State monad) and when implementing inherently mutable algorithms you usually end up using the ST monad. Still, on the outside, a function will be pure and pretty :).
- dllthomas 14y ago
  This is all correct, and I do think it's an important difference between Haskell and OCaml, I just didn't like the way it was phrased ("lies") because that's not really the difference. The difference is that Haskell has a place for you to document (in the type system) whether functions have certain types of effects (and if you cooperate just a little, the compiler will make sure this documentation is correct). The cost is the (conceptual) overhead of actually doing this - which is small when you know what you're building but can require some re-plumbing of a chunk of your code when things change. This difference isn't inherently a win for Haskell - that OCaml doesn't bear the cost of significant restructuring because you find you need to do some IO based on results internal to a function several layers down is a big win in the short term. Whether it's a win in the long term, and how much the short matters versus the long, would seem to depend very much on the particular problems you're solving. Having come to Haskell from C by way of OCaml, my personal preference is to get as much out of the type system as one can - but one should always be aware of the trade-offs.
applicative 14y ago
With `{-#LANGUAGE Safe#-}` it is.
Peaker 14y ago
unsafePerformIO for an IO action that is not actually pure is considered a bug, and the compiler makes sure you can't abuse unsafePerformIO without being bitten very very hard.