I would like to respond to John's note. My response is largely positive,
though I disagree with a couple of points.
>However, it is an independent question whether or not strictness annotations
>should be applicable to function types. And this is where I disagree with
>the committee. To quote `Introducing Haskell 1.3',
>
> Every data type, except ->, is a member of the Data class.
>
>In other words, in Haskell 1.3
>
> FUNCTIONS ARE NOT FIRST-CLASS CITIZENS
I cannot agree here. Functions are not members of the equality class either,
but that does not demote them to second class citizens. However, John may be
right in suggesting that people will become more reluctant to use functions
as values if they cannot force their evaluation.
>I see a very great cost in such a philosophical change, and I do not see
>that the arguments against strictly evaluating function values are so very
>compelling.
>
> Implementation difficulties? hbc has provided it for years, and
> even under the STG machine is the problem so very much harder than handling
> shared partial applications correctly?
I haven't checked hbc, but I would be interested if someone would confirm
that function strictify works properly. It didn't use to in LML.
> Semantic difficulties? The semantics of lifted function spaces are
> perfectly well defined. OK, so it's not the exponential of a CCC --- but
> Haskell's tuples aren't the product either, and I note the proposal to
> change that has fallen by the wayside.
This is probably an important point. I see there being value in two sorts
of functions: lifted and non-lifted (or equivalently boxed and unboxed).
A lifted function may be expressed as a computation which delivers a function,
just like lifted integers are computations which deliver integers. Under this
view it would be entirely in keeping with the rest of Haskell for the standard
functions to be lifted, and to leave open the possibility in the future of
introducing unlifted functions.
>So here's my proposal: change `Introducing Haskell 1.3' to read
>
> Every data type, including ->, is a member of the Data class.
I am inclined to agree. Is there a problem then that every type is in Data?
Not at all. The Data class indicates that forcing has been used in the
body of an expression. This is valuable information that is exposed in
the type.
John.
