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

[Yitzchak Gale]

I wrote:
>> ...it was recently claimed on this list that tuples
>> are not products in that category.

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

We're still working on it. I've not been convinced yet.
Sorry about my thickness.

Perhaps this should be on a nice wiki page somewhere.
I tried to convince David House to put it in the Wikibook
chapter, but he is right, that needs to simpler. There is
some discussion on the talk page for that
chapter, but no one spells out the details there, either.

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

Sorry, I hope I am not misrepresenting anyone. I just
notice that people make assumptions about a so-called
category Hask, derive various conclusions, then mention
that they are not really true. Perhaps it is only me who is
worried.

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

I'd like to understand better what is true, so that I can understand
what is safe.

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

It would be nice to distill out of that the basics that are needed
to get the properties that we need for day-to-day work in
Haskell.

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

I'm not sure it's so bad. First of all, not only is it not a formal
problem, it's also not really a practical problem - there will rarely
if ever be any difference between the two when applied in real
programs.

My opinion is that there would not be any problem with using
that version as (.) in the Prelude. Even if we never do, at least
we should then use (.!) when we state the so-called "Monad laws".
It bothers me that Haskell's so-called "monads" really aren't.
That is bound to cause problems.

And it would be so easy to fix in most cases - just require monad
bind to be strict on the second parameter.

Thanks,
Yitz