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

Having a nat -> atom conversion #21

Open
HuStmpHrrr opened this issue Apr 15, 2019 · 2 comments
Open

Having a nat -> atom conversion #21

HuStmpHrrr opened this issue Apr 15, 2019 · 2 comments

Comments

@HuStmpHrrr
Copy link
Contributor

since often the set of variables is assumed to be countably infinite, it's just clear that nat and atom are isomorphic types. in fact, atom is just hidden nat. would it make sense to have a function of type nat -> atom?

this would be helpful, for example,when examining a particular type checking example.

@HuStmpHrrr
Copy link
Contributor Author

the problem here is more fundamental: Modules in Coq are opaque. that means all modules in metalib cannot compute. is there any interest to fix this problem?

@dunnl
Copy link
Member

dunnl commented Apr 18, 2020

Old issue, but a comment for the record: The opaqueness isn't exactly a problem. A change at this line

Module Atom : ATOM.

to

Module Atom <: ATOM.

will make the module transparent. But this comes at the cost of exposing all of its details. It would no longer be possible to distinguish between atom and nat which would, for example, totally break my own library that uses Metalib. If one wants to compute with Metalib your options are rewriting terms based on the axioms of Atom, possibly automating this with tactics (like fsetdec), or extracting to OCaml/Haskell (a quite viable option).

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

2 participants