-
Notifications
You must be signed in to change notification settings - Fork 124
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
Impoting interfaces from functors #1581
Comments
Not sure if this is related, but I'm trying to define functors that "extend" a common interface in different ways and a functor that generates an instantiation of one extended interface in terms of the other; Cryptol reports that the same field in their respective imports of the same extended interface cannot match:
Demoting the functors that import the common interface into a common functor submodule that imports this interface (and adding
Returning to the original example and adding
Adding |
Currently we can't import an interfaces from a functor, because the instantiation of the functor would have to happen inside the module, and the parameters of the functor cannot depend on things defined inside it. For example:
We could allow such imports as long as the instantiation does not depend on anything in the module (i.e., it could be moved outside the module).
There is a second case that it would be good to support, and where the instantiation cannot be moved outside the module,
namely when we are passing through other parameters:
This requires us to change the implementation of pass through parameters, which is probably a good idea any way.
Currently, this would be desugared like this:
Note that in this case we cannot move
Anon
outside the module because it depends on the parameters that came in throughJ
. To support this, we should avoid creating the local "copy" module (AnonArg
in the example), and treat this type of instantiation as its own construct.To summarize, it should be possible to use interfaces from functor instantiations as long as the instantiations only depend
on externally defined modules and other parameters (and the parameter dependencies don't form loops of course).
The text was updated successfully, but these errors were encountered: