
No-one appears to have responded to this with a definitive answer... On Tue, 15 Jan 2002, Feuer wrote:
I know what you mean. However, if you look at it, data Empty1 a = E1 is a datatype with one constructor, and that constructor takes no arguments. So this is in fact a "phantom" unit type. newtype Empty2 a = E2 () is in fact better than data EmptyBad a = EBad () because the constructor E will be optimised away, and the type will be share the representation of the unit type (). However, I don't see why Empty1 and Empty2 would differ in any way at all... In any reasonable implementation, they would have the same internal representation, right?
Might this not be simply that an implementation _could_ compile them down to the same thing, but that given newtype exists in the language anyway (as I understand it primarily so that you can have types which the typechecker can tell aren't the same and yet leverage off an existing type which provides all the operations you need without suffering a run-time penalty) it's not worth the extra complication of adding special cases to the code for standard types (declared using data) so they are more efficient in this case. It's a point often made by Simon P-J that there aren't that many people actually working on Haskell interpreters/compilers around the world and work does get prioritised by the reward/difficulty ratio.
By the way, I don't understand why Haskell98 provides both strictness flags and newtype declarations.... it seems to me that newtype M [a1 a2 ....] = MC (...) should be exactly the same as data N [b1 b2 ....] = NC !(...) If I'm not mistaken, any compiler too dumb to notice a datatype with only one constructor strict in its one argument is too dumb to use.
Dunno (but I'm a Haskell diletantte), and I can't remember which order they were added to the language in. (I know newtype wasn't in the Haskell 1.0 report, I'm 99% sure strictness annotation wasn't either.) ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel