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

F* (wrongly?) says SMT pattern miss bound variable when using typeclasses #3081

Closed
TWal opened this issue Nov 2, 2023 · 2 comments
Closed

Comments

@TWal
Copy link
Contributor

TWal commented Nov 2, 2023

See the following example. F* complains that the typeclass instance is not captured by the SMT pattern, but the SMT pattern works fine.

assume val t: Type0

class toto = {
  f: t -> t -> t;
  g: t -> t -> t;
  f_lemma: x:t -> y:t -> squash (f x y == g y x);
}

// Lemma that can be proven using f_lemma twice
val test_lemma:
  {|toto|} ->
  x:t -> y:t -> z:t ->
  Lemma
  (f x (f y z) == g (g z y) x)

// It can't be proven automatically
[@@expect_failure]
let test_lemma #toto_instance x y z = ()

// We create a lemma with SMT pattern.
// F* says: Pattern misses at least one bound variable: ...
val f_lemma_smtpat:
  {|toto|} ->
  x:t -> y:t ->
  Lemma (f x y == g y x)
  [SMTPat (f x y)]
let f_lemma_smtpat #toto_instance x y =
  f_lemma x y

// However the SMT pattern works well
let test_lemma #toto_instance x y z = ()

If we write the instance explicitly the error disappear, although I would have thought it is equivalent to the code above?

val f_lemma_smtpat:
  {|toto_instance:toto|} ->
  x:t -> y:t ->
  Lemma (f x y == g y x)
  [SMTPat (f #toto_instance x y)]
let f_lemma_smtpat #toto_instance x y =
  f_lemma x y

What is happening here, is there really something wrong with the first SMT pattern?

mtzguido added a commit to mtzguido/FStar that referenced this issue Nov 6, 2023
@mtzguido
Copy link
Member

mtzguido commented Nov 6, 2023

Thanks for the report Théophile! Pushing a fix for this. What is happening is that F* is checking that all arguments of the lemma are mentioned in the pattern before doing typeclass resolution, and giving a false warning. The pattern is itself fine.

mtzguido added a commit that referenced this issue Nov 6, 2023
@TWal
Copy link
Contributor Author

TWal commented Nov 6, 2023

Great, thanks!

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