Simon Marlow <[EMAIL PROTECTED]> wrote:
> The report is in general very careful to say absolutely *nothing*
> about evaluation order, leaving the implementation free to choose,
Yes, this is a highly desirable goal.
> However, having said all that, arguably an exception should be made in
> this case. The main use of seq (and strictness annotations) is to
> control operational behaviour, rather than to change the semantics of
> the program
Indeed, `seq` is widely viewed as a wart on the language _because_ it
specifies the evaluation order, which is something otherwise avoided in
the Report.
So the doubly bizarre thing is that, actually, `seq` does not control
the evaluation order (which is the only valid reason for wanting to use
it in the first place), but nevertheless it undesirably changes the
semantics of programs such that equational reasoning no longer holds.
I think if we are going to allow ourselves the luxury of semantic
breakage, it should at least be worth the cost - we should get some
real and definite operational control in return.
That is why I think this:
> the evaluation-order property of seq should be a strong hint, not a
> requirement - otherwise we fall into the trap of mandating evaluation
> order.
is not strong enough. `seq` should guarantee sequential evaluation. If
you want a strong (but not mandatory) hint to the compiler about
strictness, than that should be a different construct at the user level.
At the moment, these alternatives are named `pseq` and `seq`. One
suggestion is just to reverse their sense. Another is to use bang
patterns for hints. Another might be to introduce strictness hints in
type signatures.
Regards,
Malcolm
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
