Glossary FDLnotes

Abstract Identifiers - What are they really?

The notion of abstract identifier was introduced in Abstract Ids & Closed Maps. There it was explained that we mean them to be uniformly renamable, "unowned", atomic, and discrete.

Obviously the intent is to tightly restrict what operations may be performed upon them, but it has not been suggested how this can be accomplished or what values might be used for them.

If we were using a single programming language, we might borrow some method from it. For example, some programming languages admit the introduction of "abstract types" for which one can specify methods of creating new values and restrict the methods of access. Some programming languages have a concept of "pointer value" which is extremely similar to what we have in mind for abstract identifiers as object indices. Even in programming languages with no built-in methods for creating such values, programming practices are adopted for treating some values as abstract -- different executions of the program may generate different particular values, but the result may be the "same" (modulo which values get picked for these "abstract" types).

Using these programming methods one does not so much implement abstract values as one abstractly implements values. When one gets down to execution, one uses concrete values, but they are used with a discipline that makes the choice of values irrelevant to the desired effect.

But we do not intend to embed the FDL in a particular programming language environment. When an external process connects to the FDL, some concrete, externally understandable, values must be communicated instead. We cannot directly enforce a programming discipline upon external processes to have them treat identifiers abstractly; but we can stipulate that the choice of concrete values communicated by the FDL during a Session is undetermined prior to that session. In particular, if one stores a closed map, see Abstract Ids & Closed Maps, in one session and then attempts to retrieve it in a later session, there is no guarantee that the same closed map will be retrieved. The only guarantee is that it is an equivalent closed map, i.e. same modulo uniform change of values chosen for the "abstract" identifiers.

The freedom to uniformly rename identifiers permits various useful operations on closed maps, especially as regards combining independently or partially independently developed closed maps, maintenance of multiple versions, and pursuing alternative lines of development off pre-existing closed maps. The threat of uniform renaming encourages users to employ well known methods for treating these identifiers from the FDL abstractly, a discipline which cannot nowadays be considered onerous. If source code is stored in the FDL, then tests can be specified by Clients and applied to the source code to certify that it does treat the FDL identifiers abstractly. IF YOU CAN SEE THIS go to

Glossary FDLnotes