Closed Mbodin closed 4 years ago
Rather than the wildcard, it seems the trouble comes from inferring the event type D
for the "mutually recursive" events. Maybe it should be annotated explicitly? That would avoid the let
trick...
I agree that annotating D
explicitly in the notation feels like a good idea. It may also prevent the in odd_evenE T return itree (odd_evenE +' void1) T
pattern-matching annotation.
I also think that it would be worth instantiating the mrec-fix
notation for some specific numbers of mutually recursive functions. rec-fix
is already an instance for one function, using the callE
construct. I think that it would also make sense to define a rec-fix f x := f_body with g y := g_body
notation, based on a call2E
or something like that: defining two function mutually recursive is a very common use-case. What do you think?
That sounds great! I'm definitely in favor of all of that. I would welcome a PR for it :)
I find the current definition of
mrec_fix
quite surprising: https://github.com/DeepSpec/InteractionTrees/blob/master/theories/Interp/Recursion.v#L103 It has two parametersA
andB
that are unused. Furthermore the notationmrec-fix
defined below is putting a wildcard for the typeT
, which is typically needed for mutually recursive definitions.Here is a proof script to illustrate my point.
The definition
odd_even_1
is made usingmrec
and works. Note the importance of using the argumentT
(which why I was so surprised to find a wildcard inmrec-fix
).The natural definition
odd_even_2
is failing because of the wildcard. The definitionodd_even_3
suggests a fix.