newtype pattern matching

[D. Tweed]

(extra > because I initially sent this just Martin by mistake... oops)

> On 22 Jan 2002, Martin [ISO-8859-1] Norb=E4ck wrote:
>=20
> > tis 2002-01-22 klockan 15.52 skrev Feuer:
> > > Why is pattern matching on newtypes lazy?  Does this add to efficienc=
y
> > > somehow?  If not, it seems to be just another rule to keep straight.
> >=20
> > That's the difference between newtype and data. Newtypes are unboxed, s=
o
> > there is no constructor to match on. Pattern matching on newtypes is
> > only a type-checker thing, the constructor doesn't exist.
>=20
> I don't know if this helps or confuses, but I think of it as newtype usin=
g
> a `constructor' purely as a particular choice of syntax so that it looks
> similar to the more general constructor syntax. But you could imagine a
> different language design decision where instead of being written to look
> like a constructor, for the declaration
>=20
> newtype M a =3D M [a]
>=20
> a new syntax ::: was introduced where e:::M means `expression e can only
> be matched with the approriate type M a' (so for a concrete example, if
> e :: [Int], then e ::: M means e can only be matched with newtype
> M Int). Because of the similarity to the :: notation, which we're used to
> seeing as `typechecker glue' that is only there to inform compilation, it
> would be more intuitive that all the newtype stuff vanishes during
> compilation. However, I think this syntax falls down in actually
> constructing the raw values in the first place, e.g.,
>=20
> f x =3D M (x++x)
>=20
> is easier to understand than
>=20
> f x =3D (x++x):::M
>=20
> so I can see why the constructor syntax was chosen.