Adding type signature changes semantics (was [Haskell-cafe] Lazy
in either argument?)
isaacdupree at charter.net
Fri Aug 3 20:01:18 EDT 2007
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?
More information about the Glasgow-haskell-users