🚀 go-pugleaf

In article <208500001@s.cs.uiuc.edu> gooley@s.cs.uiuc.edu writes:
>
>Wasn't there some talk about OPS5 awhile back in this notesfile (over a
>year ago)?  Somebody hand-translated a few standard OPS5 benchmarks (such
>as monkey-and-bananas) into Prolog and found that the Prolog versions,
>even using C-Prolog, were much faster than the OPS5.  I don't recall
>seeing anything at that time about an automatic translator, though...but
>this shows that such a gadget might be useful.

As the person who submitted that program to the net, I'd say it's unlikely 
that you'd get an automatic translator that would satisfy anyone, at least
as far as performance is concerned, without a LOT of work.

The reason is this: OPS5 is a forward chaining system that uses crafty
heuristics to choose which goal to try next, at which it is moderately
but not spectacularly successful. In practice many OPS5 programs are
actually hierarchical and can easily be translated into Prolog's 
backward chaining mode, using unification to preserve the results of
the actions. In fact one can do better by inspection than the naive
approach of bunging all the working memory into an association list
and then searching it each time you want to change it. Often variables
have a particular function: e.g. a goal variable which says what the
current subproblem is.

In other words, starting off with an OPS5 statement which says in effect:

	condition, condition,..., condition -> action

one ends up with a Prolog clause of the form:

	goal <- condition, condition,..., condition, action.

where each statement is read (roughly) left to right (in the Prolog case
exactly so). Actions are coded as state transformers on one of a pair of
parameters, so assignments are not required.

Production systems can however be used in totally different ways, in
which this translation method would be a loser.  The other ways
correspond much more closely to the original aims of production
systems which were, as I understand it, to mimic the behaviour of
intelligent brain systems which were supposed to have only a few
chunks of working memory. In fact it is used as a general programming
formalism, for which purpose it is not, in my opinion, so useful (at
least not for sequential machines).

Chris Moss.