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 i
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 and
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 l
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 b
(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
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
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 funct
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).
I
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 convin
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,
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
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 de
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 a
13 matches
Mail list logo
