0.3 - Attributes: Give me where to stand...

The introduction of attribute trees creates a new behavioral model for exploration and exploitation.

An implication worth noting is the emphatic new conceptual distinction between a single attribute

&example me=this is an example

and the single attribute which also serves as the root segment of an attribute tree

&example me=these are my examples
&example`a me=these are my 'a' examples
&example`a`1 me=this is example 'a1'
&example`a`2 me=this is example 'a2'
&example`b me=these are my 'b' examples
&example`b`1 me=this is example 'b1'
&example`b`2 me=this is example 'b2'

This is a new conceptual imperative: Any single attribute can, at any time, conceivably be (become, be treated as, and/or behave as) a portion of an attribute tree.

This imperative's potential lends itself somewhat naturally to subroutine management such as that illustrated by the ~reboot module in which @startup behaves both as a single attribute (containing code which is triggered at startup)

@startup #1=<this code is automatically triggered and it retrieves code from attribs in the startup` tree without directly triggering those attribs>

and as the root of a tree of other attributes (each containing code to be placed in the queue by the code in the @startup attribute).

&startup`0000 #1=<this is the first piece of code retrieved for execution by me/startup>


(Changes to ~reboot pending.)

Other implications resulting from this imperative can be found, coincidentally, within god's startup actions: specifically those actions involving the @attrib command and its family.

Give me where to stand and I will move the earth.

A remark attributed to Archimedes by Pappus of Alexandria (in his "Collection") and commonly called "Archimedes Lever", this simple assertion of relativity long predates that of Einstein's mathematical equations. Furthermore, Archimedes assertion better illustrates the reality of human experience.

In a very 'human experience' way, Archimedes Lever describes this new imperative of attribute trees with tremendous precision.

An examination of a minimalist example can illuminate this for us quite nicely, so let us look at a tree based on single-character name segments. To explore this concept, we'll use our special attribute, the tilde (~), as the root of the tree, then expand it with other common single characters (0-9, a-z, possibly others) as branches and leaves.

Let us first work with 0-9 as leaves, directly attached to the root.

~
~`0
~`1
~`2

etc...

This imperative carries one set of implications if the root attribute needs different attribute flags than the numbered leaf attributes, and another set of implications if the root attribute is flag-indifferent (e.g., it's empty - the default, since it's automatically generated whether you intend to use it or not).

Once again, our startup` tree, if applied to a player ancestor, illustrates this well -- you want the basic processing code (the startup attribute) to be available to all players, yet you also want the remainder of ancestor's startup' leaves to not be inherited (i.e., only apply directly to ancestor) -- you can do this by setting the branch (startup`) no_inherit.

If the tree is expanded to more levels (e.g., the addition of a-z as leaves on the 0-9 branches), the aforementioned implications remain present. However, as the number of levels increase (at least the first few branches beyond the first branch) these same implications can become organizational organizational variables. For example, ...

~
~`0
~`0`a
~`0`b
...
~`1
~`1`a
~`1`b
...


It's important to remember, at this time, that restrictions are inherited but privs are not, and that restrictions are only inherited by the leaves of the branch to which they're applied.

Adding to this, entire trees can be completely veiled from a default examine by simply veiling their root attribute.

So, one of potentially countless applications of our 'where to stand' philosophy is that at any single branch point (where to stand) we have the ability to control (restrict) all of its leaves (move the world)... all the while leaving the branch point itself (which may be an in-use leaf of a lower branch) and all subsequent branches (leaves of the current branch which are also branch points for subsequent branches and/or leaves) and their leaves unaffected.

And this is as good a time as any to complicate the overall situation even further (at least initially) by re-introducing the attribute naming concepts from the original version of this section. (Until I add a more updated and relevant version of these concepts, you can review the 'Old' subpage of this page.)