Max,
If you want to look at a simple example, look at the Inf.hs example
included in the package.
It's very simple, and ghc generates fantastically bad code for it.
It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc
When I looked at it a year ago or so, it was a return of one
constructor in a sum.
Looking at core, you can see several places where a function is called
and that function always returns the same constructor, so the case
analysis of the return value is not needed; it should be returned as
an
Lennart,
| Unfortunately, GHC lacks certain optimizations to make efficient code
| when using CMonad,
| so instead of C speed you get low speed.
...
| When I looked at it a year ago or so, it was a return of one
| constructor in a sum.
| Looking at core, you can see several places where a
| When I looked at it a year ago or so, it was a return of one
| constructor in a sum.
| Looking at core, you can see several places where a function is called
| and that function always returns the same constructor, so the case
| analysis of the return value is not needed; it should be returned
Duncan and I have thought about this too, exactly as you describe.
(Just !x)
=
(# tag#, x# #)
-- Don
lennart:
When I looked at it a year ago or so, it was a return of one
constructor in a sum.
Looking at core, you can see several places where a function is called
and that function
2009/3/30 Don Stewart d...@galois.com:
Duncan and I have thought about this too, exactly as you describe.
(Just !x)
=
(# tag#, x# #)
It would be nice to generalize this to arbitrary sum types, but doing
so plays hell with the type checker - I think the most straightforward
way would
Nested constructed product returns? Or constructed sums?
lennart:
Well, yes and no. GHC actually does a decent job when given very
imperative code with references and mutable arrays.
Now the type I use to wrap the references to get type safe l-values
and r-values makes it tricker, and ghc
