GHC API: getting the unfolding of a "strange" Id

[Christiaan Baaij]

Thank you for the explanation, I think I pretty much understand what's going on now.
Indeed, nothing went wrong, it was just that I thought that the flag -fexpose-all-unfoldings would indeed put _all_ unfoldings in the interface file: even unfoldings that are bottom values.
For my use-case, I can just compile the file with -fno-strictness so that this top-level bottom value is never created in the first instance.

Here are the -dverbose-core2core files:
Compiled with no additional / default flags: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/noflags.core
Compiled with -fexpose-all-unfoldings: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfoldings.core
Compiled with -fexpose-all-unfoldings -fno-strictness: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfoldings_nostrictness.core

-- Christiaan


On Apr 1, 2014, at 1:11 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> These "absent" thunks appear when the strictness analyser works out that a function does not use an argument at all.  Suppose 'f' does not use its first argument. Then a call
> 	f (...big expression...)
> will be replaced with
> 	f (absentError "blah")
> 
> Such thunks almost invariably turn out to be dead code in the end, and are discarded.  It's very unusual for them to survive to the end of compilation, let alone as a top-level value.  But it's not impossible.
> 
> Just for curiosity, can you compile with -dverbose-core2core, and leave the results somewhere I can see them?
> 
> In short, it doesn't look as if there is anything wrong.  If there's a good reason you want to see the unfolding anyway, that's not impossible, but at least you understand what is happening now.
> 
> Simon