Wed, 16 Jan 2002 08:29:09 +0000 (GMT)
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
> 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.)
www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will
email:firstname.lastname@example.org|slope upward exponentially, reaching the power
work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel