bug in language definition (strictness)

[Ravi Nanavati]

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?

Thanks,

 - Ravi

On Fri, Aug 7, 2009 at 6:30 AM, Malcolm
Wallace<malcolm.wallace at cs.york.ac.uk> wrote:
>> If, as I understand it, you are relying on the fact that seq's first
>> argument is evaluted before its second, then you really want pseq rather
>> than seq.
>>
>> In GHC we provide a way to do what you want (pseq), I'm just not convinced
>> it should be the required behaviour of seq.
>
> Whilst looking for something else, I have discovered that the official list
> of changes from Haskell 1.2 to Haskell 1.3 has this explicit statement:
>
> "The seq function evaluates its first argument before returning the second
> one."
>        http://haskell.org/definition/from12to13.html
>
> In addition, the 1.3 and 1.4 Reports, in describing how seq should be
> understood for any particular type, states:
>
> "The _case_ is used to force evaluation of the first argument to `seq`
> before returning the second argument."
>
> The Haskell'98 committee decided to remove the Eval class (that had seq as
> one of its methods), see
> http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=204
>
> I assume that it was simply inattention whilst editing the Report text, that
> caused the removal of the official requirement that seq evaluate its first
> argument before its second, because I can find no discussion by the
> committee that suggested such an important change.
>
> If you can point me to the committee discussion that led to changing this
> requirement, I would be grateful.
>
> Regards,
>    Malcolm
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>