Constructor wrappers vs workers in generated Core

Christopher Done chrisdone at
Sat Feb 2 14:43:37 UTC 2019

Hi all,

I'm compiling Haskell modules with this simple function. I'd like to
interpret the Core for practical use and also educational use.

compile ::
     GHC.GhcMonad m
  => GHC.ModSummary
  -> m GHC.ModGuts
compile modSummary = do
  parsedModule <- GHC.parseModule modSummary
  typecheckedModule <- GHC.typecheckModule parsedModule
  desugared <- GHC.desugarModule typecheckedModule
  pure (GHC.dm_core_module desugared)

And then I'm taking the mg_binds from ModGuts. I want to work with the
simplest, least-transformed Core as possible. One thing that's a
problem for me is that e.g. the constructor


in this expression

\ (ds_dnHN :: Integer) ->
  case ds_dnHN of _ [Occ=Dead] {
    S# i# ->
      case isTrue# (># i# 1#) of _ [Occ=Dead] {
        False -> (\ _ [Occ=Dead, OS=OneShot] -> $WS# 2#) void#;
        True ->
          case nextPrimeWord# (int2Word# i#) of wild_Xp { __DEFAULT ->
          wordToInteger wild_Xp
    Jp# bn -> $WJp# (nextPrimeBigNat bn);
    Jn# _ [Occ=Dead] -> $WS# 2#

is referred to by its wrapper, "$WS#". In general, I'd prefer if it
Core always constructed the worker S# directly. It would reduce the
number of cases I have to handle.

Additionally, what if a worker gets transformed by GHC from e.g.
"Wibble !(Int,Int)" to "Wibble !Int !Int", are then case alt patterns
going to scrutinize this transformed two-arg version?  (As documented

So my question is: is it possible to disable this wrapper
transformation of data constructors?

If not it seems like I'll have no option but to handle this extra
wrapper stuff, due to the case analyses. That wouldn't be the end of
the world, it'd just delay me by another week or so.

For strict fields in constructors I was planning on simply forcing the
fields in my interpreter when a constructor becomes saturated (and
thereby enabling some nice inspection capabilities), rather than
generating extra wrapper code that would force the arguments.


More information about the ghc-devs mailing list