re: Is Haskell bad for FP? VIEW POST

re: In particular, strictly speaking (no pun intended), the way anything can throw errors is a violation of purity and breaks isomorphisms with categor...

You're right, I had the wrong definition of purity and side-effects.

Nevertheless, the intuition remains. By allowing errors to be based on ⊥, types in Hask become less informative than they would be in just the Set category extended with infinite recursion (let's call it Set∞). Essentially it is much like using a Kleisli category of Set∞ with monad Either Error. This is very similar to what you get when allowing side-effects, which use the IO monad instead.

My confusion came from incorrectly thinking that a side-effect was anything not properly represented in the type system, and purity merely means "no side-effects".

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Doubling down on jargon isn't going to help - it just shows how little you know to people who actually know these things. Choosing to publish an ignorant post and back it up with ignorant rebuttals is not endearing.

Haskell types are modeled as Domains and have all of those caveats. See:

The principle reason being that Domains model denotational semantics a la the category of Scott Domains as models of the lambda calculus. It's fairly easy to navigate around ⊥ if you think about your statements in any more depth than operationally.

Here is a list of questions for you to answer for yourself in order

  1. What is your definition of purity?
  2. What is your definition of side effect?
  3. Do you think IO is pure, or impure?
  4. What problems are there with set-based models of types with respect to exceptions?
  5. Why would people think laziness is a good thing in the first place?

Here is a good place to start for the last one:

code of conduct - report abuse