Support quantification over the Cryptol # kind

[Isweet]

Example

Suppose we have a Cryptol module Example in Example.cry below and the subsequent SAW script.

module Example where

p : {N} (fin N, N % 2 == 0, 2 <= N, N <= 6) => [N] -> Bit
p w = w == w

import "./Example.cry" as Example;

// Verify a new property, `p`, named `name`, using tactic `t`.
let verify name p t = time do { print (str_concat (str_concat "Verifying " name) "..."); prove_print t (rewrite basic_ss p); };

Example <- verify "example" {{ Example::p }} rme;

The example above will cause SAW to produce an error:

[14:57:36.508] Stack trace:
"verify" (/.../proof.saw:13:12-13:18)
"time" (/.../proof.saw:11:23-11:27)
"prove_print" (/.../proof.saw:11:90-11:101)
"t" (/.../proof.saw:11:102-11:103)
"rme" (/.../proof.saw:13:42-13:45)
sequentToSATQuery: expected first order type or assertion:
Cryptol.Num

As an aside, this error message probably also deserves a SAW issue for usability.

To confirm that this error is due to Example::p being parametric, we can instantiate the type parameter explicitly:

Example <- verify "example" {{ Example::p`{2} }} rme;

In this case, SAW successfully proves the theorem.

Discussion

An example like this is surprising to me because the kind of the type variable in the Cryptol expression is #, which is the numeric kind. I'd sort of expect, at a high level, that quantifying over the numeric should be possible by (say) translating to SMT by introducing a symbolic variable for the type variable, and introducing SMT constraints corresponding to the type constraints (e.g, 2 <= N above). As I write this, it occurs to me that if a Cryptol sequence is encoded as an SMT bitvector then this would mean the SMT solver would need to support variables whose kind is "bitvector of length x" where x is a symbolic Nat. Maybe that's not a thing?

I don't think I have any recommendations for this. It is chiefly a usability issue since the user can always manually instantiate the property with all satisfying numerics. However, it does show up quite a bit in conjunction with #2208, because the mitigation for that is to make every declaration in the module parametric.

[RyanGlScott]

As I write this, it occurs to me that if a Cryptol sequence is encoded as an SMT bitvector then this would mean the SMT solver would need to support variables whose kind is "bitvector of length x" where x is a symbolic Nat. Maybe that's not a thing?

That is not a thing in SMT-LIB as far as I am aware.

[sauclovian-g]

Indeed, that's not a thing. If the range is bounded (as it is in the example) we could always expand it, but I don't think that should happen without someone saying so as it could end up expensive.

[sauclovian-g]

It is also possibly feasible in some cases to prove it for e.g. bits == 3 and generalize the proof to larger bitvectors by rewriting and rechecking the proof itself; however, that's going to take real work 😐

[Isweet]

A quick literature search yielded this paper from the Stanford / CVC5 folks: https://arxiv.org/pdf/1905.10434. It is possibly helpful in encoding symbolic bit-width statements into fixed bit-width.

In any event, I agree 100% that it is not an easy fix.

[sauclovian-g]

Cryptol refuses to let you prove things of this form, right? It'll complain they're polymorphic, IIRC.

We should be able to fix the error message relatively soon; the rest is ... problematic, alas.