opencog / atomspace

The OpenCog (hyper-)graph database and graph rewriting system

Home Page:https://wiki.opencog.org/w/AtomSpace

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Implement NextLink

linas opened this issue · comments

The NextLink is an idea to alter the pattern matcher to return one result at a time, rather than waiting for it to find all results. It is meant to replace the cog-bind-first-n scheme function. It should work something like this:

NextLink
    anchor-atom
    PatternLink

Here, PatternLink might be GetLink or BindLink or DualLink - any of the pattern matching links. The anchor-atom can be any atom, it will be used to distinguish different pattern searches running in parallel. (Its not obvious that the anchor is needed, so maybe it should be optional?)

Each time NextLink is called, another result atom is returned. If there are no results, then simple (Atom) is returned, to denote the empty result.

A reasonable implementation would be to cause the PatternLink to run in a distinct thread. The purpose of this thread is not to speed up or parallelize, but simply to make it easier to manage the internal state of the pattern matcher. That is, the NextLink is a de-facto continuation, and continuations need to store state somewhere. For this particular case, it seems easiest to store the pattern matcher state in a distinct thread.

Bonus points: since NextLink is essentially a "call with current continuation" (or call/cc) it might be usable with other link types, e.g. PutLink or with FilterLink or with MapLink, all of which accept sets as input and return sets as output. That is, NextLink could be used to iterate over the elements of a set. Whether or not this is a good idea is unclear; the bonus-points are to clarify this.

There are several ways to think of the above proposal.

  1. launch a thread to find all pattern bindings, and use the C++ NextLink::execute() method to return answers one-by-one

  2. do lazy evaluation: i.e. search for and return only one answer at a time; defer computation until it is needed.

See also #1645 "Parallelize the pattern matcher" for discussion of what a scatter-gather/map-reduce type API might be appropriate for pattern matching.

See also #1750 as maybe a much better way of publishing search results.