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