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

Coq inhabited errors #1470

Merged
merged 11 commits into from
Oct 12, 2021
Merged

Coq inhabited errors #1470

merged 11 commits into from
Oct 12, 2021

Conversation

robdockins
Copy link
Contributor

In the Coq prelude, weaken the previously-unsound error axiom by insisting that it only be applied at inhabited types. This requires some additional machinery to pipe around the necessary facts about types being inhabited.

@robdockins robdockins marked this pull request as ready for review October 6, 2021 16:49
Copy link
Contributor

@eddywestbrook eddywestbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I'm still a little on the fence about this approach overall, because the isort stuff is not checked by the SAW core type-checker, and so there are now SAW core terms that will type-check but really shouldn't. This "shouldn't" only comes out in the translation to Coq, and I'm worried that this could lead to problems down the road. OTOH, it's an interesting idea for how to get around the problem of making error translate to valid Coq without changing our current approaches too much. Also, if we do run into issues, this wasn't that big of a change, and we can always reverse it and try something else. So I feel like this is an experiment, and why not?

can be passed to the `error` axiom.  This makes the axiom realizable.

Add instances for the major types of interest.

This messes up extraction for most of the Cryptol prelude, as the necessary
`Inhabited` instances must be passed along through polymorpic definitions.
…d to be inhabited.

This adds a boolean flag to to the SAWCore AST node for sorts.  For most
purposes (typechecking and such), this annotation is purely advisory
and does not directly affect the SAWCore metatheory.  However, for Coq
export, it is used to identify types arguments to functions that are
required to be inhabited. When appearing in a Pi type, lambda or definition,
such type arguments will be accompanied by an implicit argument
demanding a typeclass instance for the `Inhabited` class.

In concrete SAWCore syntax, this annotaion is attached when using the
new `isort` keyword, which is otherwise identical to `sort`.

This patch only adds the new annotation flag, but does not yet plumb
through the Coq translation changes.
annotation into implicit parameters mentioning the `Inhabited` typeclass.

For example, the vector `at` function is defined as so:

```
at : (n : Nat) -> (a : isort 0) -> Vec n a -> Nat -> a;
at n a v i = atWithDefault n a (error a "at: index out of bounds") v i;
```

It is translated into a Coq term with type:
```
forall (n : Nat) (a : Type) {Inh_a : Inhabited a}, Vec n a -> Nat -> a
```
necessary to propigate inhabited information.  Regenerate the Coq
prelude and ensure that inhabited class instances are avaliable
where necessary.
This declaration is ignored for most purposes, but is intended to
allow the user to directly influence translation passes.  In particular,
we use it here to emit typeclass instance declarations in the Coq translation
for witnessing the inhabitedness of certain types.
and use explicit references for `multiFixM`.
and remove an unused argument to `DefRename`.
@robdockins robdockins added the PR: ready to merge Magic flag for pull requests to ask Mergify to merge given an approval and a successful CI run label Oct 11, 2021
@mergify mergify bot merged commit f46eb02 into master Oct 12, 2021
@mergify mergify bot deleted the coq-inhabited branch October 12, 2021 01:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: ready to merge Magic flag for pull requests to ask Mergify to merge given an approval and a successful CI run
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants