Previously, checking the type of e.g. "(&&) `{[2]b}" would not return
"(Logic [2]b) => [2]b -> [2]b -> [2]b" as expected, but
"Logic b => [2]b -> [2]b -> [2]b". This made it impossible to reconstruct
the instances necessary to produce the required Logic dictionary when
translating to saw-core.
Regression test check31 was failing somewhat unpredictably due to the
use of lazy I/O when loading the Z3 prelude for the type checker. Using
the `strict` package seems to fix it.
This commit reorganizes how lexicographic comparisons are done in
the concrete simulator to reuse the same combinator from the symbolic
simulator. This makes it more straightforward to implement the new
signed comparison.
This class will represent types that can be meaningfully compared for
signed bitvector equality. It lifts the comparison operations on
nonempty bitvectors through tuples, records and finite sequences via
lexicographic order.
However, see the following SBV issue that currently affects
Cryptol behavior when computing signed right shifts with
symbolic index amounts:
https://github.com/LeventErkok/sbv/issues/323
It appears to have negligable or negative performance advantages over
the representation on sequence maps. Deleting the additional representation
removes a lot of code paths, and makes things somewhat simpler.
When bitsequences cannot be packed as words, they have been
represented using an explicit sequence datastructure containing
thunks for the individual bits. However, for finite, but very large,
bitsequences this was consuming unacceptable amounts of memory.
When bitvector lengths cross an arbitrarily-designated threshold
(currently 2^16 bits) we instead use a sparse representation based
on SeqMap, similar to the representation used for other finite and
infinite sequence types.
This patch does not add a warning when using 'random' in symbolic expressions.
We currently don't have any organized mechanism for generating warnings during
evaluation, and the value of emitting such a warning is debatable.
Fixes#364
