Specifications can be terser through more type trickery #456
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I was writing an STM specification for Dynarrays, I was a bit frustrated to have to add a catch-all
assert false
at the end ofpostcond
. So I went into an over-engineering rabbit hole and found that it can be avoided by making thecmd
type of specifications a GADT, which allows to specify the result type for commands. The typechecker is then able to deduce the result type when pattern matching on commands.As an example, I have rewritten
src/atomic/stm_tests.ml
to match the newSpec
signature.This has a number of benefits and some drawbacks.
Benefits
run
function, results no longer need to be wrappend into theRes
constructor. However, it is still necessary to also return an instance of'a ty_show
; I have not found a simpler way to make the results printable.postcond
function, it is no longer necessary to match on patterns likeRes ((Result (Int, Exn), _), v)
for the typechecker to deduce the right type forv
: the command name suffices. It is also no longer necessary to add a catch-all_ -> assert false
at the end.run
are safer because the result type is checked.Drawbacks
Defining a GADT in the specification adds its own boilerplate: most functions now need explicit type annotations with universal quantifiers; the user must also define an existential type
packed_cmd
and wrap the command generators in it. Such STM tests are harder to write when one is not familiar with qcheck-stm.And of course, another big drawback is that it changes the signature of STM specifications.
For these reasons, I open this PR as a draft, mostly to share the idea.