Logic Programming and the Internet: Difference between revisions

From This Prolog Life
Jump to navigation Jump to search
No edit summary
(3 intermediate revisions by the same user not shown)
Line 8: Line 8:
== HTTP ==
== HTTP ==


Consider that Prolog's default behaviour is query-solving - where a query is posed for which arbitrarily many answers (solutions) may be returned.
Consider that Prolog's default behaviour is query-solving – where a query is posed for which arbitrarily many answers (solutions) may be returned.


This can be mapped to HTTP's request/response mechanism straightforwardly:
This can be mapped to HTTP's request/response mechanism straightforwardly:
Line 14: Line 14:
=== HTTP GET ===
=== HTTP GET ===


The HTTP GET verb has a clear correspondence with Prolog's notion of a query. In fact, Prolog can be used directly as part of a request-URI, acting as a lightweight data structuring mechanism.
The HTTP GET verb has a clear correspondence with Prolog's notion of a query. In fact, Prolog can be used directly as part of a request URI, acting as a lightweight data structuring mechanism.


However, HTTP requires each request/response to be deterministic, which suggests that ''all'' the solutions for a non-deterministic query should be returned. The solutions can be formatted as an XHTML list or table, for example.
However, HTTP requires each request/response to be deterministic, which suggests that ''all'' the solutions for a non-deterministic query should be returned. The solutions can be formatted as an XHTML list or table, for example.
Line 20: Line 20:
=== Caching ===
=== Caching ===


Prolog programming allows for the 'caching' of expensive results using "lemmas", a technique used in the solution of the [[Mister X#Lemmas|Mister X]] puzzle, for example.
Prolog programming allows for the 'caching' of expensive results using lemmas, a technique used in the solution of the [[Mister X#Lemmas|Mister X]] puzzle, for example.


HTTP's 'HEAD' verb, (and GET with "If-Modified-Since") support caching mechanisms, primarily to save communications bandwidth.
HTTP's 'HEAD' verb and GET with “If-Modified-Since” support caching mechanisms, primarily to save communications bandwidth.


The integration of Prolog "lemmas" with HTTP's caching methods can save both bandwidth and recomputation through a single mechanism, enabling the creation of robust distributed applications with a minimum of fuss.
The integration of Prolog lemmas with HTTP's caching methods can save both bandwidth and recomputation through a single mechanism, enabling the creation of robust distributed applications with a minimum of fuss.


=== HTTP POST ===
=== HTTP POST ===


When using Prolog with HTTP, the POST verb should be reserved for passing ''clauses'' from the client to the server, to update the server, not for queries.
When using Prolog with HTTP, the POST verb should be reserved for passing clauses from the client to the server, to update the server, not for queries.


The fact that Prolog is a good format for including structured (composite) data items as part of a URI can obviate some inappropriate uses of HTTP's POST verb, by allowing more complex terms in GET requests.
The fact that Prolog is a good format for including structured (composite) data items as part of a URI can obviate some inappropriate uses of HTTP's POST verb, by allowing more complex terms in GET requests.
Line 40: Line 40:
XML data is represented easily in Prolog, and vice versa, because both use tree-structured data exclusively.
XML data is represented easily in Prolog, and vice versa, because both use tree-structured data exclusively.


Because Prolog is a very high-level language, it is more flexible and more powerful than [http://www.w3.org/TR/xslt XSLT]. In particular, it seems to be very much easier to create robust, reliable transformations with Prolog, i.e. ones that produce only valid output for any valid input.
Because Prolog is a very high-level language, it is more flexible and more powerful than [https://www.w3.org/TR/xslt/all/ XSLT]. In particular, it seems to be very much easier to create robust and reliable transformations with Prolog, i.e. ones that produce only valid output for any valid input.


===xml.pl===
===xml.pl===
Line 48: Line 48:
==PiLLoW==
==PiLLoW==


The [http://clip.dia.fi.upm.es/miscdocs/pillow/pillow.html PiLLoW] library provides predicates for developing HTTP client and server applications.
The [http://cliplab.org/miscdocs/pillow/pillow.html PiLLoW] library provides predicates for developing HTTP client and server applications.


For client applications, it provides mechanisms to retrieve HTML files and to parse HTML into useful Prolog terms.
For client applications, it provides mechanisms to retrieve HTML files and to parse HTML into useful Prolog terms.

Revision as of 17:38, 15 May 2018

Prolog for the Worldwide Web

For a Prolog programmer, to suggest that Prolog is an ideal language for web-based applications is to invite the comment that, “if you have only a hammer, everything looks like a nail”.

However, the correspondences between Prolog behaviour and HTTP, and Prolog data-structures and XML are so strong that it's fair to say that if Prolog is a hand, the Worldwide Web is a glove.

HTTP

Consider that Prolog's default behaviour is query-solving – where a query is posed for which arbitrarily many answers (solutions) may be returned.

This can be mapped to HTTP's request/response mechanism straightforwardly:

HTTP GET

The HTTP GET verb has a clear correspondence with Prolog's notion of a query. In fact, Prolog can be used directly as part of a request URI, acting as a lightweight data structuring mechanism.

However, HTTP requires each request/response to be deterministic, which suggests that all the solutions for a non-deterministic query should be returned. The solutions can be formatted as an XHTML list or table, for example.

Caching

Prolog programming allows for the 'caching' of expensive results using lemmas, a technique used in the solution of the Mister X puzzle, for example.

HTTP's 'HEAD' verb and GET with “If-Modified-Since” support caching mechanisms, primarily to save communications bandwidth.

The integration of Prolog lemmas with HTTP's caching methods can save both bandwidth and recomputation through a single mechanism, enabling the creation of robust distributed applications with a minimum of fuss.

HTTP POST

When using Prolog with HTTP, the POST verb should be reserved for passing clauses from the client to the server, to update the server, not for queries.

The fact that Prolog is a good format for including structured (composite) data items as part of a URI can obviate some inappropriate uses of HTTP's POST verb, by allowing more complex terms in GET requests.

XML

HTTP services in which both the client and server are Prolog programs can gain efficiency by exchanging Prolog terms in URIs and results, using Prolog's term I/O facilities.

However, XML is becoming established as the preferred format for data exchange in heterogeneous distributed applications.

XML data is represented easily in Prolog, and vice versa, because both use tree-structured data exclusively.

Because Prolog is a very high-level language, it is more flexible and more powerful than XSLT. In particular, it seems to be very much easier to create robust and reliable transformations with Prolog, i.e. ones that produce only valid output for any valid input.

xml.pl

xml.pl is a module for parsing XML with Prolog. It has been placed in the public domain to encourage the use of Prolog with XML.

PiLLoW

The PiLLoW library provides predicates for developing HTTP client and server applications.

For client applications, it provides mechanisms to retrieve HTML files and to parse HTML into useful Prolog terms.

For server applications, it provides a predicate to access CGI query parameters so that a Prolog application can be used to handle form input directly i.e. without additional scripting. Additionally, HTML parsing supports the reverse translation of terms into HTML so that forms can be generated.

See also, Porting PiLLoW to Quintus Prolog.