Bug in higher-order matching

[francoisthire]

I am sorry, I don't have time to minimize the example. I am aware of a type checking issue in Lambdapi which is probably related to Higher-Order matching. The error can be found in the Librairies repository. There are two files in play. The first one encodes Cedille's core theory: cedille.dk . The second one encodes a basic example with it: nat.dk.

The first file type checks but not the second in Lambdapi (but it does in Dedukti and Dedukti is right on this one). I know that the error commes from either this rule or this rule which are both Higher-Order rules. One of these rules is not applied while it should.

[gabrielhdt]

So as of commit 4e458b7ec224b3574bda8e7d6fb59d4bbd8b5a2e, the expected behaviour announced by Frederic operates.

Additionally, I've made clearer what I stated above, see here and there. In both lines, one condition translates "check for free variables if some are forbidden", the other part forces the variable check in case of permutation of free variables as shown there.

[rlepigre]

@gabrielhdt What about efficiency in your branch? Have you tested make matita and the likes?

[francoisthire]

@francoisthire my example comes from a simplification of the ho_bug1.dk file (see here) that is used in our unit tests. The problem with this example (under my attempted fix) is essentially the same, so I don't understand why Dedukti would reject the above example and still allow the example in ho_bug1.dk.

I made a mistake in my answer. I thought that f was applied to x in the pattern. Since it is not the case, you need to take into account the second part of my answer, not the first part.

[gabrielhdt]

@rlepigre on verine, performance does not change, but I haven't fixed the issue as you have done, using snf (i.e. my branch is still buggish)

[rlepigre]

@gabrielhdt OK, no worries. I started to give comments on your PR, but I'll do that in several waves. It would be nice to merge it soon, and solve the problems at the same time. I don't want to spend time optimizing the version I fixed, it is probably better to finish the work on decision trees.

[francoisthire]

Is it possible to get a behavior similar to the current one once @gabrielhdt PR will be merged?

[gabrielhdt]

wdym?

[fblanqui]

@gabrielhdt I don't understand why you have to check variable occurrences when there is a permutation. In abstractions.lp there should be no test on variables.

[gabrielhdt]

@fblanqui in fact it is a trivial variable check, but I need to remap the right variables into the term, and this is done by a variable check.

[fblanqui]

I don't understand. If you take f (λx, λy, &F[x,y]) → r, there is nothing to do whatever r is. Idem for f (λx, λy, &F[y,x]) → r. Assume that you try to match λx, λy, t against λx, λy, &F[x,y], then F will be set to λx, λy, t. If you try to match against λx, λy, &F[y,x] then F will be set to λy, λx, t because abstractions are done in the order of the arguments of F. And all this does not depend on r. If r contains F[a,b] then it will be replaced by t{x=a,y=b} in the first case, and t{x=b,y=a} in the second case. But this is taken care by the substitution mechanism.

[gabrielhdt]

I was mistaken, it has nothing to do with permutation. However, during evaluation, I unbind terms using variables created at compile time. In the end, I must gather the free variables introduced and bind them into right hand side. This is currently done by a variable check, which performs a lift to get the variables, and then a bind_mvar. It is possible to do it outside the free variable check though, if you want to separate things.

[fblanqui]

Yes, it would be better to separate the two.

[gabrielhdt]

Commit 2494410c00874b3321ec8652c78ee2cc3c0d0bfd separates the two, and no free var check is done in abstractions.lp.