shankar@srcsip.UUCP (Subash Shankar) (07/24/88)
I was wondering if anybody knows of any papers (or implementations) of programs for translating OPS5 (or any other production system) programs into Prolog. Failing that, are there any production system interpreters written in Prolog? And what the heck, anybody care to comment on the difficulty of such a project. I would think that both the translater and interpreter would be fairly simply to write, although the language specific primitives may cause problems. Thanks.
gooley@s.cs.uiuc.edu (07/25/88)
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. Then again, there's been some talk recently of optimizing compilers for OPS5, and even of something vaguely resembling a WAM (it's a building-block of the PESA-1 machine, if memory serves, not a stand-alone serial machine like the WAM). Therefore, implementations of OPS5 seem slowly to be coming up to the standard for those of Prolog. Anybody have more details? Mark. Gooley, gooley@s.cs.uiuc.edu
cdsm@ivax.doc.ic.ac.uk (Chris Moss) (07/28/88)
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.