When `:set mono-binds=on`, any local definitions lacking type
signatures will not be generalized (i.e., will be monomorphic). This
reduces what is in most cases unnecessary polymorphism that can give
rise to constraints that are difficult to solve. This also improves
the performance of the Cryptol interpreter by lifting many polymorphic
type applications out of the inner loops that are commonly defined as
bindings in `where` clauses.
The flag is on by default in the Cryptol REPL, and in most cases makes
it possible to leave out more type signatures in `where` clauses than
before. However, some programs really do rely on inferring polymorphic
types for local variables; in this case adding an explicit polymorphic
type signature to the local binding in question will make the program
typecheck.
The Smtlib solver was translating Fin constraints to True, as it didn't know
how to handle them. They should have been skipped, and returned back as
unsolved goals instead.
Due to the limitations of the GHC runtime, we can't get around the
possibility of out-of-memory errors, but we can prevent individual
bitvectors from being too large for the libgmp-backed bignums.
There is now an architecture-dependent check whenever creating a new
`BV` value in the concrete evaluator to ensure the width does not
exceed the GMP limits. If a width is too large, the evaluation returns
to the REPL much like diving by zero.
To mark a failing test as a known failure, you should add a file with
a name like this:
TESTNAME.icry.fails
When the test runs, if it fails, then the contents of this file is displayed.
It is a probably a good idea for the contents to reference the ticket where
the failure was reported.
When the problem is fixed, the `.fails` should be removed. Failing to do
so will result in test failure (i.e., a test that passes but has a `.fails`
file is considered an error).
See #66 for more discussion. Basically we don't want the type of `it` to be different for unsat or sat results, so we put undefined values in there instead. Also, instead of using tuples and different field names to distinguish formula arguments of various arities, we use a convention of fields `arg1`, `arg2`, ...
Per @weaversa's suggestions in #66, we now bind records to `it` for sat results, leading to less ambiguity about the meaning of those results. There is still some weirdness to this; the fields present in the record change based on the result and the arity of the formula, but this seems like a reasonable approach given that it's not an expression that needs a type.
Similar to what @weaversa requested in #66, we bind `it` to `False`
when we can't find a sat assignment, and `it` to `True` when we've
proved a theorem.
Also adds some simple tests for the sat/prove result binding, and let
binding at the repl.
This test works as of revision db08bfafa9.
Versions of SBV prior to 3.1 did not distinguish the boolean type from
the size-1 bitvector type; this example uses literals like "0b0" and
"0b1", so it triggered the SBV bug, which manifested as a type error from
the external SMT solver.
