Open linas opened 2 years ago
A similar idea involves the tagging of different data streams, so that (WordNode "foo")
is syntactic sugar for
(TagLink (TagNode "natural language word") (ItemNode "foo"))
This has the natural structure
(TagLink (TagNode "tag-name") (ItemNode "word"))
where ItemNode
is a kind-of LexicalNode
and TagLink
is a kind of Connector
.
An alternate viewpoint is the set-theoretic viewpoint: TagNode
is the name of a set, (so SetNode
) and TagLink
is a kind of MemberLink
.
The practical difference is that Tags are meant for data streams (tag a stream of words, a stream of pictures, a stream of audio). Thus, tags are for "the set of things a generator is producing".
The overall structure resembles a "user-defined type", but is .. different, somehow?
Issue #2190 has discussion regarding an earlier variant of this idea.
Seems its about time to start on proper runtime user-defined types. The simplest approach would seem to be to add a new type, say
DynamicTypeNode
, inheriting fromTypeNode
, and allowing constructions such as this:after which the user would be able to writing things like
(CatNode “Fuzzykins”)
.Links are only a little harder. For example:
which would allow the user to then write things like
while anything else would throw a syntax error. Full support would need to include support for SignatureLink, ArrowLink, and all the other type infrastructure, but that should be "easy", because that code is already there.
Under the covers (i.e. in the actual C++ code) this would have to be supported with a new
DynamicTypeLink
, so that(CatNode “Fuzzykins”)
becomes, under the covers,i.e. it becomes exactly what the type definition called for. Pretty much all that the implementation needs to do is to modify the node/link printers to print the user-defined types. That, plus type-checking to force the user to use what they declared they would use... TruthValues would need to pretend they live in the right place, but this is probably trivial (no code changes needed). I believe that pattern matching support will also be trivial (no changes needed).
TypeDefinitionLink
would special case the existingDefineLink
. Obviously, once a type has been defined and used, it cannot be deleted ... at least, nut until all the instances are deleted first.If you are reading this, and think this is a good idea, please upvote.