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

Higher-order functors #41

Open
nilern opened this issue Jul 10, 2019 · 4 comments
Open

Higher-order functors #41

nilern opened this issue Jul 10, 2019 · 4 comments

Comments

@nilern
Copy link

nilern commented Jul 10, 2019

Higher-order functors are an old and obvious extension.

I think the only problem is whether defunctorizers like MLton can support them. I suspect that the module language would still be normalizing (since it can be reduced to a subset of System F(omega)) so the defunctorizer would still terminate instead of infinite expansion. Extending the actual algorithms would surely be nontrivial.

@RobertHarper
Copy link

RobertHarper commented Jul 10, 2019 via email

@JohnReppy
Copy link
Contributor

I've been lobbying for adding defunctorization to SML/NJ. Since we have separate compilation, we will need to pickle the abstract syntax (absyn) that is produced by the type checker and beta-reduce functors when they are applied. For higher-order functors, we may have to pickle the result, since we will only generate code once the functor has been reduced to a structure.

@MatthewFluet
Copy link
Contributor

Also, a recent paper by Elsman et al. (Static interpretation of higher-order modules in Futhark: functional GPU programming in the large, https://dl.acm.org/citation.cfm?doid=3243631.3236792) shows the defunctorization of higher-order modules works as one would expect.

@nilern
Copy link
Author

nilern commented Jul 11, 2019

I've been lobbying for adding defunctorization to SML/NJ. Since we have separate compilation, we will need to pickle the abstract syntax (absyn) that is produced by the type checker and beta-reduce functors when they are applied. For higher-order functors, we may have to pickle the result, since we will only generate code once the functor has been reduced to a structure.

Sounds similar to Elsman's thesis?

Also, a recent paper by Elsman et al. (Static interpretation of higher-order modules in Futhark: functional GPU programming in the large, https://dl.acm.org/citation.cfm?doid=3243631.3236792) shows the defunctorization of higher-order modules works as one would expect.

So all the details have already been worked out. Nice!

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

No branches or pull requests

4 participants