Python str() output of certain clingo AST modules does not match valid Gringo input format

[madingess]

My use case is to parse a program with the python Clingo module using clingo.parse_program(). Then, using the abstract syntax tree returned by the parser, I make observations on the program and possibly perform transformations to specific rules within the program. Finally, the result is output to file using the python 2.7 str() function on each rule of the (possibly transformed) program.

The problem is observed regardless of whether I make transformations to the program. Even if the program makes no transformations, I may still find that the output file contains syntax which is not valid as input to Gringo or Clingo.

For example, with pools, the following code

import clingo

inputFile = "q(1;2;3)."
program_rules = []

clingo.parse_program(inputFile, lambda rule: program_rules.append(rule))

for rule in program_rules:

print "%s" % str(rule)

will reliably output

#program base.
(q(1);q(2);q(3)).

The #program base. statement is valid Gringo input; however, the output of the pool statement (q(1);q(2);q(3)). is not valid input.

Similarly, with head disjunction. If we instead use

inputFile = "q(1) | q(2)."

we reliably see the output

#program base.
q(2) : ; q(1) : .

Again, the second line is not valid Gringo input. I suspect a similar outcome with body disjoints.

These could be handled manually, by checking whether the rule uses pools or disjoints, and outputting an appropriate Gringo syntax form. But is there perhaps a built-in output method of which I am not aware? Or some better way of handling the issue?

Thank you in advance.

[rkaminsk]

The string representation of the AST has been written with the idea to ease debugging not returning a parsable format. The AST for a statement is meant to be passed to a ProgramBuilder object.

At the moment the AST implementation is still marked as experimental. So far I did not have the time to give it the attention it needs. Unfortunately, I also won't have the time anytime soon because improving its implementation is actually a huge time sink.

I could address your two issues for the next release but I do not give any guarantees that the string representation of any AST can be parsed again.

[rkaminsk]

I addressed your two issues. I have not checked thoroughly if every AST can be parsed again. If you find more cases, feel free to open a new issue.