Re: DCG, lists and custom operators...

[Lindsey Spratt]

Sean,
The DCG system is very flexible. It is mostly creating common Prolog clauses 
from DCG clauses using term_expansion. 
foo --> bar, baz.

is expanded to:
foo(A, B) :- bar(A, X), baz(X, B).

In an expansion such as this where no use is made of the list notation in the 
DCG clauses, the DCG transformation makes no assumptions about what kind of 
terms A, B, and X are bound to during evaluation.

With a little care, you can use the DCG syntax to implement state 
transformations, where A, B, and X get bound to some arbitrarily complex term 
to represent the evaluation state. This is a programming technique I use quite 
often.

bar(A, B) :- B is A + 1.
baz(A, B) :- B is A * 2.

?- foo(1, X).
X = 4.

Relying on DCG expansion to handle argument-linking but not for list management 
(as I show above), you have enormous flexibility in how you process the linked 
arguments. You can certainly manage streams in very complex ways.

If you have not yet acquired it, you should buy Richard A. O'Keefe's "Craft of 
Prolog". This is a wonderful source of ideas about and insights into serious 
Prolog programming.

Lindsey Spratt

On Apr 30, 2014, at 1:33 PM, Sean Charles <address@hidden> wrote:

> A while ago I started writing an HTTP library and I have been trying to 
> decide how to write it. Let me explain…
> 
> If I wanted to use DCG notation then, as far as I understand the mechanics of 
> gprolog, I would need the complete list in its entirety to begin with which 
> means that I would need to keep on reading bytes from the socket connection 
> until …. when? I couldn’t assume that a socket close would indicate the end 
> of the request in case ‘keep-alive’ had been sent in the header!
> 
> The implication is that I would therefore have to write a parser that fetched 
> one character at a time and using the usual methods (FSM-s etc) gradually 
> work its way through the stream examining each part of the request as it was 
> received and then taking the appropriate action. That is also not a problem, 
> I have already written such a parser for a computer language I developed a 
> while back which parses S-expression syntax into a list of terms so that is 
> not a problem either should I choose to go down that route.
> 
> Is there scope within the “[]” operator to extend it to consume data from a 
> stream ?
> 
> Tonight I will do some research on this but is it even possible withing GNU 
> Prolog, I don’t know yet?!?!?!
> 
> What I would like to try to achieve is some sort of system whereby a modified 
> DCG translation system would “fault” on having the empty list and before 
> continuing, attempt to read another character from the stream, and only truly 
> “be” the empty list of the EOF has been reached. I think that this also 
> raises issues though because this would have to be buried from the actual 
> point of trying to unify the DCG head if you see what I mean.
> 
> Sometimes being igorant is hard work!
> 
> 
> Thanks in advanc elist for any useful feedback.
> 
> 
> 
> 
> _______________________________________________
> Users-prolog mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/users-prolog