Hm. Isn't _|_ simply, by definition, the bottom (least) element in an ordering? I see merit in Haskell's choice that () /= _|_, but so far I'm not persuaded that it's the only possible choice.<br><br><div class="gmail_quote">
On Sat, Jan 24, 2009 at 1:47 PM, Lennart Augustsson <span dir="ltr"><<a href="mailto:lennart@augustsson.net">lennart@augustsson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You can dream up any semantics you like about bottom, like it has to<br>
be () for the unit type.<br>
But it's simply not true. I suggest you do some cursory study of<br>
denotational semantics and domain theory.<br>
Ordinary programming languages include non-termination, so that has to<br>
be captured somehow in the semantics.<br>
And that's what bottom does.<br>
<font color="#888888"><br>
-- Lennart<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Sat, Jan 24, 2009 at 9:31 PM, Thomas Davie <<a href="mailto:tom.davie@gmail.com">tom.davie@gmail.com</a>> wrote:<br>
><br>
> On 24 Jan 2009, at 22:19, Henning Thielemann wrote:<br>
><br>
>><br>
>> On Sat, 24 Jan 2009, Thomas Davie wrote:<br>
>><br>
>>> On 24 Jan 2009, at 21:31, Dan Doel wrote:<br>
>>><br>
>>>> For integers, is _|_ equal to 0? 1? 2? ...<br>
>>><br>
>>> Hypothetically (as it's already been pointed out that this is not the<br>
>>> case in Haskell), _|_ in the integers would not be known, until it became<br>
>>> more defined. I'm coming at this from the point of view that bottom would<br>
>>> contain all the information we could possibly know about a value while<br>
>>> still being the least value in the set.<br>
>>><br>
>>> In such a scheme, bottom for Unit would be (), as we always know that the<br>
>>> value in that type is (); bottom for pairs would be (_|_, _|_), as all pairs<br>
>>> look like that (this incidentally would allow fmap and second to be equal on<br>
>>> pairs); bottom for integers would contain no information, etc.<br>
>><br>
>> Zero- and one-constructor data types would then significantly differ from<br>
>> two- and more-constructor data types, wouldn't they?<br>
><br>
> Yes, they would, but not in any way that's defined, or written in, the fact<br>
> that they have a nice property of being able to tell something about what<br>
> bottom looks like is rather nice actually.<br>
><br>
> Bob<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>