Is Prep supposed to keep thing in (reverse) dependency order?
ÉRDI Gergő
gergo at erdi.hu
Thu Nov 3 09:46:42 UTC 2022
Hi,
I was under the impression that the Prep'd Core is still in reverse
dependency order, i.e. if definition A refers to intra-module definition
B, then A's binding will always be preceding B's binding. I've been
exploiting this (hopefully not made-up and accidental!) property in my
work so far.
However, for the following input:
```
$s$fFunctorFun_$sfmap
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
$s$fFunctorFun_$sfmap
= (\ (@a)
(@b)
(f :: a -> b)
(g :: Fun '[AnnexType, CSASource, Currency, String] a)
(x1 :: AnnexType) ->
let {
g1 :: TFun '[CSASource, Currency, String] a
g1
= (g `cast` <Co:32>) x1 } in
(\ (x2 :: CSASource) ->
$s$fApplicativeFun_$s$fFunctorFun2
@Currency
@a
@b
f
(((g1 `cast` <Co:55>) x2)
`cast` <Co:22>)
`cast` <Co:148>)
`cast` <Co:125>)
```
I am getting the following output from Prep:
```
sat_s2iCp
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
sat_s2iCp
= (\ (@a)
(@b)
(f :: a -> b)
(g :: Fun '[AnnexType, CSASource, Currency, String] a)
(x1 :: AnnexType) ->
let {
g1 :: TFun '[CSASource, Currency, String] a
g1
= (g `cast` <Co:32>) x1 } in
let {
sat_s2iCo :: CSASource -> Currency -> Fun '[String] b
sat_s2iCo
= \ (x2 :: CSASource) ->
$s$fApplicativeFun_$s$fFunctorFun2
@Currency
@a
@b
f
(((g1 `cast` <Co:55>) x2) `cast` <Co:22>) } in
sat_s2iCo
`cast` <Co:148>)
`cast` <Co:125>
$s$fFunctorFun_$sfmap
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
$s$fFunctorFun_$sfmap
= \ (@a)
(@b)
(eta_B0 :: a -> b)
(eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) ->
sat_s2iCp @a @b eta_B0 eta_B1
```
Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to
`sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of
`$s$fFunctorFun_$sfmap`.
Is this expected, for some reason, or is this a GHC bug? If the latter,
I'm happy to file a ticket but I can't promise an actual end-to-end
compilable reproducer...
More information about the ghc-devs
mailing list