Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)

[Isaac Dupree]

Tim Chevalier wrote:
> On 8/3/07, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
>> Stefan is right here.
>>
>> - It's not surprising that with -Onot you get different code from different source programs, even if one can readily be transformed into the other.  That's what -O does.
>>
> 
> Yes, but I found it surprising that just removing a type signature
> should result in markedly different code. Are there other known
> situations where that can happen?

It is not _just_ removing a type signature, it is also changing the type 
from `Bool` to `forall a. a`. An explicit type signature of the latter 
would have produced the same results as no type signature, I believe. 
The surprise is that an unconstrained type-variable being variable 
rather than instantiated to an arbitrary type, makes any difference 
(since it doesn't, normally, at runtime).  I would guess the programs 
`Bool` and `a` are the same once optimizations are turned on?  Maybe GHC 
could avoid the creation of type-lambdas that are unused (in some 
sense)... with -Onot... I'm dubious about that.

Inserting a preemption test in non-allocating loops seems like a good 
idea to me (I hate the invisible threat that my program might not thread 
as threading should work)... any idea how bad the performance impact 
could be (I guess the test could be specified to branch-predict that the 
loop wouldn't be interrupted), and whether there could be a pragma to 
disable that test in certain loops? Is -threaded versus not, relevant here?

Isaac