KR - Allow better tracking of source varialbes about logicmoo_workspace

[whitten]

What do you mean by "source" varialbles?
variables defined in Prolog or variables that exist in the logic such as used by forAll or thereExists ?

[TeamSPoon]

The "source" variables were from CycL/CLIF used by forAll or thereExists that initially had names.

I actually preserve these through the stages of the canonicalizer which converts CycL to a language that is prolog (with prolog variables).

% pkif :-
%       all(PARENT,
%           all(GRAND,
%               all(CHILD,
%                   (parent(GRAND, PARENT)&parent(PARENT, CHILD)=>grandparent(GRAND, CHILD))))).
%
% /devel/LogicmooDeveloperFramework/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl:320
% cnf :-
%       grandparent(GRAND, CHILD)v (not(parent(GRAND, PARENT))v not(parent(PARENT, CHILD))).
%
% /devel/LogicmooDeveloperFramework/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl:320
% horn :-
%
%       [ (not(parent(GRAND, PARENT)):-not(grandparent(GRAND, CHILD)), parent(PARENT, CHILD)),
%         (not(parent(PARENT, CHILD)):-not(grandparent(GRAND, CHILD)), parent(GRAND, PARENT)),
%         (grandparent(GRAND, CHILD):-parent(GRAND, PARENT), parent(PARENT, CHILD))
%       ].
%
% /devel/LogicmooDeveloperFramework/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl:320
% pfc :-
%
%       [ (neg(parent(GRAND, PARENT))<-neg(grandparent(GRAND, CHILD)), {avoidHeadLoop(parent(PARENT, CHILD), parent(GRAND, PARENT))}, parent(PARENT, CHILD), {vg(s(PARENT, GRAND))}),
%         (neg(parent(PARENT, CHILD))<-neg(grandparent(GRAND, CHILD)), {avoidHeadLoop(parent(GRAND, PARENT), parent(PARENT, CHILD))}, parent(GRAND, PARENT), {vg(s(CHILD, PARENT))}),
%         (parent(GRAND, PARENT), parent(PARENT, CHILD), {vg(s(CHILD, GRAND))}==>grandparent(GRAND, CHILD))
%       ].
%

Then right before I save the result I end up purposely discarding them.

% /devel/LogicmooDeveloperFramework/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl:320
% succeed(user:must_det_l((show_interesting_cl(kif(fwc), if((parent(_G637, _G638), parent(_G638, _G659)), grandparent(_G637, _G659))), kif_process(if((parent(_G637, _G638), parent(_G638, _G659)), grandparent(_G637, _G659)))))).

Because to drag those strings "during query" slows down the engine.

But

saved_varname_info((parent(GRAND, PARENT), parent(PARENT, CHILD)=>grandparent(GRAND, CHILD)), true, '/opt/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl':320).\nsaved_varname_info((parent(GRAND,PARENT),parent(PARENT,CHILD) => grandparent(GRAND,CHILD)),true,'/opt/PrologMUD/pack/logicmoo_base/prolog/logicmoo/plarkc/logicmoo_i_clif.pl':320).

I store enough information they can be presented in the final proof.

But this method is not useful when "browsing the KB" ( As I purposely discarded them for certain structures .. when I converted them to native Prolog variables)

Like in this pt/2 structure (Positive Trigger) and really this is probably the most useful time to see "CHILD" instead of "A"
pt(parent(eileen,A),(vg(s(A,trudy)) -> rhs([grandparent(trudy,A)]))) :-
'deduced-from' = parent(trudy,eileen),
rule_why = pt(parent(trudy,eileen),pt(parent(eileen,A),(vg(s(A,trudy)) -> rhs([grandparent(trudy,A)])))).

The code had created a "listener" on eileen that any child she has.. will be grandparented by trudy

Other such structs are spft/3

spft(pt(parent(C, A), pt(parent(A, B), (vg(s(B, C))->rhs([grandparent(C, B)])))), (parent(C, A), parent(A, B), {vg(s(B, C))}==>grandparent(C, B)), u).

spft((neg(parent(C, A))<-neg(grandparent(B, A)), {avoidHeadLoop(parent(B, C), parent(C, A))}, parent(B, C), {vg(s(A, C))}), clif(if((parent(B, C), parent(C, A)), grandparent(B, A))), pt(clif(if((parent(B, C), parent(C, A)), grandparent(B, A))), rhs([{clif_to_prolog(if((parent(B, C), parent(C, A)), grandparent(B, A)), [ (neg(parent(B, C))<-neg(grandparent(B, A)), {avoidHeadLoop(parent(C, A), parent(B, C))}, parent(C, A), {vg(s(C, B))}), (neg(parent(C, A))<-neg(grandparent(B, A)), {avoidHeadLoop(parent(B, C), parent(C, A))}, parent(B, C), {vg(s(A, C))}), (parent(B, C), parent(C, A), {vg(s(A, B))}==>grandparent(B, A))])}, [ (neg(parent(B, C))<-neg(grandparent(B, A)), {avoidHeadLoop(parent(C, A), parent(B, C))}, parent(C, A), {vg(s(C, B))}), (neg(parent(C, A))<-neg(grandparent(B, A)), {avoidHeadLoop(parent(B, C), parent(C, A))}, parent(B, C), {vg(s(A, C))}), (parent(B, C), parent(C, A), {vg(s(A, B))}==>grandparent(B, A))], {sanity((clif_must if((parent(B, C), parent(C, A)), grandparent(B, A))))}]))).

There are multiple ways of keeping the variables names:

1. FASTEST, SIMPLE, WASTE_RAM: Every time I am about purposely discard I will create a unifiable copy of the same form but with variable names filled in.

https://github.com/TeamSPoon/PrologMUD/blob/master/pack/logicmoo_base/prolog/logicmoo/util/logicmoo_util_varnames.pl#L15-L39

2. SPEED 20% slower, COMPLEX, RAM_SAVED
   : Add a synthetic literal that will always succeed but will in times of printing allow variable names to "reappear"

  spft(pt(parent(C, A), pt(parent(A, B), (vg(s(B, C),{var_info(['CHILD'=A,'PARENT'=B,'GRANDPARENT'=C])})->rhs([grandparent(C, B)])))), (parent(C, A), parent(A, B), {vg(s(B, C)),no}==>grandparent(C, B)), u).

3. "CORRECT"ist , SPEED 200% too slow, SIMPLE, RAM_SAVED

   spft(pt(parent(C, A), pt(parent(A, B), (vg(s(B, C))->rhs([grandparent(C, B)])))), (parent(C, A), parent(A, B), {vg(s(B, C))}==>grandparent(C, B)), u):- 
       label_vars(['CHILD'=A,'PARENT'=B,'GRANDPARENT'=C]). 

Actually where this lead to: "Well if i am storing CycL variables and presenting them in proofs.. I should be using the same mechanism for doing that with the HL (Heuristic language Prolog). " So actually the answer this issue will problem is solved for Prolog Variables.