🚀 go-pugleaf

I thank James Harland for a very interesting response to my query.

Such ideas are sometimes obscured by a frequent interpretation of
"declarative programming" or "executable specifications", i.e. where one
only has to specify what the problem is, and not how it is to be solved.

In a sense, an executable specification is quite easy to obtain.  Suppose
one can specify a problem in a formal language.  Then, one can use any
complete theorem prover for it to query that specification.  So, what is
to distinguish doing this in full first-order logic from doing the same in
definite clauses (with SLD-resolution)?  It is the possibility of
specifying algorithmic knowledge in the latter.

Often, when people are told about the merits of Prolog, especially its
logical basis, they assume they are relieved of the responsibility to
specify algorithmic knowledge.  Then, they notice unpleasant aspects e.g.
frequent inability to run programs backwards, having to worry about
ordering of goals, search for proof by backtracking, absence of logical
negation.  Finally, they say, "Oh Prolog is just another programming
language.  We still have to worry about *how* to solve a problem".  Of
course this is true!  But the interesting aspect is that Prolog allows one
to think about algorithms in a logical manner (in addition to offering
good expressive power).

The procedural interpretation of a logic is a very interesting idea.
Perhaps equally interesting is a logical interpretation of a procedure.

Sanjai Narain