No, the variables of the compiled clauses are not the point ... but the variables of the solutions must stay the same. Except the d_next call, this is already working as u can see. Kish Shen schrieb: > Christian Wirth wrote: > >> >> if i only call getunboundmove(Player,Move,Term,State), the solution is: >> >> Player = Player >> Move = move(north) >> Term = [d_role(Player, _219), 'd_++'(_265, _340, _219), d_cell(_264, >> _340, _219)] - Read as: role Player exists | _340 is _264 + 1 | cell >> x=_263,y=_340 exists (the last var is State=_219, but these facts are >> state independent) >> State = [location(_73, _264, _265), \+ blockednorth(_264, _265)] - >> Player _73 is in position _264/_265 (Here _73 should be Player, but >> thats not importent) | the north of position _264/_265 is not blocked >> >> and for effect, i want to get: >> >> Effects=[location(Player,_264,_340)] >> >> It is essential, that the variable numbers are staying correct, >> because i need to map the effects to the relevant State/Term conditions > > I haven't been able to understand your code in detail, but am I > correct in thinking that you are compiling predicates such as d_role > and d_cell etc. in your example, which share variables (_219 in your > case), and you expect the compiled version of these predicates will > still share the variables? > > If so, this is a rather fundamental misunderstanding of variables in > Prolog. Variables exists during the runtime only, and variables in > your source are not the same as the runtime variables. > > If you really want to do meta-programming using compiled/asserted > predicates with some notion about shared variables across the > predicates, you will probably need to have some ground representation > of variables (such as an id number) in your predicates, which you > convert to runtime variables. > > Cheers, > > Kish >Received on Tue Feb 09 2010 - 15:34:39 CET
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET