* My taste is that isomorphic possibly-abstract types should get a new kind
of type declaration (newtype, isotype, or whatever), perhaps defined to be
exactly equivalent to a algebraic data type with just one strict
constructor. But I don't feel strongly about this.
(At least we appear to be agreed on the idea that there should
be an explicit constructor.)
Our tastes agree here.
* I'd misunderstood Phil's position about liftedness. He advocates
- unlifted functions
- lifted algebraic data types (all of them)
- unlifted tuples (just tuples, not all single-constr types)
Not quite. I advocate separate declarations for lifted constructors
and unlifted constructors. For lifted constructors, we have the
traditional `data' declaration, exactly as before. For unlifted
constructors we have
newtype T a_1 ... a_k = C t_1 ... t_n
where the a's are type variables, the t's are types, T is the
new type name, and C is the name of the single constructor. (It's
semantically impossible to have an unlifted sum type, which is why
there's only one constructor.)
Note that `newtype' yields Simon's isomorphic type declarion as a
special case when n=1.
I furthermore advocate that tuples be unlifted, i.e., defined by
`newtype' rather than `data'. (I'm not especially enamored of the name
`newtype'; any better suggestions?)
I have never, never been tripped up by the liftedness of tuples, but the
argument that ``we are prepared to pay for laziness so why not this too''
has a certain masochistic charm. I'll try the effect on performance of
making all tuple-matching lazy in the nofib suite.
Thanks Simon!
* Phil remarks that pattern-matching in let/where is implicitly twiddled.
That's true, and it is inconsistent; but while we might fix it for tuples,
we can't fix it for general algebraic data types --- so is it important to
fix it for tuples...?
Fair point. The only way to make the correspondence perfect is to ban
lifted contructors in `let' and `where', allowing only unlifted constructors.
This yields a neater language, but is probably too radical a change for
Haskell 1.3.
Cheers, -- P