Type checker

From OpenCog
Jump to: navigation, search

The type checker can be used to validate the type, or more specifically, the type signature of an atom. Type checking is performed by the pattern matcher to restrict the kinds of types that might be matched during a pattern query. Type checking is also performed by PutLink, to avoid the creation of inappropriate structures, thus implementing a defacto kind of FilterLink. Type checking is also performed by MapLink, again, to perform a kind of filtering (the MapLink should be thought of as a dual to PutLink: its an UnputLink).

In the future, type checking might be used to prevent the insertion of inappropriate atom types into the AtomSpace.

Type-checking code is primarily located in the "is_type()" method on class Variables; see /opencog/atoms/core/Variables.h However, it is also performed in an ad-hoc basis in several places. One such is the MapLink::extract() method, which does the recursive type checking needed to unput values in types; see /opencog/atoms/core/MapLink.cc.

At this time, it does not have a scheme wrapper, but it could; see below.

Overview

Currently in the Atomspace, nothing stops you from creating

InheritanceLink
   NumberNode "9"
   GroundedSchemaNode "print"

even though this is nonsense....

Also, if we had a PredicateNode whose input is supposed to be a GroundedSchemaNode mapping NumberNodes to NumberNodes, e.g.

PredicateNode
   isDifferentiable
   GroundedSchemaNode "x squared"

ExecutionLink
     GroundedSchemaNode "xsquared"
      NumberNode 3
      NumberNode 9

We have no way to represent these type distinctions so we could also form

PredicateNode
   isDifferentiable
   WordNode "frog"

ExecutionLink
     GroundedSchemaNode "xsquared"
     Sentence Node "I am not squarable"


It would be useful to be able to verify that a link or a node is of a specific type.

Signatures

The type of an atom can be specified by using a SignatureLink. If the atom is just a node, the TypeNode can be used to specify it's type. If the atom can be any one of several types (i.e. it is polymorphic), the TypeChoice link can be used.

The above-mentioned "is_type()" method on class Variables will return a yes/no answer as to whether a given graph is a given type.

To search for all graphs of a given type, this could be done as follows:

 GetLink
    TypedVariableLink
        VariableNode  "$X"
        SignatureLink
            .. whatever deep type you want...
   VariableNode "$X"

which will return all atoms having the specified signature. This query works today. This query is currently not optimized, and might run slow on a big atomspace. Its not hard to make it run faster, no one has needed this yet.

A new function, say 'cog-check-type' could be created (it hasn't been yet): it would accept two arguments: a SignatureLink, and an atom whose type needs to be checked.

Enforcement

Type checking could be performed at the time that atoms are added to the AtomSpace: the AtomSpace could maintain an table of approved types that are admitted, and compare to each. Because checking would slow down the addition of atoms, it would probably have to be made optional.

I suppose the only value of these would be to flag an error if someone's code created links that don't make sense. This may not be a problem that exists right now, thus it may not be worth solving the problem right now....

On the other hand, even if we don't enforce the type restrictions on code right now it would be useful to have clearly stated somewhere what type restrictions the Link types in use now are supposed to have. This info is all contained in some publication somewhere but is not always easy to find...

Type Inheritance

The page OpenCogPrime:TypeInheritance discusses how type inheritance works. If one merely need to see if (A->B) inherits from (C->D), one can do that with a 5-line-long scheme program or a 20-line long c++ (or a 10-line python program) I'm not sure where this would be needed, currently...

The pattern matcher does not check type inheritance at the moment; it could do this, with a minor extension. Define two new atoms TypeInhNode and TypeCoInhNode that work just like TypeNode, except that the first one looks downwards in the type-inheritance hierarchy, while the second looks upwards.