Talk:DefineLink

From OpenCog
Jump to: navigation, search

Comments

Cut n paste from https://github.com/opencog/atomspace/issues/74

The place where DefineLink becomes interesting is in the pattern matcher: what happens when a pattern has define links in it? Should these be searched verbatim? Should these be understood as defining sub-patterns to be searched for? If a patten is large and complex, it sure would be nice to build it out of smaller, simpler sub-patterns defined in a DefineLink.

Tangled up in the above is the notion of "beta reduction" aka "substitution" aka "composition": all three of these terms refer to the same idea: given some expression containing x, substitute the value a for all occurrences of x (but do NOT do any further evaluation/execution; just substitute) -- this gets interesting if "a" is a the thing that is defined.

So, for example: the ExecutionOutputLink/SchemaNode example has two steps: a beta-reduction step, where the values 2 and 4 are substituted for X and Y, and then an execution step, where 2+ 4*10 is computed numerically. It would be nice to have a BetaRedexLink or SubstitutionLink or CompisitionLink (or even a modified PutLink!!??) that only does the beta-reduction, and nothing else.

There are more tangles. So, the SchemaNode example "works" because we "know" that, whenever we see a SchemaNode, that it was previously "defined" with a DefineLink (and that it is an error if a DefineLink cannot be found). But what about the PredicateNode "MyPredicate" example? So, every time that we see a PredicateNode, should we try to see if it is behing a DefineLink? This would be very CPU-wasteful... This suggests that the only things that can be "defined" are SchemaNodes, and maybe "DefinedPredicateNode"s and maybe, ummm. "DefinedPatternNode" (for defining search patterns??)

One last remark: I tried to solve some of the above while simultaneously writing the C++ implementation. What I often found was that, although my "theoretical" idea of how it should work was simple and clean, the C++ code became ugly. This was usually a signal that my "theoretical" notions were flawed.

One more last remark: the atomspace really really is a lot like "typed prolog" and it is very useful to study prolog, and see how it deals with these issues. Also, studying MUMPS seems like a good idea (although I haven't done so myself) -- MUMPS faces and solves many of these same issues.

Linas (talk) 09:39, 4 August 2015 (CDT)