>>>>> "Stefan" == Stefan Kahrs <[EMAIL PROTECTED]> writes:
> In a certain sense you have No. 4 already: it's called newtype. Newtypes
> can be recursive. Syntactically the constructors are still there, but
> that's only to help the type inference.
As I understand it, the purpose of newtype is to cut down on unnecessary
performance overhead when all you want to do is make a type abstract. I'm
interested in getting rid of the constructor altogether -- Gofer's
documentation gives a few examples where the constructor is superfluous. As
for the type inference, I think Jones also says that there is no reason why it
couldn't be implemented, just that he hadn't done it.
The only argument I've heard against doing this is that it changes the
meaning of the "type" keyword, since it no longer functions as just a "macro"
binding that rewrites to an existing type signature. I think this is a good
point, but it seems to me that the "type" keyword is kind of out-of-place in
Haskell in the first place, considering that Haskell avoids pre-processors
and other forms of syntax manipulation. Also, "type" is really only a 50%
solution in the first place, since it may cause misleading error messages.
If you ask me, regular-recursive datatypes are the only *good* use of
"type". Things like the String type really ought to be define using "newtype"
instead, although I'll grant you that it would be annoying to pattern-match
against every time.
As for recursive "newtype": Really? That's news to me. "newtype"
definitions only have one constructor, so any recursive definition would be an
infinite datatype. Since a newtype constructor is unlifted, this would make
recursive newtypes pretty useless.
--
Frank Christoph Next Solution Co. Tel: 0424-98-1811
[EMAIL PROTECTED] Fax: 0424-98-1500
