blob: 80e446f09942342cfc47a7f7a535f13fd62ae7a0 (
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
|
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
Level 2 will introdue syntax sugar for quickly instantiating conceptual relationships
using operators. This is handled by creating syntax expression concepts.
|
