Introduction

See (p3,dp) for some early ideas.

This will be integrated with the material at (formative,design).

This introduces an old idea originally described in (formative,ood) which will play a role in the implementation of the .design. This section constitutes a bottom-up design effort for the .design.

We introduce here the terms "value", "value key" and "value object".

We frequently have a key to an object such that use of the key does not affect subsequent uses of the key. In such cases we call the key a value key and the object a value object.

Another key to the same object may not have this relationship with the object. A factory requestor's key and the factory form a value-key, value-object pair. But a factory builder's key and the factory do not form such a pair because a use of the builder's key influences subsequent uses of that key.

Two factories with the same domain creator, components, ordinals etc. represent the same value but are different objects. There are two objects but just one value.

The value object has been called an "immutable object" elsewhere.

The producers described here understand this relationship and manage value objects to support these ends:
Represent definitional relations between various values,

Build value objects as they are required,

Provide access to value objects,

Keep track of requirements for a particular value object,

Delete value objects when they are not currently required and when space is needed,

Delete value objects when their values are obsolete (as an indirect consequence of a change in the definition of a value),

Register and enforce commitments to continue supporting values.

Provide an "ownership" relation that will serve to account for space and for negotiating ownership of and responsibility for a value.

Ensure that all sources are available for the software. Some sort of "escrow" is thus provided.

This is an attempt to describe the producer function while omitting some of the implementation strategies but specifying their goals.

There are these types of object which together provide the producer function: the SP, the SPD, the SS and the MO. These objects are referred to collectively as "SO"s.

The SP (Originally the "Smart Producer")
Introduction
For each value defined by the producer logic there is an SP. SP's hold the method of creating a value object for that value. These methods typically refer to other SP's. If SP b refers to SP c then we say that c supports b. Value objects of value v are created and deleted only by the SP associated with value v.

An SP knows when there is a value object currently in existence representing its value. When there is none, the SP creates the value object on demand. The SP will provide a copy of the value key to the value object.

The value for an SP may change when that SP or one of the supporting SP's are modified.

An SP consists of a row of comps and an MO reference.
An SP has a function which is either an SP script or a comp.

SP scripts:

We have not yet specified the semantics or syntax of SP scripts but it does not go far beyond that of a sequence of KC commands where the key operands are references to the comps available in this SP.

These scripts are pure data. That is to say that they have no authority in them. They can only invoke the authority that is passed to them by the SP. They are thus copyable.

It might be reasonable to say that an SP script refers only to the row of comps of the SP. This would make the SP interpreter extremely simple.

Logic of an SP while it defines a constant value.
The SP has hidden state transitions even while its value remains unchanged.

A key to the SP allows one to: ask for a value key to the value object, lock or unlock the value object.

While the object is locked the SP won't delete it. {N.B. The object lock won't protect from value changes which "obsolete" the value and its object})

How an SP defines its value
In an SP there is a row of several comps {(so-comp)} and a reference to an MO. The comps are referred to here as c[i] for i from 0 up. c[0] is also called the SP's function.

When an SP decides to build its value object, it calls v(c[0]) {(v-def)} passing a key, Vref. This call yields the value key to the new value object. Vref provides access to v(c[i]) for specified i and to v(c) where c is any of the comps accessible thru this SP's MO.

The value objects that are called for via Vref are value locked. Upon the return from the function those comps that aren't lasting are unlocked. Those that are lasting are unlocked only when this SP's object is deleted.

Changing an SP's value
Calls on an SP key may change the value that that SP or another SP defines, at which time it will cease to define the old value.

Calls on an SP can lock and unlock the value. The value will not change while it is locked. Calls that would change an SP's value will be refused if its value is locked or if the SP indirectly supports a value-locked SP.

The SPD (SP Directory): SPD's comprise a tree with SP's and MO's as leaves.
There is a mapping N from SPD's and EBCDIC names into SO's.

There is an SPD called rootspd.

If sx is an SO then for some n >= 0 there is a {unique} sequence (s(0), s(1), ... s(n)) such that s(0) = rootspd and s(n) = sx and for each i < n, there is a name m such that N(s(i),m) = s(i+1).

If N(s,n) = N(t,m) then s=t and n=m. {The tree has no "joins".}

{Each SO has just one tree path name.}

