Attribute Variables: Library Interfaces / Implementations / Portability

Question

When I was looking at some prologs recently, I came across this @mat answer to the question How to represent a directed circular graph in Prolog with direct access to neighboring vertices .

So far, my personal experience with using attributes in Prolog has been very limited. But the precedent given by @mat aroused my interest. So I tried to use it to answer another question, a list of orders with programming logic constraints .

Firstly, the good news: my first use of attribute variables turned out the way I wanted.

Then, not so good news: when I sent the answer, I realized that in Prolog there are several APIs and implementations for attributes.

I feel that over my head here ... In particular, I want to know the following:

• What API is widely used? So far I have found two: SICStus and SWI.
• What features do the various attribute implementations offer? The same? Or is one of them used in the other?
• Are there differences in semantics?
• What about the actual implementation? Are more effective than others?
• Can (or have) use attribute variables as portability?

A lot of question marks, here ... Please share your experience / position? Thank you in advance!

---

Edit 2015-04-22

Here is a snippet of the response code:

init_att_var(X,Z) :- put_attr(Z,value,X). get_att_value(Var,Value) :- get_attr(Var,value,Value). 

So far I have "used" put_attr/3 and get_attr/3 , but --- according to the SICStus Prolog documentation on attribute variables --- SICStus offers put_attr/2 and get_attr/2 .

Thus, even this very minor use case requires some level of emulation (one way or another).

Answer 1

I would like to focus on one important common point that I noticed when working with different interfaces for variable attributes: when developing an interface for variable attributes, the developer should also keep in mind the following:

• Is it possible to take attributes into account when discussing simultaneous unifications , as in [X,Y] = [0,1] ?

This is possible, for example, in SICStus Prolog, since such bindings were canceled before verify_attributes/3 called. In the interface provided by hProlog ( attr_unify_hook/2 , called after unification and with all the attachments already in place), it is difficult to take into account the (previous) attributes of Y when discussing the union of X into attr_unify_hook/2 , because Y no longer a variable at this point ! This may be enough for solvers who can make decisions based only on ground-based values, but this is a serious limitation for solvers who need additional data, usually stored in attributes, to see if the join should succeed, and then no longer Available, One obvious example: logical unification with decision diagrams.

As of 2016, the check-attribute branch in SWI-Prolog also supports verify_attributes/3 , thanks to the great work of doing Douglas Miles . The branch is ready for testing and should be combined with the master as soon as it works correctly and efficiently. For compatibility with hProlog, the branch also supports attr_unify_hook/2 : it does this by overwriting such definitions into a more general verify_attributes/3 at compile time.

It is clear that there may be a drawback of verify_attributes/3 , since the simultaneous creation of several variables can lead to the fact that you will more likely see (in attr_unify_hook/2 ) that the union cannot be performed. However, I will gladly and at any time share this, as a rule, insignificant advantage to increase the reliability, ease of use and enhanced functionality that gives you a more general interface, which in any case is already standard behavior in SICStus Prolog, which located at the top of its community is also one of the faster Prolog systems.

SICStus Prolog also contains an important predicate called project_attributes/2 : it is used toplevel to restrict the project to request variables. SWI-Prolog also supports this in recent versions.

There is also a huge advantage to the SWI: the residual targets that attribute_goals//1 and therefore copy_term/3 give you are always a list. This helps users to avoid default in their code and encourages a more declarative interface because the list of goals of a pure constraint cannot contain management structures.

Interestingly, no interface allows interpreting unifications except syntactically. Personally, I believe that there are cases where you can interpret unifications differently than syntactically, but there may be good arguments against this.

Other interface predicates for assigned variables are in most cases easily interchangeable with simple shell predicates for different systems.

Answer 2

Jekejeke Minlog has state attribute variables <or> . Well, not really, an attribute variable can have zero, one or many hooks that are allowed to close, and therefore may carry a small state.

But usually, an implementation controls state. To this end, the Jekejeke Minlog Purpose allows you to create reference types from variables so that they can be used as indexes in tables.

Full potential is untied if it is combined with trailing and / or forward. As an example, we implemented CLP (FD). There is also a small tutorial.

In our case, the primitive components :

1) Stateless attribute variables
2) Trailing and variable keys
3) Continuation of the queue

Attribute variable attributes can have associated effects before extending the continuation queue, but only run once. Goals from the continuation queue can be non-deterministic.

Before implementing applications, there are several additional levels, which are mainly clusters of primitives for making changes temporarily.

The main applications are open source here and here :

a) The ultimate resolver of domain restrictions
b) Herbrand restrictions
c) Suspension

Bye

Answer 3

You can find one of the oldest and most complex implementations of attribute variables in ECLiPSe , where it is part of a wider infrastructure for implementing constraint resolvers .

The main characteristics of this design:

• attributes must be declared, and instead the compiler supports efficient access
• the syntax of the assigned variables so that they can be read and written
• a more complete set of handlers for operations with attributes; therefore, attributes are taken into account not only for unification, but also for other general operations, such as terminal copying and subnet tests
• a clear separation between variable attribute concepts and suspended goals.
• used in more than a dozen ECLiPSe libraries.

This document (section 4) and the ECLiPSe documentation contain more detailed information.

Answer 4

An additional perspective for variable attribute libraries is how many attributes can be defined for each module. In the case of SWI-Prolog / YAP and citing SWI documentation:

Each attribute is associated with a module, and a hook ( attr_unify_hook/2 ) is executed in this module.

This is a serious limitation for library developers such as CLP (FD), because it forces the use of additional modules for the sole purpose of having multiple attributes instead of defining as many attributes as needed in the module that implements their library. This restriction does not exist on the SICStus Prolog interface, which provides the attribute/1 directive, which allows you to declare an arbitrary number of attributes for each module.