On Fri, Aug 03, 2007 at 09:01:18PM -0300, Isaac Dupree wrote:
Tim Chevalier wrote:
On 8/3/07, Simon Peyton-Jones [EMAIL PROTECTED] 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?
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
