Open JoeyEremondi opened 6 years ago
So, after some debugging/tracing, the source of the problem is at this line
The result of nt_or_mv_of_systerms
looks like this:
(( X[0], None), (n) )
(( tau[0], None), (n) )
(( tau[0], (tau,)), (n) )
The same term (tau) appears in the list twice, but with different data for the subntr_data
, causing some stage of the process to see them as different terms. This explains why it only happens with the subterm relationship, but I don't (yet) understand subntr_data
well enough to know where the problem is originating.
I'll keep investigating, but hopefully this info is helpful to someone who knows Ott internals better than I do.
Just to further add info, I've now found that the problem is that in [ </ Xn |-> taun // n /> ]
, tau
is parsed into a St_nonterm
instead of St_nontermsub
. This happens regardless of whether dot or comprehension list forms are used.
On 12 February 2018 at 01:48, Joey Eremondi notifications@github.com wrote:
Just to further add info, I've now found that the problem is that in [ </ Xn |-> taun // n /> ], tau is parsed into a St_nonterm instead of St_nontermsub. This happens regardless of whether dot or comprehension list forms are used.
I've no time right now to really look into this, sorry. But it looks to me as if that is a correct parse wrt the grammar - the T_tsub production has taus not their super-nonterminal. That suggests there might be a bug in the bounds analysis code, failing to coalesce nonterminals that are used in multiple subrule ways like this.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ott-lang/ott/issues/26#issuecomment-364812155, or mute the thread https://github.com/notifications/unsubscribe-auth/AErM5qwhhcdS_--dae5fwmvgcWqKE3-Kks5tT5hTgaJpZM4R78To .
Here's a minimal example displaying the problem:
The InstL rule generates pretty bizarre Coq output. It quantifies over a list of type
(var*typexpr*typexpr)
, when it should quantify over(var*typexpr)
.Additionally, the pattern matching functions use matches of the form
(X_,tau_,tau_)
, which Coq errors on due to the repeated variable names.The problem goes away when I remove
tau
as a subrule fortypexpr
and just maketau
andtypexpr
synonyms, so it must be related to the subrule construct somehow. Similarly, the problem goes away if I remove the premise of the InstL rule. It's like the compiler can't figure out that the tau1...taun in the premise are the same as in the conclusion.Here's the raw Coq output: