| 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.
What do you mean by "constructed the worker directly"? How does that differ
from "call the wrapper, and then (in a simplifier pass) inline the wrapper?
In general, the wrapper of a data constructor can do quite a bit of work:
evaluating arguments, unboxing them, casting newtypes, reducing type families.
Simon
| -----Original Message-----
| From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Christopher
| Done
| Sent: 02 February 2019 14:44
| To: ghc-devs@haskell.org
| Subject: Constructor wrappers vs workers in generated Core
|
| 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.has
| kell.org%2Ftrac%2Fghc%2Fwiki%2FCommentary%2FCompiler%2FDataTypes%23Thelif
| ecycleofadatatype&data=02%7C01%7Csimonpj%40microsoft.com%7Cf242a0e3c4
| 43448a439508d6891cd1d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63684
| 7154205957282&sdata=amZzhNxmR8Ods4%2BpsLQE4NzGHP%2FYeEaJevar%2Bl9cKFE
| %3D&reserved=0)
|
| 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@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cf242a0e3c443448a439508d
| 6891cd1d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847154205957282
| &sdata=KSCjmeulEQoL6CvOpLiiwNEX9a3DNnUVnPwbqdEXmOA%3D&reserved=0
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
