(This issue is mostly as a future reminder to myself. I want to fix it in the new core implementation.)
The descend function in SimpleCodeMotion3.hs controls to which locations in an expression sub-expressions can be hoisted. At the moment, it permits any location except to lambdas that belong to let binders. This ensures that let binders always have the expected form: Let :$ a :$ Lam v :$ b.
It is also possible to control lifting through the MkInjDict argument. In Frontend.hs, we define mkId so that it is not allowed to lift to expressions of function type. In practice this has a similar effect to what we achieve with the descend function: If we cannot lift to expressions of function type, we cannot lift to lambdas. However, with the SICS flag on, we do allow lifting to expressions of function type (because we want to hoist constants over top-level lambdas), so that's why descend had to be modified.
I think it would be better to control lifting in a single place, and we need more fine-grained control than just distinguishing between functions and non-functions. A simple solution would be to just parameterize codeMotion on the descend function (probably with an additional parameter saying wether we're at the top level).
Also, we have many higher-order constructs like Let where we expect to find a lambda as an immediate child. We would probably want to rule out lifting to those lambdas as well. That could also be achieved by the above suggestion.
(This issue is mostly as a future reminder to myself. I want to fix it in the new core implementation.)
The
descendfunction in SimpleCodeMotion3.hs controls to which locations in an expression sub-expressions can be hoisted. At the moment, it permits any location except to lambdas that belong to let binders. This ensures that let binders always have the expected form:Let :$ a :$ Lam v :$ b.It is also possible to control lifting through the
MkInjDictargument. In Frontend.hs, we definemkIdso that it is not allowed to lift to expressions of function type. In practice this has a similar effect to what we achieve with thedescendfunction: If we cannot lift to expressions of function type, we cannot lift to lambdas. However, with theSICSflag on, we do allow lifting to expressions of function type (because we want to hoist constants over top-level lambdas), so that's whydescendhad to be modified.I think it would be better to control lifting in a single place, and we need more fine-grained control than just distinguishing between functions and non-functions. A simple solution would be to just parameterize
codeMotionon the descend function (probably with an additional parameter saying wether we're at the top level).Also, we have many higher-order constructs like
Letwhere we expect to find a lambda as an immediate child. We would probably want to rule out lifting to those lambdas as well. That could also be achieved by the above suggestion.