Yeah, I knew it was fairly unlikely that I was the first to think of
this optimization ;-)
I just reported the "run-time performance bug" as
http://hackage.haskell.org/trac/ghc/ticket/2902
I am using an Intel Core 2 Duo MacBook and GHC 6.10.1, OS X 10.5.6.
For the toy example that I submitt
Bertram Felgenhauer wrote:
Now in fact, IO actions are indistinguishable from pure computations by
the RTS, so this mechanism also makes IO actions resumable, in
principle, if you can access the corresponding thunk somehow. Normally
you can't - there is no reference to that thunk - but unsafePerf
Simon Peyton-Jones wrote:
This is a nasty corner I agree. GHC requires -XGADTs for you to *define* a
GADT. Perhaps it should also require -XGADTs for you to *match against* one (as
you are doing here). That would avoid this particular hole. If you think that
would be a step forward, do put
Hi,
I expected ":trace expr" to always add data to the trace history but it
does not do so for CAFs (which are not reduced yet).
My point is that the command ":trace z" did not add anything to the
trace history and I cannot check why value z is 2, because value of y is
not in the trace history
Simon Peyton-Jones wrote:
> | I have a good theory on the latter symptom (the "thread killed"
> | message). Sticking in some traces, as in my appended code, helped me
> | to see what's going on. It seems to be exactly what you describe --
> | the variable v is permanently bound to the exception it
| If I remove -XScopedTypeVariables from this http://hpaste.org/13230 then
| I get the following error message:
|
| > Asn1cTestNew.hs:55:27:
| > GADT pattern match in non-rigid context for `INTEGER'
| > Solution: add a type signature
| > In the pattern: INTEGER
| > In the definiti
Which version of GHC are you using? GHC 6.10 implements automatically
precisely the transformation you give below.
If the difference shows up in GHC 6.10, could you spare a moment to produce a
reproducible test case, and record it in GHC's bug tracker?
Thanks
Simon
| -Original Message---
| I have a good theory on the latter symptom (the "thread killed"
| message). Sticking in some traces, as in my appended code, helped me
| to see what's going on. It seems to be exactly what you describe --
| the variable v is permanently bound to the exception it "evaluates"
| to. Since the right
I have not followed the details of this thread, but Simon Marlow will be back
in action on 5 Jan and he should know.
What I do know is that this is supposed to happen:
* If a *synchronous* exception S is raised when evaluating a thunk, the
thunk is permanently updated to "throw S".
*
| Subject: Re: length of module name affecting performance??
|
| That's a truly awesome feature! I'll shorten all my module names to
| single letters tomorrow.
Awesome indeed :-). Try shortening all your variable names to single letters
to, to see if that helps. Oh, and delete all comments.
I
10 matches
Mail list logo
