Incorrect AST for Stratego concrete syntax (Spoofax 0.6.1)
While bootstrapping strj, I came across some issues in parsing use the latest strategoxt.jar (http://hydra.nixos.org/build/913698). The following files do not give ambiguities using the C version of parse-stratego:
https://svn.strategoxt.org/repos/StrategoXT/strategoxt-java-backend/trunk/trans/variable-access.str
Submitted by Rob Vermaas on 16 February 2011 at 09:11
Issue Log
The build url you indicated seems to succeed?
Probably copied the wrong URL. Just try to parse the mentioned files with JSGLR and parse-stratego.
Ah, the url is probably the strategoxt.jar build I used (look at build inputs tab to see which svn revision it was)
Ah. I don’t suppose you made a Java version of
parse-stratego
yet? The files depend on heuristic filters that are not enabled in the normal jsglr command-line tool… I suppose it needs a command-line option for that. Anyway, I’ll try to look into it when I have some more time.
Well, as it goes wrong during running of stratego java compiler, I would think it is using parse-stratego strategies, and therefore it might be a parse-stratego (in java) bug ?
in strategoxt-java-backend/java/runtime/org/strategoxt/lang/compat/override/jsglr-parser-compat.str there is :
override parse-string-pt(on-parse-error | tbl, start-symbol, path) =
stream -> term
where
read-text-from-stream;
jsglr-parse-string-pt(on-parse-error |tbl, start-symbol, path) => termwhich is used by parse-stratego.
Ah, but there actually is an option for JSGLR to parse with heuristic filters. We need a
--help
option.I tried two files:
$ java -cp java/strategoxt.jar org.spoofax.jsglr.Main –heuristic-filters on -p syn/Stratego-Stratego-Java-15.tbl -i trans/variable-access.str –implode | pp-aterm(…lots of output, no amb…)
$ java -cp java/strategoxt.jar org.spoofax.jsglr.Main –heuristic-filters on -p
locate1 Stratego-Sdf2.tbl
-i java/tools/org/strategoxt/tools/lib/gen-renamed-sdf-module.str –implode | pp-aterm | less(…lots of output, no amb…)
So I can’t seem to reproduce it? Can you reproduce it in this way? Maybe the problem is that the compiler doesn’t properly configure the parser?
I must have messed something up here, indeed there are no amb’s (anymore?). However, if you compare the output of
$ sglri –heuristic-filters on -plocate1 Stratego-Sdf2.tbl
-i java/tools/org/strategoxt/tools/lib/gen-renamed-sdf-module.str | pp-aterm | less
with
$ java -cp java/strategoxt.jar org.spoofax.jsglr.Main –heuristic-filters on -plocate1 Stratego-Sdf2.tbl
-i java/tools/org/strategoxt/tools/lib/gen-renamed-sdf-module.str –implode | pp-aterm | lessyou get the following diff (diff c java):
140c140
< prod(meta-listvar(“A*”), sort(meta-var(“S”)), meta-var(“$”))prod([meta-var("A*")], sort("S"), meta-var("$"))
142c142
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
150,151c150,151
< meta-listvar(“A*”)
< , cf(sort(meta-var(“S”)))[meta-var("A*")] , cf(sort("S"))
155c155
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
162,163c162,163
< meta-listvar(“A*”)
< , lex(sort(meta-var(“S”)))[meta-var("A*")] , lex(sort("S"))
167c167
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
178,179c178,179
< ToTerm(sort(meta-var(“S1”)))
< , ToTerm(symbol(sort(meta-var(“S1”)), sort(meta-var(“S2”))))ToTerm(sort("S1")) , ToTerm(symbol(sort("S1"), sort("S2")))
193c193,195
< , [imports([renamed-module(meta-var(“M1”), renamings(meta-listvar(“ro*”)))])], [imports( [renamed-module(meta-var("M1"), renamings([meta-var("ro*")]))] )]
Rob gave this another try, now with the comparing C-SGLR (left) with JSGLR+implode-asfix:
139,142c139,140
< ToTerm(
< prod(meta-listvar(“A*”), sort(meta-var(“S”)), meta-var(“$”))
< )
< , ToTerm(sort(meta-var(“S”)))ToTerm(prod(meta-listvar("A*"), sort("S"), meta-var("$"))) , ToTerm(sort("S"))
149,153c147
< prod(
< meta-listvar(“A*”)
< , cf(sort(meta-var(“S”)))
< , meta-var(“$”)
< )prod(meta-listvar("A*"), cf(sort("S")), meta-var("$"))
155c149
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
161,165c155
< prod(
< meta-listvar(“A*”)
< , lex(sort(meta-var(“S”)))
< , meta-var(“$”)
< )prod(meta-listvar("A*"), lex(sort("S")), meta-var("$"))
167c157
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
178,179c168,169
< ToTerm(sort(meta-var(“S1”)))
< , ToTerm(symbol(sort(meta-var(“S1”)), sort(meta-var(“S2”))))ToTerm(sort("S1")) , ToTerm(symbol(sort("S1"), sort("S2")))
Notice how the (likely harmless)
meta-listvar
problem is gone now. What remains is a problem that sounds a lot like Spoofax/352.It also seems to be a parser issue then, rather than an imploder issue.
Running the java parse without –implode and with implode-asfix, I get following diff:
139,142c139,140
< ToTerm(
< prod(meta-listvar(“A*”), sort(meta-var(“S”)), meta-var(“$”))
< )
< , ToTerm(sort(meta-var(“S”)))ToTerm(prod(meta-listvar("A*"), sort("S"), meta-var("$"))) , ToTerm(sort("S"))
149,153c147
< prod(
< meta-listvar(“A*”)
< , cf(sort(meta-var(“S”)))
< , meta-var(“$”)
< )prod(meta-listvar("A*"), cf(sort("S")), meta-var("$"))
155c149
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
161,165c155
< prod(
< meta-listvar(“A*”)
< , lex(sort(meta-var(“S”)))
< , meta-var(“$”)
< )prod(meta-listvar("A*"), lex(sort("S")), meta-var("$"))
167c157
< , ToTerm(sort(meta-var(“S”))), ToTerm(sort("S"))
178,179c168,169
< ToTerm(sort(meta-var(“S1”)))
< , ToTerm(symbol(sort(meta-var(“S1”)), sort(meta-var(“S2”))))ToTerm(sort("S1")) , ToTerm(symbol(sort("S1"), sort("S2")))
Log in to post comments