bug in language definition (strictness)

[Simon Marlow]

On 06/08/2009 14:20, Peter Gammie wrote:
> On 06/08/2009, at 10:59 PM, Simon Marlow wrote:
>> On 06/08/2009 13:49, Thomas Davie wrote:
>>> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote:
>>>
>>>> On 2009-08-06 11:08, Malcolm Wallace wrote:
>>>>> yet, because of the definition of $!, this applies the constructor to
>>>>> its arguments right-to-left instead of the intuitive left-to-right.
>>>>
>>>> I do not think that there is a bug: x `seq` y `seq` e has the same
>>>> denotation as y `seq` x `seq` e.
>>>
>>> Not if one considers the "kind" of bottom one receives:
>>>
>>> undefined `seq` error "it exploded" `seq` e will print
>>> "Prelude.undefined"
>>> while
>>> error "it exploded" `seq` undefined `seq` e will print "Error: it
>>> exploded"
>>
>> There's only one kind of bottom in Haskell 98. And even with the
>> imprecise exceptions extension, both expressions still have the same
>> denotation - they denote the same set of exceptions, one of which is
>> non-deterministically picked when the program is run.
>
> If the FFI Addendum is considered part of Haskell 98, then we have
> unsafePerformIO, and so an appeal to denotational equivalence is not
> sufficient. When grafting a pure interface onto a notionally-pure
> library (specifically a BDD library), I often used seq to get these
> effects buried in "pure" values under control.

That sounds like a very dangerous use of seq and unsafePerformIO to me!

The presence of unsafePerformIO doesn't change the meaning of the rest 
of Haskell.  You can use it to write programs that don't behave 
according to the denotational semantics if you want, but if you do that 
it's considered an unsafe use of unsafePerformIO.

What semantics would you like Haskell to have, in which (x `seq` y `seq` 
e) and (y `seq` x `seq` e) are not equal?

> I also think the principle of least surprise is clearly violated here.

I do have some sympathy with that.  The fact that we're having this 
discussion is evidence that something is wrong - and indeed it took 
quite a while before we noticed that seq doesn't actually enforce a 
sequential evaluation order.  And seq was originally introduced to fix 
space leaks, but sometimes it can't be used for this because it doesn't 
provide enough operational guarantees (I haven't seen such cases myself, 
but Malcolm W tells me it really happens).

I'm against the change originally proposed in this thread, because on 
its own it doesn't make any difference.  But by all means let's think 
about ways to restore the lack of surprise, but which hopefully don't 
curtail the compiler's ability to optimise, or run programs in parallel.

Cheers,
	Simon