Closed pigworker closed 3 years ago
At the moment, when I check subproofs, I validate them first, then I check which subgoals they cover. That is, I don't match subgoals to subproofs until after I've validated the subproofs. For subdefinitions I won't get away with that. I'll need some sort of superficial matching to identify which subdefinition addresses which subgoal. Fortunately, constructors show up helpfully, so that should be enough of a clue.
This is now beginning to work. But induction
is now spelled inductively
. And there's no sign of sizes.
We also have
test S (S Z) + S (S Z)
yielding
tested S (S Z) + S (S Z) = S (S (S (S Z)))
We're not out of the woods yet, but I think I'll close this issue and open another in the morning. Some careful rationalisation and refactoring is on the cards.
I have added
data
declarations in the style of classic Haskell. (Perhaps there should be GADTs, but...later.)In a slight liberalisation of the Haskell syntax, a binding may be a variable x but
(
x::
type)
is also acceptable. And (you guessed it) a placeholder may be a type but(
x::
type)
is also acceptable. The difference is that the bindings scope over all the constructor declarations.I have not yet implemented a (strict) positivity check: that will prove important in due course. Moreover, it is good to detect which parameters are co-, contra- and equi-variant. (Ask me about functoriality another time.)
I am now planning how programming will look.
Type signatures will be compulsory for all definitions. They also are more liberal, in that
will all be ok and mean the same thing. If there is no definition,
ask
should insert one, by default as fully applied as in the type signature. If argument names are not supplied, there will doubtless be a ghastly heuristic. The user is free to change names and appliedness. So, for example, the above would yield (respectively)At this point, I propose three methods one may deploy:
The
induction
MethodYou say
induction
and then a nonempty list of variables inhabiting inductive data types.and you get given a thing with the same name as the thing you are defining whose type signature follows the original style, but where the types of the induction variables are marked
Wee
(bikeshed!). Behind the scenes, we have acquired a fresh Skolem constanti ∈ Size
and a hypothesiswhere
Size
is an abstract type, andSized
T i n is a type ifType
∋ T,Size
∋ i andDug
∋ n.Dug
is an internal copy ofNat
which counts how far we have dug into a thing. I don't intendSized
,Size
andDug
to be exposed to the user:Sized
T i (S
n) isWee
T andSized
T iZ
isBig
T. Guess what? The goal is now reallyWe have subtyping:
Sized
T i m ≤ T.Sized
T i m ≤Sized
T i n if n ≤ m. That is, we can forget smallness.The
from
MethodWe're now ready to use
from
to invert the construction of a pattern variable of inductive type.Now, when the
from
variable (and it must be a variable) has aSized
type, the exposed inductive substructures are one step moreDug
. At this point, we're good to finish off.The
=
MethodWe're done.
You may give the output by writing
=
and a term of the right type. If you accidentally write a variable that is out of scope,ask
will respond by inserting awhere
clause. We could sayand we'd be
ask
edAnyhow, that's my sketch of what and how.