I wrote:
What goes wrong with finite coproducts? The obvious thing to
do would be to take the disjoint union of the sets representing the
types, identifying the copies of _|_.
Jonathan Cast wrote:
This isn't a coproduct. If we have f x = 1 and g y = 2, then there
should exist a function h
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
(sorry, I hit the send button)
What is the lifted version you are referring to?
Take the ordinary disjoint union, and then add a new _|_ element,
distinct from both existing copies of _|_ (which are still distinct
from each other).
Now why is that not the category-theoretic coproduct?
h .
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
Take the ordinary disjoint union, and then add a new _|_ element,
distinct from both existing copies of _|_ (which are still distinct
from each other).
Now why is that not the category-theoretic coproduct?
h . Left = f and h . Right = g both for _|_ and for finite
elements of the types. And it
On 6 Jan 2008, at 3:55 AM, Yitzchak Gale wrote:
I wrote:
What goes wrong with finite coproducts? The obvious thing to
do would be to take the disjoint union of the sets representing the
types, identifying the copies of _|_.
Jonathan Cast wrote:
This isn't a coproduct. If we have f x = 1
On 6 Jan 2008, at 5:32 AM, Yitzchak Gale wrote:
(sorry, I hit the send button)
What is the lifted version you are referring to?
Take the ordinary disjoint union, and then add a new _|_ element,
distinct from both existing copies of _|_ (which are still distinct
from each other).
Now why
Jonathan Cast wrote:
The normal view taken by Haskellers is that the denotations of
Haskell types are CPPOs.
So:
(1) Must be monotone
(2) Must be continuous
(Needn't be strict, even though that messes up the resulting
category substantially).
I wrote:
I'm not convinced that the category
On 5 Jan 2008, at 6:03 PM, Yitzchak Gale wrote:
Jonathan Cast wrote:
The normal view taken by Haskellers is that the denotations of
Haskell types are CPPOs.
So:
(1) Must be monotone
(2) Must be continuous
(Needn't be strict, even though that messes up the resulting
category substantially).
Hi Jonathan,
I wrote:
So in what way are Set morphisms restricted from being
Hask morphisms?
Jonathan Cast wrote:
The normal view taken by Haskellers is that the denotations of
Haskell types are CPPOs.
CPPO?
So:
(1) Must be monotone
(2) Must be continuous
Could you please define what
Jonathan Cast wrote:
The normal view taken by Haskellers is that the denotations of
Haskell types are CPPOs.
I wrote:
CPPO?
(1) Must be monotone
(2) Must be continuous
Could you please define what you mean by those terms
in this context?
Jens Blanck wrote:
The extra P would stand for
On 3 Jan 2008, at 3:40 AM, Jens Blanck wrote:
The normal view taken by Haskellers is that the denotations of
Haskell types are CPPOs.
CPPO?
So:
(1) Must be monotone
(2) Must be continuous
Could you please define what you mean by those terms
in this context?
(Needn't be strict, even
On 2 Jan 2008, at 5:49 AM, Yitzchak Gale wrote:
Hi Andrew,
Andrew Bromage wrote:
I still say it isn't a set in the same way that a group isn't a
set.
Haskell data types have structure that is respected by Haskell
homomorphisms. Sets don't.
Ah, that's certainly true. But what is that
13 matches
Mail list logo
