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

Compilation of mixed functors #17

Open
Drup opened this issue Oct 26, 2016 · 2 comments
Open

Compilation of mixed functors #17

Drup opened this issue Oct 26, 2016 · 2 comments
Labels

Comments

@Drup
Copy link
Member

Drup commented Oct 26, 2016

functors with mixed parameters and/or result needs decliate handling of names. After discussion with @vouillon , we can try the following scheme:

  • On the client side, just erase all the server stuff
  • On the server side, each mixed module will be given an extra field that is a fragment containing the value representing the first class module representing the client side version of the module
  • each server version of a functor that take or emit a mix module must obey the convention (by applyting the client side version of the functor inside a fragment).
  • for eliom module, we must be careful of adding the extra field, which means registering a new fragment containing all the client side stuff in the eliom file.
@Drup Drup added the Runtime label Oct 26, 2016
@Drup
Copy link
Member Author

Drup commented Oct 26, 2016

Given a functor F(X:S) = M, the following property should hold : M_c should not depend on either M_s or X_s. This is analogous of using constant fragments.

For lifting this restriction, we could use a similar scheme than fragments, by extracting a functor parametrized by the holes.

@Drup
Copy link
Member Author

Drup commented Oct 26, 2016

Note: if we assume functor application are synchronous we can use a more general compilation scheme by just declaring new fragment cloture inside the functor and using a deterministic identifiers (ie. a counter) to number fragment clotures and injections.

Unfortunatly, synchronous functor application on both side means functor application is independent of control flow, which pretty much means only top level application (which is probably not the case for implicits).

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

No branches or pull requests

1 participant