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

On Fri, Aug 03, 2007 at 09:01:18PM -0300, Isaac Dupree wrote:

Tim Chevalier wrote:

...

On 8/3/07, Simon Peyton-Jones 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.

It *does not change the designed semantics at all*. It *tickles a bug*. In the *absence of code generator bugs* it generates *semantically equivalent code*. Do you want inserting or removing type signatures to always tickle the same bugs? Seems like an awfully constraining desgin choice to me.

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?