I have a helper strategy that wraps parent-at-position to give me the first parent for which a strategy succeeds:

parent-at-position-matching(ma|position) =
?ast;
<repeat-until(split-init-last ; Fst , \ p -> <parent-at-position(|p)> ast \ ; ma)> position

At some place i call it this way (as part of a refactoring):

<parent-at-position-matching(?source@Automated(tests)|position)> ast;

Everything works as expected until i change the build.main.xml file to build a jar file instead of ctree:

and set it in the -Builders.esv file accordingly:

// provider : include/gradingslang.ctree
provider : include/gradingslang.jar

These are the only changes i make in the project. After rebuilding the project the parent-at-position-matching application fails, stack trace:

rewriting failed, trace:
inline_refactor_0_0
inline_refactor_0_0
parent_at_position_matching_1_1
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
repeat_until_2_0
split_init_last_0_0
at_last_1_0

Submitted by Vlad Vergu on 18 November 2011 at 17:53

It’s hard to say what’s causing this. If there is a difference in semantics between the compiler and interpreter, odds are that the compiler is right, though. That ?source@Automated(tests) expression looks a bit suspicious. Which variables are unbound? Is tests unbound? AFAIK, it would then be bound after the first match, even if source didn’t match. If there is any semantic difference, I think this would be the spot.

Looks like the same issue as https://yellowgrass.org/issue/Spoofax/326.

TL;DR: in the interpreter source is only bound if the term matches ?Automated(tests), while in the compiler, source is bound regardless of whether ?Automated(tests) matches or not. So at the first invokation it is bound, and any later invokation fails because it is bound already and doesn’t match the current term.

Change to ?Automated(tests); ?source to fix.

I agree the matching expression looks suspicious, changing to:

<parent-at-position-matching(?Automated(tests);?source|position)> ast;

works around. The difference is a pity though. I kind-of prefer the match-then-bind approach as it’s usage is intuitively the same as binding in rewrite rules. If you look at the desugared AST:

Match(
As(
Var(“source”)
, NoAnnoList(Op(“Automated”, [Var(“tests”)]))
)

It says that you first match-then-bind.

Maybe for now we should add a warning:

// notification of Spoofax/326
constraint-warning:
CallT(, sargs, ) -> msgs
where
collect(?Match(As(,)));
map(
ma@Match(As(var,match)) -> (ma, $[
Match may exhibit inconsistent behavior.
Consider rewriting to: [
Seq(Match(match),Match(var))].
See https://yellowgrass.org/issue/StrategoXT/848])
) => msgs

Duplicate of Spoofax/326.