Prolog - DCG parser with input from file
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.
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.
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.