Marnix Klooster <[EMAIL PROTECTED]> writes:
> I have a question on 'solitary constructors'; such a constructor is
> the only one in its data type. It appears to me that pattern matching
> using these constructors can be more lazy. To give an example from
> the Haskell 1.3 report, with
>
> data D1 = D1 Int
> d1 (D1 i) = 42
>
> currently "d1 undefined" is equivalent to "undefined". The reason for
> this is that "data" constructor patterns are refutable. But in the
> case of a solitary constructor, it would make sense to make the
> pattern irrefutable. This has already been done in the case of
> "newtype" constructors, which are in fact a special kind of solitary
> constructor.
>
> [snip]
This idea seems intuitively obvious. As you note, there's really no
way for a pattern (D1 i) to fail so there's no need to evaluate the
argument until i is required.
The main problem is that adding a constructor to a single-constructor
datatype changes the semantics of a program that uses it even if you
never use the constructor. We felt that this kind of semantic change
should be a syntactically "louder" than just adding or removing a
constructor.
There's also the minor problem of picking a semantics for non-unary
data constructors:
data D2 = D2 Int Int
d2 (D2 i1 i2) = 42
d2' ~(D2 i1 i2) = 42
If d2 (D2 undefined undefined) == undefined, you don't get the
laziness you want (or you have to make a special case of single
constructor _unary_ data types).
If d2 (D2 undefined undefined) == 42, we have to implement d2 in the
same (less efficient) way that we implement d2' under the current
semantics. This would be a bit of a shame since most compilers
currently generate better code for single constructor datatypes than
for multiple constructor datatypes and this change would make them
generate worse code :-( (This is why newtype constructors must be
unary.)
--
Alastair Reid Yale Haskell Project Hacker
[EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair.html
