* 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

Reply via email to