sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

Problem parsing comments in the middle of productions #94

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. source mapping-bot.soar in 
soar2d/agents/tanksoar/tutorial/mapping-bot/elaborations/monitor.soar

What is the expected output? What do you see instead?

Expected: the rules to be loaded properly
Actual:

Error: Expected ( to begin RHS action

^
(Ignoring production all*monitor*impasse*state-no-change)

Production addition failed.
/Users/justinnhli/Desktop/SoarSuite-9.3.1-osx-x86_64/soar2d/agents/tanksoar/tuto
rial/mapping-bot/elaborations/monitor.soar:3
Total: 0 productions sourced.

Original issue reported on code.google.com by justinn...@gmail.com on 13 Sep 2011 at 8:02

GoogleCodeExporter commented 8 years ago
Simpler test case:

sp {rule1
    (state <s> ^superstate nil)
-->
#   (<s> ^arst 1)}
}

If commented out close brace is removed, the rule sources successfully.

Original comment by joseph...@gmail.com on 13 Sep 2011 at 8:33

GoogleCodeExporter commented 8 years ago
Note that, for tcl compatibility, comments are treated as no-op commands, and 
thus parens must match in them.

See:

http://wiki.tcl.tk/1669

Note that tcl compatibility is very important for SoarTech.

Original comment by marin...@gmail.com on 13 Sep 2011 at 8:35

GoogleCodeExporter commented 8 years ago
This is expected behavior. It is required for tcl compatibility.

Original comment by marin...@gmail.com on 13 Sep 2011 at 8:37

GoogleCodeExporter commented 8 years ago
I understand that the # inside the rule body should be treated as a literal 
character and the first } should still close the body of the rule. That's fine. 
But that still doesn't explain why a rule like 

sp {rule 
(state <s> ^a 1) 
-->
#(<s> ^b 1)}

doesn't parse correctly. What I'd expect is that the CLI parser will take 'rule 
(state <s> ^a 1) --> # (<s> ^b 1)' (ignoring some whitespace) to be the first 
argument to sp and hence the rule body, and then for the kernel rule parser to 
strip out everything from the hash to the end, resulting in a valid rule with 
an empty RHS. Currently sourcing this rule results in an "Expected ( to begin 
RHS action" error.

Original comment by joseph...@gmail.com on 13 Sep 2011 at 9:59

GoogleCodeExporter commented 8 years ago
As Bob said, this is expected behavior.

Joseph: please move the parser bug into a new issue.

Original comment by justinn...@gmail.com on 13 Sep 2011 at 10:02