Subject: RE: [SWIPL] Looking for a way to record a variables reference

From: "Douglas R. Miles" <[email-masked]>
Date: Sun, 24 Feb 2002 19:09:39 -0800

Jan,

See Comments bellow:

> -----Original Message-----
> From: Jan Wielemaker [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 7:27 AM
> To: Douglas R. Miles; [email-masked]'
> Subject: Re: [SWIPL] Looking for a way to record a variables reference
> 
> 
> > I am looking for a way to record a variable's reference.. 
> > For example the way block/3 allows a variable to be used as a 'key'.
> > 
> > I could term_to_atom/2 a varable and gets its '_G325' 
> > and use that.. But I am trying to find a 
> > 
> > variable_reference(-Var,+VarRefInteger)  
> > 	and perhaps even make an unsafe 
> > 	  variable_reference(?Var,?Integer)
> > 
> > Should is start by ussing valTermRef(vt) ?
> 
> valTermRef extracts the address from term-reference.  Term-references
> only live as long as the call to C, so you can't do much with them.

I understand now.

> 
> > Is there any way to go the other way arround?
> > Just how quickly do things change?
> 
> Addresses of variables should not be considered stable.  Backtracking
> end the life of variables, garbage collection may do the same or move
> them.

Understandable about garbage collections shifting them about of memory.  I
must be more interested in how it gets it's name and how dynamic that is. 

> 
> The only sensible reference to a variable is another variable.

I suppose one would do this on a variable that was never backtrack over in
the program.  A single or many topvars that woould stay arround for the
durration of the program. 

> > I'd liketo attach  a disjuntive set of arbitrary properties 
> to be put on a
> > variable.
> > recorda(VarRefInteger,isa(human))
> > recorda(VarRefInteger,isa(animal))
> 
> There is no (sensible) way references to variables from the permanent
> heap are going to work.  You can store information about variables in
> other terms (i.e. by having a list or table with a term [var(X,
> isa(human)), var(Y, isa(animal)), ...]). 

Yes, currently I am storing some variables in the exact manner. An 'ordered'
list like
[v(_G1,[prop1|_RoomforMoreProperties]),v(_G2,[propA,propC|_]),v(_G3,[prop1,p
ropB|_]),v(_G4,[prop1,prop2|_])|_PlaceForNewVars] throughout the depth of a
query.  The variable stays active since it is created at time of user query
and then disappears afterwards.. which works just fine.  
But instead of membering throuh a list, So I think i am looking for a more
efficient storage.
I thought that I could give each variable a   'Tracking' number or 
atom such as using  term_to_atom(_G22,'_G22') to be used as a key

> Some systems provide `attributed
> variables' for this purpose.
> 
> > What would be the complications of allowing a variable to 
> work as a 'Key' in
> > flags/3 and record*/N
> 
> Not much in the current design.  
> 
> > I would see problems trying to access then back with 
> current_flags/1 and
> > current_key/1.
> 
> Life-time is the biggest trouble.

Yes, I see  recorded(Var,Info) you wouldnt have any idea if this was the
same varibles info.

>  Some systems provide `global variables',
> possibly not a bad idea and I think not very hard to implement.

Do global varibles act like standard prolog varibles built from a frame
higher then your current one.. Or are they just not lost on bactrackign?

> 
> > But what if there was a '$variable' wrap of some sort or an 
> alternate form
> > of access?
> 
> The more interesting question is what are you trying to 
> accomplish?  In
> some cases variables aren't a very good idea in the first 
> place.  In others
> you can get away using some clever datastructures in standard 
> Prolog.  

The is an inference engine I am trying to optimize.  Attempting to profile
clause head usage 
per actual == prolog variable to detect loops but allow certain variables to
enter a clause multiple times.  The final goal is an iterative deeping of
per variable usage.  As well as a 'max alternatives'  When the body clause
has new variables completely disconnected from the head, I'd like to set up
a heuristic to decide how many times they should bind (ussualy once).  Two
problems i am trying to solve:  Record per-varible clause usage so the later
on in the query durring a cycle the variable wont be used in the clause and
go thru the same path. presently with a
var(Var,[usedInClauseTimes(clause56,20) is in the master list and i can
prune off further calls but backtracking further back makes the masterlist
forget that this should be a pruned path.
I started using block/3 to so i could exit up /out of a search tree quickly.

For each new varible, I create a new block/3 and at any time the system
could cut a 
bunch of of dead end points instead of backtracting.  
It also is sending back its bindings and prunings via exit/2. I suppose 
this can make prolog varbles disappear? so it ends up being a term copy (and
not a gateway to 
another frame).  Sometime I start a loop of catch(!(Othervars),_,true) to
clear things up.  (I may not have to).

So it's not wanting type contraints (even though thats the example I gave in
email)  It's more to discover information like how many prolog calls has
this varible been arround.. what other varibles has it been unified with..
How many alternative calls the same variable could be used in.

For example

likes(sam,Food) :-
        indian(Food),
        mild(Food).

would become:

likes(sam,Food) :-
	  my_var_tracker(likes(sam,Food),likes(sam,FoodRenamed)),
        (indian(FoodRenamed),
        mild(FoodRenamed),
	  clause_completes(likes(sam,Food),likes(sam,FoodRenamed));
        clause_done(likes(sam,Food),likes(sam,FoodRenamed).

my_var_tracker(In,Out):-
	free_variables(In,Vs),
	save_some_info(In,Vs),
      edit_keep_or_force_fail_if_needed(In,Vs,Out).

save_some_info(In,[V|Vs]):-...

I don't know (I am only learning) if this tracking or clause selection is
even usefull.  I can do it efficiantly by other means currently.  Like
making 'my_var_tracker'/2 clause call pattern centric is more usefull then
variable centric.  But I would like a way still to recognised prevously used
variables. And maybe later, even 'simular' varibles that were generated
using a duplicated path thru the clause database. 

So the ability to use a variable's _Gxxxx name or simular to go straight to
some information store would be usefull.  When that xxxx disapears I
understand I would have to contend in some way.  

> Yet in other using a Prolog with dedicated support might be a better idea.

imagine what Sicstus would tell me! ;P

> I am interested in projects taking SWI-Prolog into new directions.
> 
> 	Cheers --- Jan
> 

Thank you,

Douglas