ADDED: portray_var/2 and flag auto_name_variables

[dmchurch]

This adds a new flag, auto_name_variables, that controls an implementation of a new portray hook to customize how variables are printed.

Before and after:

?- L=[_,_,_], member(X, L).
L = [X, _8654, _8660] ;
L = [_8648, X, _8660] ;
L = [_8648, _8654, X].

?- set_prolog_flag(auto_name_variables, true).
true.

?- L=[_,_,_], member(X, L).
L = [X, __A, __B] ;
L = [__C, X, __B] ;
L = [__C, __A, X].

The indexing is reset every time Prolog returns to the query prompt at break level 0.

[JanWielemaker]

Interesting feature. I need to think a little about this though. The linear list may get rather costly. Also, once the variable is instantiated the entire term will become part of the global list. With many variables printed, for example through debug prints, this may get rather costly, both in terms of variable-name lookup as because once printed instantiated variables can no longer be garbage collected as they are accessible from the global array.

An alternative approach could be to use an attribute. The problem with that is that attvars are not admissible everywhere. Another solution is to use the content of a variable to give it a stable identifier (I guess that is the main purpose?). As is, a variable is simply a zero-word. Just testing the tag bits for zero is enough. I don't know the performance impact of that. A more serious problem is that a number of the internal routines processing terms use the content of the variable for temporary admin. Might be hard to replace. Maybe some reserved attribute that doesn't cause the variable to be considered attvar? Might also be tricky ...

[dmchurch]

Maybe some reserved attribute that doesn't cause the variable to be considered attvar? Might also be tricky ...

Sounds like a job for term painting, doesn't it? 😄 I actually have another variant of this idea I came up with before the portray_var/2 solution, which attaches an extra data structure to LD and allocates a fixed data structure when requested via option arguments to write_term/2. I went with the portray_var solution at least for now, because it doesn't involve malloc() and free() calls hanging about in the pl-write.c source, ha.

I'll keep thinking on ways to improve this, the hidden-attribute version seems like the most workable idea so far, I think 🙂

[JanWielemaker]

Exploring the term painting idea might make sense. One problem is that backtracking will "unpaint" the variable ... I've been thinking about getting stable names for variables several times. Never came up with something that is sufficiently simple and doesn't use excessive amount of resources ... Some price is affordable as long as it can be switched off or we can by default disable the thing if we cannot manage the resource usage. Debug prints and tracing can lead to large number of variables that must be "named" ...