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

Confusing error from trying to use memory restrictions on module types #520

Open
oskgo opened this issue Mar 13, 2024 · 4 comments
Open
Assignees
Labels

Comments

@oskgo
Copy link
Contributor

oskgo commented Mar 13, 2024

The following example emits an unknown symbol error, which seems to be caused by the use of {-F}, but doesn't appear until much later:

module type Foo = {}.

module type Bar(F: Foo) {-F} = {
}.

module (Baz: Bar) (F: Foo) = {}.
@strub strub self-assigned this Mar 29, 2024
@strub strub added the bug label Mar 29, 2024
@strub
Copy link
Member

strub commented Mar 29, 2024

Not sure whether we want to accept this or not.

@fdupress
Copy link
Member

It would be neat to allow restrictions to be part of the module type. But we then need to allow them at all layers of the type. For a functor type, for example:

module type F {-M} (O : T) = {}.

is not the same as

module type F (O : T) {-M} = {}.

This may be more complex than we'd really like to make the module system at present?

@alleystoughton
Copy link
Member

And * (initialization) was moved out of the module declarations and into (well it was always in) the logic.

@oskgo
Copy link
Contributor Author

oskgo commented Apr 24, 2024

Personally I think it only makes sense to accept it if we also have implied bounds on lemmas. If not then we just have to repeat ourselves anyways.

If might seem like allowing these bounds would statically prevent some errors in definitions or statements, but I think in practice it won't because forgetting the bounds only makes the adversary more capable, which is fine.

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

4 participants