bug in language definition (strictness)

[Simon Marlow]

On 07/08/2009 12:17, Ravi Nanavati wrote:
> I wonder if this discussion has veered too far into legalistic
> reasoning (of various sorts). From where I'm standing the
> state-of-play is this:
>
> 1. Compiler writers (and some users) want a "liberal" version of seq
> (that's slippery about evaluation order) for optimizations and better
> correspondence with the denotational semantics.
> 2. Other users want a version of seq that guarantees evaluation order
> for use cases where that matters.
>
> Is there any deep reason why we don't just figure out what the best
> way to give people both versions of seq is and do that?

Compilers can provide seq with an ordering guarantee if they want, just 
as GHC does with Control.Parallel.pseq.  I don't think it would be good 
to mandate this in the standard, for the reassons I've already described 
in this thread, in summary:

  - it constrains evaluation order in a way that Haskell
    doesn't currently do, and which might prevent interesting
    implementations (e.g. automatic parallelisation)

  - it's not clear how to specify what "seq with an ordering guarantee"
    actually means.  If someone were to come up with a precise
    definition, that would be a much better basis for discussion.

Cheers,
	Simon