bug in language definition (strictness)

[Malcolm Wallace]

>
>>> 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 can easily imagine that (x `seq` y `seq` e) might have *two*  
>> semantic
>> denotations: bottom (Exception: stack overflow), and e. And I would  
>> like
>> to be able to choose which one I get (please). This is the declared
>> purpose of seq, namely "to improve performance by avoiding unneeded
>> laziness".
>
> I'm afraid I don't really comprehend what you're getting at.  What  
> do you mean by an expression having two semantic denotations, and  
> how would you like to choose which one you get?  And I'm baffled by  
> the mention of stack overflow, where does that come in?

Whether it is a stack overflow, or some other kind of resource-related  
exception like out-of-memory, or too-many-open-file-handles, does not  
really matter.  As you were saying, semantically they are all just  
bottom.

My real point is that seq looks for all the world like it is intended  
to affect the operational behaviour of a program, yet some people  
insist that it is a purely denotational device, and that operational  
questions are not relevant.  The Report hints that using seq can  
"improve performance" (although the opposite is also true), and  
changes in performance are certainly an operational notion.  Yet I  
think it would be valid to say that seq can turn a non-terminating  
(exceptioning) program into a terminating one.

Regards,
     Malcolm