The MO (Map Object)
A map object is composed of:
a mapping of EBCDIC names to comps {(so-comp)},

a list of MO keys {which serve as directory extensions}.

A map object is called upon to provide a comp corresponding to an EBCDIC name. If this name is not among the names of the map object, the same name is requested {recursively} of the extension objects in turn.

Reason for MO

Most representations of programs within Gnosis have everything already bound except the parameters. The Record collection creator has its own access to the supernode creator. A requestor of a new record collection is not at liberty to substitute a different program for the supernode.

A design is a representation of a program that may wish to use the local supernode {or whatever}. This is necessary if the design is carried to another Gnosis. In this case it is not meaningful to bring your keys with you. The MO provides the space in which to find the local supernode factory. He who holds keys to the design has the code, not merely the service of the code. There is no way of preventing him from changing it. The MO provides the convenient way to symbolically bind these values.

The SS (Smart Segment)
This is a segment that will notify past readers of changes to the segment, or alternatively will inhibit such changes. It is designed to hold the source language in which Gnosis applications are built. {The SS is merely a front end segment keeper in front of a VCSK segment.}

SS's are created in SPD's and thus enjoy the durability attributes found there.

The position of the SS in the scheme of things

The idea of treating the smart segment as an integral part of the producer scheme seems to discriminate against other ways of storing information. Other objects types, such as record collections, should be able to serve like the smart segment. There is something special, however, about any object serving in this role: it must be manifestly copyable. The segment is uniquely natural in this respect.

Another consideration arises when a copy of a value-locked SP is made. The copy will contain a reference to a virtual copy of any SS that the original contained a reference to. Simple minded editing of such a segment results in changing most of the pages, thus losing the design advantage of the VCSK. An editor and OS reader that believes a threaded text representation solves this dilemma.

The comp
A "comp" is either:
a reference to another SP,
Some SP references are "lasting".

or a primitive key,
A primitive key is a key that is assumed to behave as a value key but whose logic is otherwise unknown to the producer logic.

If c is a comp which is an SP reference then v(c) is the value key for that SP. Otherwise v(c) is c.

Producer Example

Assume that the code is in a page and that its address space is built of an LSS 3 node with the code in slot zero and a private page at slot one. Assume that the source code is assembler and is kept in a smart segment.

Our first task is to define a value to correspond to the text deck. Note that this is a bit of detail that the normal developer would hopefully not need to cope with. We hope that after we have coped here with this detail we can hide it within a higher function, and all within the scope of the producer.

Assume a comp {perhaps primitive} that takes a segment key and a bank and returns a segment built of that bank containing the text deck for the source in the supplied segment.

From this comp we build an SP that takes a smart segment as a parameter(?).

This section wants to be an introduction to the above. It was written much later and it needs to be reconciled with the above.

The idea is to have a palpable object {such as the smart producer} that can produce some other object that embodies some fixed base value. Having an SP may be better than having the base object itself for reasons such as:

The SP might have some manifest durability.

The SP might be transportable to other Gnosis systems.

The SP might thus provide access to the service of some particular kind object subject to particular set of agreements which the SP is aware of and may be instrumental in enforcing.

If the base value is immutable then the SP might at times lend access to an object for that value which it keeps.

To an SP there are a variety of keys providing authority such as:

Read access to all data internals including signatures of each SP component.

Read access to all internals including keys to SP components (which are keys).

This would allow a mutable copy of the SP to be created and variants of the base object might be thus created.

All internals ciphered under a key which is in escrow somewhere.

Versions:
The pure form of the SP represents some value that is forever fixed. This corresponds, perhaps, to the idea of a particular release of a compiler and a level of bug fix for that release. That SP does not preclude the existence of another SP that supports a later release with new features or with the same features but with bugs fixed.

The above idea immediately suggests a variable SP that represents a changing value. Such changes may be either fewer bugs or new features. This would be especially useful while debugging code that either directly or indirectly supports the value. Such SP's would seem not to be transportable!

Is the difference between these two ideas the same as the difference between "REAL" and "REF REAL"?

Suppose a variant of PLIPACKER {(p3,preamble)} were to produce a "variable factory" which would be a "PROC KEY" that yields at a particular time the factory to the current object. By "current" I mean the version that corresponds to the current source, and the source that was source that was input to the plipacker that produced the factory key that is a factory component of this plipacker input.