Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control descending in code motion #136

Open
emilaxelsson opened this issue Jan 16, 2015 · 0 comments
Open

Control descending in code motion #136

emilaxelsson opened this issue Jan 16, 2015 · 0 comments

Comments

@emilaxelsson
Copy link
Member

(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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant