4 ms·

I would like to see an analysis of Hask when restricted in one of the following ways: 1. Only strict functions (f ⊥ = ⊥) 2. Only total functions (x ≠ ⊥ -> f x

I would like to see an analysis of Hask when restricted in one of the following ways: 1. Only strict functions (f ⊥ = ⊥) 2. Only total functions (x ≠ ⊥ -> f x ≠ ⊥) But otherwise, the notion that Hask is not a category is nothing new.

TAForObvReasons 10y ago
> But otherwise, the notion that Hask is not a category is nothing new. I'm not entirely sure. Read the official Haskell page on the subject: https://wiki.haskell.org/Hask https://wiki.haskell.org/Hask > In order to make Hask a category, we define two functions f and g as the same morphism if f x = g x for all x. Thus undef1 and undef2 are different values, but the same morphism in Hask. If I understand the passage correctly, they are defining the morphism in a way that makes Hask a category. I think the author of the original post interpreted it the same way.
- dietrichepp 10y ago
  It seems like the author isn't interpreting it the same way at all, because "(undefined . id)" would be the same morphism as "undefined" by the criteria on the wiki page, and then the author says that they must be different because you get different behavior when you pass them to "seq", which is a radically different set of criteria. Which is exactly what is addressed by the wiki page... you get different behavior when you use "seq" on two different things which are the same morphism. The wiki page even uses almost the same example.
catnaroek 10y ago
The problem is that the entire library ecosystem is built under false premises. It's annoying, because you occasionally stumble upon an abstraction leak, and then you need to take a really deep breath, climb down the abstraction ladder (which is pretty tall in Haskell's case!), and look for the exact place where something went wrong.
- dietrichepp 10y ago
  I'm not convinced. All abstractions are leaky, you just have to decide whether a particular abstraction is useful or not in spite of its leaks. I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. While this is definitely a problem in some Haskell code bases, you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code.
  - catnaroek 10y ago
    > All abstractions are leaky, I can tolerate abstraction leaks when the cost of using the non-leaky version is prohibitive. For example, I wouldn't want a language that constantly reminds me that memory allocation can fail. “Memory is infinite” is just too nice an abstraction, and I'm not going to let the fact it isn't true get in the way. But I can't live with a mismatch between the language's intended and actual semantics. If the Haskell language, libraries and community promise me that Hask is morally the category of sets, then it better be morally the category of sets! Of course, this promise is impossible to fulfill in a language without a typefully delimited terminating subset, so Haskellers better scale down their ambitions to something actually realizable. > I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. No, I don't mind high abstraction towers - I actually like them, in fact! What I hate is climbing them down because some abstraction leaked somewhere. > you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code. Since when is imperative code straightforward? Reasoning about purely functional programs: high school algebra, plus induction over datatypes. Reasoning about imperative programs: Hoare logic. The facts speak for themselves. In any case, this has nothing to do with functional vs. imperative. It's just “please don't impose cognitive dissonance on me!”
    - dietrichepp 10y ago
      That's a really disingenuous interpretation of "straightforward". If you don't want to have a real conversation then just don't bother replying next time.

TAForObvReasons 10y ago

> But otherwise, the notion that Hask is not a category is nothing new. I'm not entirely sure. Read the official Haskell page on the subject: https://wiki.haskell.org/Hask https://wiki.haskell.org/Hask > In order to make Hask a category, we define two functions f and g as the same morphism if f x = g x for all x. Thus undef1 and undef2 are different values, but the same morphism in Hask. If I understand the passage correctly, they are defining the morphism in a way that makes Hask a category. I think the author of the original post interpreted it the same way.

dietrichepp 10y ago
It seems like the author isn't interpreting it the same way at all, because "(undefined . id)" would be the same morphism as "undefined" by the criteria on the wiki page, and then the author says that they must be different because you get different behavior when you pass them to "seq", which is a radically different set of criteria. Which is exactly what is addressed by the wiki page... you get different behavior when you use "seq" on two different things which are the same morphism. The wiki page even uses almost the same example.

catnaroek 10y ago

The problem is that the entire library ecosystem is built under false premises. It's annoying, because you occasionally stumble upon an abstraction leak, and then you need to take a really deep breath, climb down the abstraction ladder (which is pretty tall in Haskell's case!), and look for the exact place where something went wrong.

dietrichepp 10y ago
I'm not convinced. All abstractions are leaky, you just have to decide whether a particular abstraction is useful or not in spite of its leaks. I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. While this is definitely a problem in some Haskell code bases, you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code.
- catnaroek 10y ago
  > All abstractions are leaky, I can tolerate abstraction leaks when the cost of using the non-leaky version is prohibitive. For example, I wouldn't want a language that constantly reminds me that memory allocation can fail. “Memory is infinite” is just too nice an abstraction, and I'm not going to let the fact it isn't true get in the way. But I can't live with a mismatch between the language's intended and actual semantics. If the Haskell language, libraries and community promise me that Hask is morally the category of sets, then it better be morally the category of sets! Of course, this promise is impossible to fulfill in a language without a typefully delimited terminating subset, so Haskellers better scale down their ambitions to something actually realizable. > I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. No, I don't mind high abstraction towers - I actually like them, in fact! What I hate is climbing them down because some abstraction leaked somewhere. > you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code. Since when is imperative code straightforward? Reasoning about purely functional programs: high school algebra, plus induction over datatypes. Reasoning about imperative programs: Hoare logic. The facts speak for themselves. In any case, this has nothing to do with functional vs. imperative. It's just “please don't impose cognitive dissonance on me!”
  - dietrichepp 10y ago
    That's a really disingenuous interpretation of "straightforward". If you don't want to have a real conversation then just don't bother replying next time.