Re: Haskell 1.3 (newtype)

[wadler@dcs.gla.ac.uk]

Resent-Message-Id: <199509121007.MAA24977@animal.cs.chalmers.se>
From: wadler@dcs.gla.ac.uk
Subject: Re: Haskell 1.3 (newtype)
Date: Tue, 12 Sep 95 11:03:51 BST
To: haskell@dcs.gla.ac.uk, jl@cse.ogi.edu, rjmh
Old-Resent-From: haskell-request@dcs.gla.ac.uk
Errors-To: haskell-request@dcs.gla.ac.uk
Approved: haskell@dcs.gla.ac.uk
Resent-Date:  Tue, 12 Sep 1995 11:04:43 +0100
Resent-From: kh@dcs.gla.ac.uk
Resent-To: haskell-list-dist@dcs.gla.ac.uk


The design of newtype appears to me incorrect.

The WWW page says that declaring

	newtype Foo = Foo Int

is distinct from declaring

	data Foo = Foo !Int

(where ! is a strictness annotation) because the former gives

	case Foo undefined of Foo _ -> True  =  True

and the latter gives

	case Foo undefined of Foo _ -> True  =  undefined.


Now, on the face of it, the former behaviour may seem preferable.  But
trying to write a denotational semantics is a good way to get at the
heart of the matter, and the only way I can see to give a denotational
semantics to the former is to make `newtype' define a LIFTED type, and
then to use irrefutable pattern matching.  This seems positively weird,
because the whole point of `newtype' is that it should be the SAME as
the underlying type.

By the way, with `newtype', what is the intended meaning of

	case undefined of Foo _ -> True ?

I cannot tell from the summary on the WWW page.  Defining `newtype'
in terms of `datatype' and strictness avoids any ambiguity here.

Make newtype equivalent to a datatype with one strict constructor.
Smaller language, more equivalences, simpler semantics, simpler
implementation.  An all around win!

Cheers,  -- P