The width table in CryptolTC.z3 wasn't large enough to solve constraints
about the width of 64-bit words. This change is a bit of a band-aid, as
larger words will expose the same problem. Longer-term, we should try to
solve these constraints after the SMT-based phase, using some other
approach.
The constraints in CryptoBox were too permissive, and when adjusted to
represent the true intent (that values fit within 64-bits), and the
width table was updated, the example will type-check again.
Thanks to @tommd for tracking both of these down.
vectors at indices starting from the beginning/end of the vector,
respectively.
Included in this patch are implementations of these primitives
for the concrete evaluator. Symbolic primitives are TODO.
Fix some minor conflicts in the test suite.
Conflicts:
tests/issues/issue002.icry.fails
tests/issues/issue148.icry.stdout
tests/issues/issue198.icry.stdout
tests/issues/issue214.icry.stdout
tests/issues/issue290v2.icry.stdout
tests/issues/issue312.icry.fails
To get acceptable performance, we need to be pretty aggressive about
using word representations instead of list-of-bits. Unfortunately,
with the new evaluator, this means we force things to be more strict
than is correct.
We are also still slower than the current evaluator. It is not
clear where the problems are.
The definitions added in #299 cause a regression in Prelude typechecking
performance. Until we sort out the performance, we'll keep these
definitions in the module `Cryptol::Extras`.
The `random` primitive previously took a `[32]` seed, but this causes
inconsistency between 32-bit and 64-bit platforms when the seed is large
enough to wrap around in GHC's representation of an `Int`. This patch
switches to an API that seeds directly with four 64-bit words, and so
should behave the same way on our supported platforms.
Implication (==>), not, and, or, all, any, map, foldl, sum, scanl, extend,
extendSigned, foldr, scanr, zip, zipWith, repeat, curry, uncurry, and elem.
Rationale:
I've had to implement these functions several times for different problems.
While my problems were admittedly toy, not cryptographic, the functions are
generally applicable and unlikely to clash with many, if any, preexisting
operations of different semantic meaning.
