FreeLink variable order depends on variable names, not just atom structure

[ngeiswei]

The variable order returned by FreeLink (FreeLink::get_vars() for C++, cog-free-variables for Scheme) depends on the variable names, not just the atom structure. For instance

 scheme@(guile-user)> (cog-free-variables (And (Variable "$X") (Variable "$G")))
$6 = ((VariableNode "$G")
 (VariableNode "$X")
)
scheme@(guile-user)> (cog-free-variables (And (Variable "$X") (Variable "$Y")))
$7 = ((VariableNode "$X")
 (VariableNode "$Y")
)

I don't know if that's a bug, probably not, but it should at least be added as a warning in the pertinent documentations https://wiki.opencog.org/w/FreeLink https://wiki.opencog.org/wikihome/index.php/Scheme#cog-free-variables

[linas]

The free variables are a set. Sets do not have a defined order. It was defined that way on purpose. The documentation somewhere does state why its a set, and not an ordered list. Please note that the concept of order is fundamentally ill-defined in atomese. Not only is there ambiguity in breadth-first vs. depth-first searches, there is also ambiguity in unordered links. I don't see much point in artificially introducing some fake order, when the core concept is naturally unordered.

I don't recall adding a scheme wrapper for this; exposing this function in scheme does not seems to be a wise idea, I don't know why it got exposed or who uses it.

[linas]

Archeology reveals that it is you, Nil, who added the scheme binding for get_free_variables, two years ago. Here: 341eda9 Why did you add this? why would you ever need to access this outside of C++ code?

I'm kind of nervous to see core function escape out of C++ code, and move into scheme (or python) -- it makes long-term maintainability and portability harder, and risks creation of spaghetti code. Maybe there really is some valid reason to export this kind of function into scheme code, but its not obvious what it would be.

[linas]

Grepping for users of this function gives none in the atomspace, one in PLN:

pln/rules/wip/instantiation.scm:  (if (member V (cog-free-variables A)) #t #f))

From there, the various users branch out in various directions. It's kind of hard to run them all to ground. But, from what I can tell, the only place it ends up getting used is in select-conditioned-substitution-terms which is trying to find some kind of expressions that can be somehow glued together.

From the distance, and not close up, it appears that you are trying to use variables as if they were connectors. So, in various domains, there is this concept of "jigsaw puzzle pieces", and that two pieces can only be joined, when their connectors fit together. When I skim the contents of implication-instantiation.scm it sure looks like you are trying to assemble jigsaw-pieces, but instead of using connectors, you are using variables. I might be totally wrong -- I'm just skimming. But if this is the case, then perhaps variables are the wrong paradigm?

Even in the pattern matcher, variables aren't really "variables" in a traditional sense; instead, they encode a "don't care" condition applied during search.

In atomese, perhaps we should make a much stronger distinction between variables, in which we can substitute values, variables that encode "don't care" conditions, and variables that are actually connectors. !? Doing this might not be easy, but it might be important. Hard to tell.

[linas]

A few more comments about "connectors": as a general rule, the location of the connector does not matter; only the type; as long as the connector types are compatible, they can connect. There still may be some global rules that constrain connection: e.g. the the final graph is planar, with no crossing links. This has the side-effect of enforcing a degree of sequential order.

Or there may be more complex constraints e.g. "landmark transitivity". If the graph can be laid out in a linear fashion, then there can be left-right constraints. If you can naturally color the graph, there might be coloring constraints. Again: these are all "global" constraints that have to be satisfied by the final graph, rather than "local" constraints, e.g. that the connectors appear in a certain fixed order.

Whatever. I'm just looking at implication-instantiation.scm and it looks like its trying to enforce local connector constraints, using variables as connectors. Or I might be wildly wrong.

[ngeiswei]

Ooops, I had forgotten I had added that wrapper. And of course I got confused because it returns a list, while as you pointed free variables are a set. My bad.

As far as instantiation.scm goes, it is likely obsolete, and if not it should be. All rules under the wip directory need to be reviewed, then fixed or removed.

[ngeiswei]

Though I've got to say that the FreeVariables class https://github.com/opencog/atomspace/blob/master/opencog/atoms/core/Variables.h#L48 doesn't exactly reflect the fact that free variables are unordered either, see FreeVariables::varseq, etc. Maybe all attributes and methods of FreeVariables pertaining to and depending on variable ordering should be moved to Variables. Not that it is very important though...

[linas]

the schizophrenic usages of seqs vs sets has a lot to do with C++, and that it is often awkward to use one or the other -- its often just easier, faster to use seq, even though something is conceptually a set.

[linas]

I'm closing this, because:

• There's been work done in this direction,
• The discussion above seems too vague to suggest an actual action plan. There doesn't seem to be anything concrete to do?

Reopen if you disagree, or a new issue with a more precise description of what should be done.