🚀 go-pugleaf

>(I suspect anyway that this is another of George's attempts to bring
>flames into net.lang.prolog, right? :-)

No! I was just asking questions. I don't understand why asking if an algorithm
(DFID) is applicable to parallel PROLOGs should be construed as an attempt to
raise tempers. My reasons for asking were:

1) The copious use of cut in PROLOG indicates that programmers are frequently
interested in only a single, first, solution. I thought perhaps DFID might be a
way of finding a single, first solution in very large PROLOG search spaces. For
example, a program to synthesize new chemicals might be find DFID useful for
finding the shortest synthesise pathway (very large branching factor in a very
large search space). 

2) I've heard logicians complain that PROLOG doesn't adhere to logic because
the order of rules should not affect whether a proof is found, e.g., sometimes
PROLOG programs go into an endless recursion if the rules aren't ordered
correctly. I never expected flames because an algorithm like DFID might search
and find a proof regardless of the ordering of rules (was that the flame?). I
thought a predicate called 'dfid/1' could act sort of like 'call/1' where the
proof of dfid would use a different search strategy (assumes there is no order
dependent code in the proof of dfid). 

I'm ignorant about parallel or concurrent implementations of PROLOG and
was just seeking enlightenment -- not flames. Thank you for the thoughtful
replies; they were very helpful. The replies seem to indicate that most
PROLOG programs have a very small branching factor which would make DFID
more of liability than an asset.


						George Van Treeck
						Digital Equip. Corp.