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

On 22 Jan 2002, Martin [ISO-8859-1] Norb�ck wrote:

...

tis 2002-01-22 klockan 15.52 skrev Feuer:

...

Why is pattern matching on newtypes lazy? Does this add to efficiency somehow? If not, it seems to be just another rule to keep straight.

That's the difference between newtype and data. Newtypes are unboxed, so there is no constructor to match on. Pattern matching on newtypes is only a type-checker thing, the constructor doesn't exist.

I don't know if this helps or confuses, but I think of it as newtype using 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

newtype M a = M [a]

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.,

f x = M (x++x)

is easier to understand than

f x = (x++x):::M

so I can see why the constructor syntax was chosen.