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

From: Jan Wielemaker <[email-masked]>
Date: Sun, 24 Feb 2002 16:27:29 +0100

> 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.

> 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.

The only sensible reference to a variable is another variable.

> 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)), ...]).  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.  Some systems provide `global variables',
possibly not a bad idea and I think not very hard to implement.

> 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.  Yet
in other using a Prolog with dedicated support might be a better idea.
I am interested in projects taking SWI-Prolog into new directions.

	Cheers --- Jan