Assume you have a HybridInterpreter intp, with a term factory of type WrappedAstNodeFactory fact. If you create a term t using fact.parseFromString("...."), set it to the current term, intp.setCurrent(t), it’s not possible to match on it inside the Stratego program executed by intp.

One of two things will happen

1) Match fails even though the term build inside the interpreter, e.g. Type("Decimal", [], [])" matches exactly the string used to build the term via #parseFromString.
2) A bottomless recursion through BasicStrategoTerm#doSlowMatch() will be seen.

Admittedly, this might be a fringe case, but I find myself in the need for building terms in Java and passing them to the interpreter. For now I just hacked up a tiny API in my program that I invoke() to get what I want.

Submitted by Karl Trygve Kalleberg on 15 April 2010 at 12:24

On 15 April 2010 at 13:21 Lennart Kats commented:

I’m not sure why this would happen. What does your workaround do to get this to work?

Which version are you using? 0.4.3.4 may have some fixes related to hashCode() implementations of terms.

Also, could you post a stack trace with the bottomless recursion? Which doSlowMatch() implementation would be causing the loop?


On 22 April 2010 at 13:35 Karl Trygve Kalleberg commented:

I’ve only managed to get an incomplete stack trace so far. This is with 0.4.3.4.

java.lang.StackOverflowError
	at org.spoofax.interpreter.terms.BasicStrategoList.isEmpty(BasicStrategoList.java:39)
	at org.spoofax.interpreter.terms.BasicStrategoList.getSubtermCount(BasicStrategoList.java:82)
	at org.spoofax.interpreter.terms.BasicStrategoList.size(BasicStrategoList.java:70)
	at org.spoofax.interpreter.terms.BasicStrategoList.doSlowMatch(BasicStrategoList.java:97)
	at org.spoofax.interpreter.terms.BasicStrategoTerm.match(BasicStrategoTerm.java:23)
	at org.spoofax.interpreter.terms.BasicStrategoList.doSlowMatch(BasicStrategoList.java:99)
	at org.spoofax.interpreter.terms.BasicStrategoTerm.match(BasicStrategoTerm.java:23)
	at org.spoofax.interpreter.terms.BasicStrategoList.doSlowMatch(BasicStrategoList.java:99)
	at org.spoofax.interpreter.terms.BasicStrategoTerm.match(BasicStrategoTerm.java:23)
	at org.spoofax.interpreter.terms.BasicStrategoList.doSlowMatch(BasicStrategoList.java:99)
	.... goes on forever, alternating like this ....

My workaround is to build the term entirely inside the interpreter, by calling custom strategies. I set the current term to a String or an int, call a specific strategy to build a specific application term around the String/int, and save it for later on the Java side by reading interp.current()


On 22 April 2010 at 14:59 Lennart Kats commented:

@Karl:

If you run Java with -XX:MaxJavaStackTraceDepth=<some big number, default is 1024> you may get a complete stack trace.

Other than that, the BasicStrategoList is fishy. That should really be a StrategoList, part of the revised StrategoFactory implementation. There might be some incompatibilities between the two implementations that trigger this loop (although I’m not aware of any, other than different hashcodes, which on its own already breaks things like dynamic rules). So maybe you could find out where this BasicStrategoList is created?


On 26 April 2010 at 11:31 Lennart Kats commented:

Apparently this issue was caused by using the (BAF)BasicTermFactory. The factory works, but can’t cooperate with the TermFactory-based WrappedAstNodeFactory. I’m somewhat torn wontfix and notabug here, but I guess I’ll just close the issue either way :)

Log in to post comments