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...
Compiled with -fexpose-all-unfoldings: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfo...
Compiled with -fexpose-all-unfoldings -fno-strictness: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfo...
-- Christiaan
On Apr 1, 2014, at 1:11 PM, Simon Peyton Jones
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