Open ghost opened 3 years ago
This appears to be a bug in the llvm backend implementation of substitution. Specifically, what is happening is that when it substitutes y
for & (Z | .Terms)
, it introduces a sort injection from sort N into sort N, which should not exist. This then prevents the next rule from matching. The solution is to fix the implementation of substitution in the LLVM backend to recognize that that injection should be stripped from the output of substitution. That being said, I'm not sure exactly when I will have time to work on this. You may want to consider a workaround. Making the &
production be of sort Ref
and then declaring syntax N ::= Ref
ought to be sufficient to make this issue go away.
K Version
Description
In a pi calculus variant, a quoted process gets substituted for a variable. A subsequent pattern match on a depth-2 context fails.
The particular rules of interest are these: when I encounter a term in the list of terms of the form
*(name)
, I store the name in the<derefs>
section, and when I find a name that is a referenced process (a depth-1 context), I remove the ampersand and put it in thek
cell.The program gets stuck when I use these rules instead: when I encounter a
Deref
in the list of terms (which by construction can only be of the form*(name)
), I store it as-is in the<derefs>
section, and when I find a name that is a dereferenced referenced process (a depth-2 context), I remove both the asterisk and the ampersand and put it in thek
cell.Note that both ways of writing the rules work on lists that are parsed directly as part of the source code. The second pair only seems to fail when the list is the result of a substitution.
Working rho.k file:
Expected Behavior
The variable
P
should bind to the list of terms in the context*(&(P))
.Test programs:
test1.rho
out(x, Z) | in(y <- x.*(y))
Should result in an emptyderefs
cell. In the non-working case, I get<deref> *(&(Z | .Terms)) </deref>
. In the working case, I get an emptyderefs
cell.test2.rho
*(&(Z))
Should result in an emptyderefs
cell. In both the working and non-working cases, it does result in an emptyderefs
cell, suggesting that the problem only manifests when there is a substitution.