
On Mon, Oct 6, 2008 at 14:58, Cale Gibbard
2008/10/6 Don Stewart
: dagit:
data and newtype vary in one more subtle way, and that's how/when they evaluate to bottom. Most of the time they behave identically, but in the right cases they act sightly differently. newtype is usually regarded as more efficient than data. This is because the compiler can choose to optimize away the newtype so that it only exists at type check time. I think this is also possible with data in some, but not all, uses.
The compiler *must* optimise away the use. They're sort of 'virtual' data, guaranteed to have no runtime cost.
I'm not sure that I'd want to be that emphatic about what an implementation *must* do regarding something so operational.
The informal semantics of pattern matching in the Report says:
Matching the pattern con pat against a value, where con is a constructor defined by newtype, depends on the value: * If the value is of the form con v, then pat is matched against v. * If the value is _|_, then pat is matched against _|_. That is, constructors associated with newtype serve only to change the type of a value.
This clearly has an implementation which introduces no overhead, which one can expect from good implementations of the language. There are obviously implementations of these semantics which do introduce overhead as well though, so I would be hesitant to make any requirement like that.
And this requirement is there why? Is it specifically put in so that one is able to create this overhead-less implementation? Given: data A = A Int newtype B = B Int ta (A x) = True tb (B x) = True This happens (not surprisingly given your above comments): *Main GOA> :load test.hs [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main GOA> ta undefined *** Exception: Prelude.undefined *Main GOA> tb undefined True Why is the x evaluated in ta? cheers, Arnar