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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
