BRAND Sebastian wrote: > Hi, > > I've been looking at the plain > > suspend(+Goal, +Prio, +CondList) > > predicate from the kernel, and its description in the > reference manual. The second example > > suspend(writeln(X), 2, [X,Y]->bound), X=Y. > > works as stated, but the simpler variant > > suspend(writeln(X), 2, [X]->bound), X=Y. > > delays. I think this is incorrect. No, this is the intended behaviour: a delayed goal will only wake if it is in the bound-list of _both_ unified variables. See the User Manual chapter "Advanced Control Features/Standard Waking Conditions on Variables". This behaviour makes a lot of sense. Imagine you have two inequality contraints ?- X ~= Y, Z ~= W. The only var-var unifications that are of interest here are X=Y or Z=W because they can affect one of the goal's truth value. All other unifications X=Z X=W Y=Z Y=W are uninteresting and shouldn't cause unnecessary waking. In general, when a goal's variable gets bound to another variable which is not involved in the same goal, this is unlikely to be of any interest to the goal, so the implemented behaviour allows you more precise control. I should note that the semantics was cleaned up in the last release (and i apologise for it missing from the release notes...) as previous releases had a more unpredictable behaviour in terms of unnecessary wakings. -- Joachim Schimpf / phone: +44 20 7594 8187 IC-Parc / mailto:J.Schimpf@imperial.ac.uk Imperial College London / http://www.icparc.ic.ac.uk/eclipseReceived on Wed Mar 23 10:57:16 2005
This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:08:25 PM GMT GMT