Prolog - DCG parser with input from file

Question

As part of a project I need to write a parser that can read a file and parse into facts I can use in my program.

The file structure looks as follows:

p         


        

Answer 1

as long as your file is in plain Prolog syntax, you're advised to use Prolog term IO. Fully structured terms are read with a single call. Using a DCG its' way more complicate, and a bit less efficient (not sure here, should measure, but read(Term) invokes a Prolog parser implemented in C...) See this other question, that uses the very same format (at least, you could check if some other guy got an answer here on SO about your same assignment...)

edit after comments...

You're right that DCG are the right way to handle general parse in Prolog. Arguments in DCG productions can be seen as semantic attributes, thus programming DCG can be seen as providing a working semantic analysis on the input (see Attribute Grammar, an important technique -also- in language engineering).

And indeed the presented examples can perfectly well be solved without the hacks required with term IO.

Here it is:

:- use_module(library(pio)).  % autoload(ed), added just for easy browsing
:- use_module(library(dcg/basics)).

property(P) -->
    b, "my props", b, "=", b, "{", elS(Es) , b, "}", b,
    { P =.. [property|Es] }.

elS([E|Es]) --> el(E), b, ("," -> elS(Es) ; {Es = []}).
el(N) --> number(N).
el(S) --> csym(S). % after Jeremy Knees comment...
b --> blanks.

%   parse a C symbol
csym(S) -->
    [F], { code_type(F, csymf) },
    csym1(Cs),
    !, { atom_codes(S, [F|Cs]) }.

csym1([C|Cs]) -->
    [C], { code_type(C, csym) },
    csym1(Cs).
csym1([]) --> [].

with that, we have

?- phrase(property(P), "my props = {1,2,3}").
P = property(1, 2, 3).

Thanks to library(pureio) we can apply semantic programming to Prolog streams, and be rewarded of the same behaviour of phrase/2.

more

This other answer show a practical way to implement an expression calculator with operator resolution, and lazy evaluation.

Answer 2

I parse the string into a list and then manipulate the list. Using DCG you can convert

T = (saf>{saf, as13s}>a32s>asf).

to

S = [saf-0, saf-1, as13s-1, a32s-2, asf-3] .

Note to do:

1. parseLine(<<Yourpattern>>,Position) --> parseLine(L,Position), parseLine(R,NewPosition)
2. parseLine(Item,Pos) --> [Item-Pos].

Here you have 2 patterns to handle those are the (L>R) and the {L,R}. That won't be much complicated and really easy to read.

Answer 3

Well, the purpose of a homework question is to learn. Doing it with a DCG will teach you a more generally useful skill than horsing operators about.

I think your issues are less with DCG's inherently than with string handling.

You have a bunch of places where you use univ (the =.. operator) to convert between lists and strings. Univ probably is NOT what you want here. Univ unifies a term with a list.

foo(bar, baz)  =..  [foo, bar, baz]

What you need to understand is that a string in Prolog can be in several different forms The string 'hi Flores' could be

'hi Flores' - this is an atom - a 'solid chunk' of thing. The single quotes aren't needed for some character sequences (see your book), so hi_flores is a perfectly good atom without single quotes.

[104,105,32,70,108,111,114,101,115] - a list of ASCII codes.  This is likely what you want. These can be written with double quotes, "hi Floris"  in prolog code.

To save your sanity, put

:- portray_text(true).  

in your file so it prints out "hi Floris" in debug, not a bunch of numbers.

There's also a list of one character atoms

[h, i, ' ', 'F', l, o, r, i, s]

but you probably don't want those.

You might find the SICSTUS compatability pred read_line useful.

Now, in a DCG, you sometimes want to match 'literals' - literally that thing. If so, put that in a list. Here's a DCG for if statements in some vaguely VBish language

if_statement  --> "if", wh, "(", condition, ")", wh, 
                  "then", wh, body, wh, "else", wh,
                  else_body, wh, "endif".

% whitespace
wh -->  [].
wh -->  " ", wh.
wh --> [10], wh.   % handle newline and cr
wh --> [12], wh.

the wh's everywhere are optional whitespace.

Now, for overall strategy, you can either read in one line at a time, or read in the whole file. For one line, use read_line, which returns a list of codes. read_file_to_codes will get the whole file.

If you use the whole file strategy, and newlines are significant, you'll need to remove them from the definition of whitespace, obviously.

And, of course, all this leads to the question why questions about this problem are flooding SO instead of the instructor's in box.

Answer 4

IMHO, DCG grammar rules are quite ugly at tokenizing, I really thing DCG should have never been even proposed for that task; the real deal with DCG is to parse the tokens, because prolog uses symbolics, so I may say that, the best option is to create a foreign call to a, say C tokenizer which will unify with the plain list of tokens and then let DCG do what it has been though for. This way the implementation is cleaner and you don't have to worry about parsing cr, blanks...

Say you have an hypothetical language which has an statement that looks as follows:

object:
       object in a yields b,
       object in b yields C.

I don't want to even imagine in tokenizing this in DCG; I am too lazy to learn how to do so with a tool which have not being designed for such a task. Better would be to have a foreign call to a predicate that will provide me with the plain list of tokens.

 tokenize(A,ListOfTokens), phrase(yourDGCstartRule(Information), ListOfTokens, _).

The list for our running example will look simply as:

ListOfTokens = [object,:,object,in,a,yields,b,',',object,in,b,yields,c].

I think this is way much more elegant and your rules maps accordingly. I could be wrong in my thoughs but at the end it's a matter of taste, and to mine, DCG is not a tokenizer and I would never use it for that unless is strictly required. Admitedly I can spot some applications where it would make sense to use it also as tokenizer but still I think the tasks should be separated.

Please notice that I am NOT saying that prolog doesn't have good facilities, you could always do tokenizing in prolog but you should separate the tasks and let DCG deal only with symbols and some other stricly needed characters or strings (as Uppercase strings, like proper names or other characters).

Finally it seems to me that people might has forgotten that tokenizing and parsing are two separated tasks; more in prolog, since tokens are symbols which is what prolog is good at, and parsing tokens/symbols (not characters) what DCG does better, for as embeeded semantics interfaces prolog which is the desirable scenario.