In particular, strictly speaking (no pun intended), the way anything can throw errors is a violation of purity and breaks isomorphisms with category theory and constructive logic, which are the foundations that make functional programming such a powerful paradigm. The Haskell community does seem to maintain an preference against using these methods in pure functions, but the same philosophy could be integrated just as well in any other language through code reviews.

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".

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

What is your definition of purity?

What is your definition of side effect?

Do you think IO is pure, or impure?

What problems are there with set-based models of types with respect to exceptions?

Why would people think laziness is a good thing in the first place?

## re: Is Haskell bad for FP? VIEW POST

FULL DISCUSSIONLol. This is just wrong.

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".

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:

andrejbauer.github.io/domains-floc...

comonad.com/reader/2015/domains-se...

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

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

reddit.com/r/hascalator/comments/a...