Naming and Binding
This is the core of Membrane Technology. To name something is to define it and distinguish it from what is not that, to give is a sign by which an object can be known to interpreters.
Here is a first cut at a diagram for this:
Lower level Binding live in the various contexts. Name interpretation is typically spread out with each context having one or more layers of names and bindings. This is suggestive that it will be desirable from the standpoint of modularity and flexibility, not to mention DRY principles to settle on several core naming system conventions and APIs to handle all aspects of naming and binding. The code may still be spread out in each storage context, but all contexts will share core mechanisms for handling names and binding them to data.
The membrane manages naming: the syntax and interpretation of names, and binding: the association of names with entities
(We had: [address at a different level] in a scope, but I would associate entities with the symbol, which could be a digital representation of the entity. In currencies, data objects can be the "real thing")
In a human interpreter, the sign can bring forth many bindings, including feelings, body reactions to the presence of the sign of a dangerous symbol.
Rules of
Naming
Independent of what is being named, names have structure, syntax and semantics. This is the intensive side of, how it points, rather that what it points at.
Typical representational stack:
Octet-string -> (ASCII, LANTIN1, UTF-8, or URL-encoded ...) -> Words and Gestures
Words - Language and Alphabet, declenations, quotes, appostrophe and case
Gestures - Whitespace and punctuation up to mathematical figures
Segmented names (e.g. filesystem paths, card names, URLs, expressions) are processed by an name interpreter, and different segments of the name can be presented to different subsystems for interpretation. This segmentation may or may not be apparent in the syntax, and it may relate to selecting a scope or other naming conventions.
Rules of
Binding
Context - A set of bindings
Binding - An association of a Name and Object
Scope - A lexical or execution subcontext. Interpreters create a complete Context by combining a number or Scopes searched in a determined order where a binding in one may mask the same name in another.
Object - Context dependent, see below.
In most contexts, the names in a context must be unique.
What is being bound?
It really can depend on the context. In an interpreter that is an object oriented program, the names resolve to memory addresses whether statically allocated in the interpreter or dynamically on a heap or stack. A cardname defines a card model instance in a Rails app and an ActiveRecord record in a SQL database. That cardname will also have a URL, so it can be accessed as a webpage.
MCP is just like any other programming language context in that names are for data objects, but they will appear in different forms when the data has been translated into different contexts (e.g. from Ruby Rails model code to URLs for external access). We need to decide what the universal currency object is. As in what a "card" is for Wagn. Do we really want to use "Pattern"? We may just call them "pattern objects" then either term can apply depending on context.
Storage - (cached? virtualized?) Not sure if this is actually part of binding. It may be that these are implementation issues related to bound objects, therefore they may be present in the internal APIs, but not the protocol and required interfaces.
Execution Context - server, client, cookie, distributed, ?
Example: Sargeant or Major (rank) is a name that binds a player to a capacity. The name "Major" is bound to something that the armies define. If an army binds that name to a human, that binds the human to that role in that army.