Constructor wrappers vs workers in generated Core

[Matthew Pickering]

There is no way to turn off wrappers and I don't think it would be
possible to implement easily if at all.

However, they will all probably be inlined after the optimiser runs
but it seems that you don't want to run the optimiser at all on the
generated core?

Perhaps it would be possible to set the inliner parameters so that
only wrappers ended up being inlined and nothing else and then call
the relevant function from the simplifier on your bindings to get rid
of them again.

Cheers,

Matt

On Sat, Feb 2, 2019 at 2:43 PM Christopher Done <chrisdone at gmail.com> wrote:
>
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs