... so I  don't think it makes sense to consider (>) a part of Bool's semantics, no?

A denotational semantic definition for a type (more traditionally, a syntactic category) have two parts: a semantic domain and a collection of *compositional* definitions for the building blocks of that type.  ("Compositional" in that a construct is defined strictly in terms of the meanings of its components.)  I think you're talking about the latter, while my complexity claim is about the former: What semantic model can we have for Bool, i.e. what is [[Bool]]?  The model I'd like in a lazy functional language is the domain containing exactly three elements: true, false, and bottom (with the usual information ordering).

Whatever the domain corresponding to Bool is, the denotation of every (well-formed) Bool expression is an element of that domain.

The question I'm asking is this: Assuming compositional semantics, can [[Bool]] be this simple & customary three-value domain in the presence of an implementation-dependent [[Int]] (given that Int expressions can play a non-trivial role in Bool expressions)?

(Now you might say that Bool is just a data type definition.  If so, then rephrase the question in terms of simple data type definitions.)

  - Conal

On Mon, Mar 23, 2009 at 7:54 AM, Jake McArthur <jake@pikewerks.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Conal Elliott wrote:
| Consider
|     big :: Int
|     big = 2147483647
|     dodgy :: Bool
|     dodgy = big + 1 > big
|     oops :: ()
|     oops =  if dodgy then () else undefined
|
| Assuming compositional semantics, the meaning of oops depends on the
| meaning of dodgy, which depends on the meaning of big+1, which is
| implementation-dependent.  So a semantic domain for Bool and even ()
| would have to include the machine-dependence of Int, so that oops could
| mean a function from MachineInfo that returns () sometimes and bottom
| sometimes.  If the denotations (semantic domains) for Bool and () didn't
| include this complexity, they wouldn't be rich enough to capture the
| machine-dependence of dodgy and oops.

Since Bool's constructors are exported, we can define (>) anywhere, so I
don't think it makes sense to consider (>) a part of Bool's semantics, no?

- - Jake McArthur
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknHoq4ACgkQye5hVyvIUKkRugCghgh6qNqmpWvD5SQYX/8PzUws
0Y8AoM3qJS5RIzoEFbD2aN1rR6EdJWh9
=ozCQ
-----END PGP SIGNATURE-----