Lennart writes:
| So if we had
|
| data Age = Age !Int
| foo (Age n) = (n, Age (n+1))
|
| it would translate to
|
| foo (MakeAge n) = (n, seq MakeAge (n+1))
|
| [makeAge is the "real" constructor of Age]
|
| Now, surely, seq does not evaluate its first argument when the
| closure is built, does it? Not until we evaluate the second component
| of the pair is n evaluated.
Indeed, the (seq MakeAge (n+1) isn't eval'd till the second component
of the pair is. But my point was rather that foo evaluates its argument
(MakeAge n), and hence n, as part of its pattern matching. Hence
foo is strict in n.
Sebastian writes:
| Is it really a good idea to extend the language simply to allow foo and
| foo' to be equivalent? The effect of foo' can still be achieved if Age is
| a strict data constructor:
|
| data Age = Age !Int
|
| foo'' :: Age -> (Int, Age)
| foo'' a = (n, Age (n+1)) where (Age n) = a
|
| and compilers are free (obliged?) to represent a value of type Age by an
| Int.
Indeed, it's true that foo'' does just the right thing. Furthermore, I
believe it's true that given the decl
data T = MkT !S
the compiler is free to represent a value of type T by one of type S (no
constructor etc).
Here are the only real objections I can think of to doing "newtype" via a
strict constructor. None are fatal, but they do have a cumulative effect.
1. It requires some explanation... it sure seems a funny way to
declare an ADT!
2. The programmer would have to use let/where bindings to project values
>from the new type to the old, rather than using pattern matching. Perhaps
not a big deal.
3. We would *absolutely require* to make (->) an instance of Data. It's
essential to be able to get
data T = MkT !(Int -> Int)
4. We would only be able to make a completely polymorphic "newtype" if
we added a quite-spurious Data constraint, thus:
data Data a => T a = MkT !a
(The Data is spurious because a value of type (T a) is going to be
represented by a value of type "a", and no seqs are actually going to be
done.)
5. We would not be able to make a newtype at higher order:
data T k = MkT !(k Int)
because there's no way in the language to say that (k t) must be in class
Data for all t.
[This is a somewhat subtle restriction on where you can put strictness
annotations, incidentally, unless I've misunderstood something.]
Simon
