Constructor wrappers vs workers in generated Core

Christopher Done chrisdone at gmail.com
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

GHC.Integer.Type.S#

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
here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DataTypes#Thelifecycleofadatatype)

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.

Cheers


More information about the ghc-devs mailing list