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