summaryrefslogtreecommitdiff
path: root/intellect-framework-from-internet/starts/meaning-vm/DESIGN.txt
blob: 295a7f200fba8b1ca8e4efb7f3c874d0a028c5d6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
The codebase is made in levels.
Ideally each level defines a complete API to the underworkings.
Higher levels include greater degrees of meaning and are
more expressive and powerful.
The purpose of levels is to prevent complexity recursion
until the components are smart enough to adapt, and make
handling bugs much less explosive.

Levels have a 'ref' class they use to refer to concepts.
Each higher level adds more functionality to this class.
The desired norm of coding a level is to use only the
functionality of the level prior, except to use that
level's ref class, rather than the lower one.  Ref classes
are just wrappers for a pointer, so this should cause no
issues.
This norm was established after levels 0 and 1 were coded,
so they do not meet it yet.

# LEVEL 0
Level 0 defines an interconnected network of concept references in memory.
Each concept has a unique address, and a list of concept pairs it links to.
The first of the pair represents the type of the link, and the second the target.
Concepts may not be deallocated unless nothing links to them.
A special kind of concept is the value, which holds arbitrary data alongside itself.

# LEVEL 1
Level 1 provides for every concept having a name using the "name" link.
There is additionally syntax sugar for instantiating and using named or hyphen-separated
references.  Level-1 names are for development ease, and are considered unique.
When multiple references are made with the same name, they always refer to the same concept.
Level-1 introduce the concept of groups, using the "is" link, and uses it to categorize
concepts that have an autogenerated name in the "anonymous" group.

# LEVEL 2
Whatever gets implemented next.  Maybe expression operators, maybe structure promises,
maybe infrastructure for moving implementation onto ref code objects.

# FUTURE
## Relevence pattern matching
	This is important and core.
	This appears similar to graph structure matching, except that code creatively relevent to 
	the parts of the structure must be continually run so as to generate new information,
	new structural parts.
	At its simplest, this solves (A is not a dog), (A is a cat), (cats are never dogs),
	with logical habits relevent to 'not', 'never', 'is', using one single matching interface,
	but with more relevence could do more.