Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User defined types #2901

Open
linas opened this issue Nov 23, 2021 · 2 comments
Open

User defined types #2901

linas opened this issue Nov 23, 2021 · 2 comments

Comments

@linas
Copy link
Member

linas commented Nov 23, 2021

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 from TypeNode, and allowing constructions such as this:

	(TypeDefinitionLink
		(DynamicTypeNode "CatNode")
		(TypeNode "ConceptNode"))

after which the user would be able to writing things like (CatNode “Fuzzykins”).

Links are only a little harder. For example:

	(TypeDefinitionLink
		(DynamicTypeNode "CatLink")
		(EvaluationLink
			(TypeNode "PredicateNode")
			(TypeNode "ConceptNode")))

which would allow the user to then write things like

	(CatLink
		(PredicateNode "has")
		(ConceptNode "fur"))

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,

	(DynamicTypeLink
		(DynamicTypeNode "CatNode")
		(ConceptNode "Fuzzykins”)

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 existing DefineLink. 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.

@linas
Copy link
Member Author

linas commented Dec 12, 2021

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?

@linas
Copy link
Member Author

linas commented Dec 13, 2022

Issue #2190 has discussion regarding an earlier variant of this idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant