[Haskell-cafe] Basic question concerning the category Hask (was: concerning data constructors)

[Derek Elkins]

On Wed, 2008-01-02 at 15:49 +0200, Yitzchak Gale wrote:

[...]

> Some people are worried that this version of Hask is missing
> certain nice properties that one would like to have. For
> example, it was recently claimed on this list that tuples
> are not products in that category. (Or some such. I would be
> interested to see a demonstration of that.)

Johnathan has given such a demonstration (and it has been demonstrated
many times on this list since it's creation, it's well-known).

> I am not impressed by those complaints. As usual in category
> theory, you define corresponding notions in Hask, and prove
> that they are preserved under the appropriate functors.
> That should always be easy. And if ever it is not, then you
> have discovered an interesting non-trivial consequence of
> laziness that deserves study.

You are right not to be impressed by such complaints, but you
misrepresent people's views on this by saying that the "worry" about
such problems.

As you say (people say), these properties [that Hask is cartesian closed
to start] would be nice to have and are very convenient to assume which
is often safe enough.  Certainly computer scientists of a categorical
bent have developed (weaker) notions to use; namely, monoidal,
pre-monoidal, Freyd, and/or kappa categories and no doubt others.  Using
these, however, removes some of the allure of using a categorical
approach.  Also, there is a Haskell-specific problem at the very get-go.
The most "obvious" choice for the categorical composition operator
assuming the "obvious" choice for the arrows and objects does not work,
it does not satisfy the laws of a category assuming the = used in them
is observational equality.  Namely, id . f /= f /= f . id for all
functions f, in particular, it fails when f = undefined.  This can
easily be fixed by making the categorical (.) strict in both arguments
and there is no formal problem with it being different from Haskell's
(.), but it certainly is not intuitively appealing.