|__________________________________________| Figure 4-17
VALUE After L/OPEN/MEMBER
_________________ _________________
| _____________ | | _____________ |
| | M | | | | STRUC | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
_____|_|____ | | DESCRIPTION |
| | |_____________| | |
| | VALUE | ____________V____
| | _____________ | | _____________ |
| | | | | | | STRING | |
| | |_________|___| | | |_____________| |
| | CHILD | | ___\| TYPE | _____________
| |___________|_____| | /| _____________ | | _________ |
| OBJECT | | | | ____|_|______\| | STRING | |
| | | | |_____________| | /| |_________| |
| ___________V_____ | | SIBLING | | TYPE |
| | _____________ | | |_________________| |_____________|
| | | A | | | DESCRIPTION DESCRIPTION A
| | |_____________| | | |
| | NAME | | _________________ |
| | _____________ | | | _____________ | |
| | | ____|_|__| | | B | | |
| | |_____________| | | |_____________| | |
| | DESCRIPTION | | NAME | |
| | _____________ | | _____________ | |
| __|_|____ | | | | ____|_|___________________|
| | | |_____________| | | |_____________| |
| | | VALUE | | DESCRIPTION |
| | | _____________ | | _____________ |
| | | | ____|_|______\| | | |
| | | |_____________| | /| |_____________| |
| | | SIBLING | | VALUE |
| | |_________________| |_________________|
| | OBJECT OBJECT
| |___________
| |
| ________|_________________________________
| | ______V______ _____________ |
|____\| | "AB" | | | |
/| |_____________| |_____________| |
|__________________________________________| Figure 4-18
VALUE After first L/ASSIGN
_________________ _________________
| _____________ | | _____________ |
| | STAR | | | | OPF | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |___________|_| |
| CHILD | | | VALUE | |
|___________|_____| |_____________|___|
OBJECT | OBJECT |
___________V_____ _____________V___
| _____________ | | _____________ |
| | F | |/______|_|____ | |
| |_____________| |\ | |_____________| |
| NAME | | LIST |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |___________|_| |
| VALUE | | | MEMBER | |
|___________|_____| |_____________|___|
OBJECT | VALUE | OPD
| _____________V___
______________V_________ | _____________ |
| ______________________ | | | M | |
|| _________ _________ || | |_____________| |
||| "AB" || "CD" ||| | NAME |
|||_________||_________||| | _____________ |
||______________________|| | | | |
| / | | |___________|_| |
| / | |_____________|___|
|_______________/________| OBJECT |
VALUE / / _____________V___ _________________
/ / | _____________ | | _____________ |
/ / | | | | | | B | |
/ LIST | |_____________| | | |_____________| |
/ | NAME | | NAME |
/ | _____________ | | _____________ |
NEW MEMBER VALUE | | ____|_|_____\| | | |
| |_____________| | /| |_____________| |
|_________________| |_________________|
OBJECT OBJECT
Figure 4-19
After L/CLOSE/MEMBER
By executing similar groups of four primitives, varying only values of
constants, we can build up the LIST F shown in 4-20. The calls required
are shown below:
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('FF'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('GH'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('AB'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('IJ'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('CD'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('LM'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
The add suboperation has the effect of making the member just added, the
current member; thus no L/WHICH/MEMBER calls are needed in this
sequence.
To terminate the sequence of listops:
L/END/LISTOP(L/TOBJ(OPF))
_________________
| _____________ |
| | F | |
| |_____________| |
| NAME |
| _____________ |
| | ____|_|_________\
| |_____________| | /
| DESCRIPTION |
| _____________ |
| | | |
| |_________|___| |
| VALUE | |
|___________|_____|
OBJECT |
|
_______________V______________
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "AB" | | "CD" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "EF" | | "GH" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "AB" | | "IJ" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "CD" | | "LM" | | |
| | |_________| |_________| | |
| |__________________________| |
|______________________________|
VALUE
Figure 4-20
After L/END/LISTOP
A slightly more interesting exercise is to construct calls which create
a LIST named G, having the same description as F, and then to copy into
G all members of F having A equal to 'AB'.
We must first create G, an OPD and an object to represent the current
member.
L/CREATE("STAR",LD/LIST(G,
LD/STRUCT(R,
LD/STRING(A,STRING,2),
LD/STRING(B,STRING,2)))
L/CREATE(L/TOBJ(TOP/LEVEL),LD/OPD(OPG))
L/CREATE(L/TOBJ(TOP/LEVEL) ,LD/STRUCT(GM,
LD/STRING(A,STRING,2),
LD/STRING(B,STRING,2)))
We now need to initiate two sequences of listops, one on G and one on F.
L/BEGIN/LISTOP(L/POBJ(F),L/TOBJ(M),
L/TOBJ(OPF),GET)
L/BEGIN/LISTOP(L/POBJ(G),L/TOBJ(GM),
L/TOBJ(OPG),ADD)
L/WHICH/MEMBER(L/TOBJ(OPF),FIRST)
L/WHICH/MEMBER(L/TOBJ(OPG),LAST)
We will now sequence through the members of F; whenever the current
member has A equal to 'AB', we will add a member to G. We then copy the
values of the current member of F into the newly added member of G.
When the current member does not meet this criterion, we do nothing with
it.
First, to write a loop that will execute until we get to the end of F:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),x)
Whatever we put in this call to replace "x" will execute repeatedly
until the end/of/list flag has been set in OPF.
We must replace "x" with a single function call to in order to give
L/TILL what it is looking for. However, we will be executing "x" once
for each member of F, and will need to execute several listops each
time. The solution is to use L/CF, the compound-function function:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),L/CF(y))
We can now replace "y" with a sequence of function calls.
Each time we iterate, we need to process a new member of F; initially we
are set up to get the first member. The following sequence, then, is
needed:
L/CF( L/OPEN/MEMBER(L/TOBJ(OPF),GET),
z
L/CLOSE/MEMBER(L/TOBJ(OPF)),
L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) )
The above is a compound function which will open the current member of
F, do something to it (represented above by "z"), close it, and ask for
the next member.
We want to replace "z" by a function call which tests the contents of A
in the current member of F, and either does nothing or adds a member to
G, copying the values of the current member of F. If "w" represents the
action of adding a member to G and copying the values, then we can
express this:
L/IF(L/EQUAL(L/TOBJ(M.A),LC/STRING('AB')),w)
A suitable way to express "add a member and copy values" is:
L/CF(L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
L/CLOSE/MEMBER(L/TOBJ(OPG))
This is similar enough to the previous example so that no explanation
should be necessary.
Putting this all together, we get:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),
L/CF( L/OPEN/MEMBER(L/TOBJ(OPF),GET),
L/IF(L/EQUAL(L/TOBJ(A),LC/STRING('AB')),
L/CF( L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
L/CLOSE/MEMBER/L/TOBJ(OPG)) ) )
L/CLOSE/MEMBER(L/TOBJ(OPF)),
L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) ) )
To conclude the operation, we execute:
L/LISTOP/END(L/TOBJ(OPG))
L/LISTOP/END(L/TOBJ(OPF))
The result is a LIST G whose first member has value ('AB','CD'), and
whose second member has value ('AB','IJ'). With a few variations on the
above example, quite a few LIST operations can be performed.
4.11 Higher level functions
While these primitive i/functions are useful, we would not ordinarily
expect users to operate in datalanguage at this low level. We want to
make these primitives available to users so that they can handle the
exceptional case, and so that they can construct their own high-level
functions for atypical applications. Ordinarily, they ought to operate
at least at the level of the following construction (which is legal in
the real datalanguage currently implemented):
FOR G.R,F.R WITH A EQ 'AB'
G.R=F.R
END
This relatively concise expression accomplishes the same result as the
elaborate construction of i/functions given at the close of the
preceding section. We could define i/functions very similar to the
semantic functions used in the running software, and write the above
request as:
L/FOR(L/POBJ(G),R
L/POBJ(F),R,L/WITH(L/EQUAL(L/TOBJ(A),
LC/STRING('AB')))
The differences between the i/function call and the datalanguage request
above it are principally syntactic.
In designing functions such as L/FOR and L/WITH, the central problems
have to do with choosing the right restrictions. One cannot have all
the generality available at the primitive level. Some important choices
for these particular functions are: (1) handling multiple inputs and
outputs, (2) when FORs are nested, how outer FORs restrict the options
available to inner FORs, (3) generality of selection functions (may then
in turn generate FORs?), (4) options with regard to where processing
should start (are we updating, replacing or appending to the output
list(s)?).
Finally, this problem is related to the more general problem of dealing
with _sets_, which are a generalization of the idea of a collection of
members in a LIST having common properties. FOR is only one of many
operators that can input sets.
4.12 Conclusion
The present model, though embryonic, already contains enough primitives
and data types to permit definition and generalized manipulation of
hierarchical data structures. Common data management operations, such
as retrieval by content and selective update can be expressed.
The use of this model in developing these primitives has resulted in
precise, well-defined and internally consistent specifications for
language elements and processing functions. Operating in the laboratory
environment provided by the model seems to be a substantial benefit.
5. Further Work
In this section, we review what has been accomplished so far in the
design and describe what work remains to be done before this design
iteration of datalanguage is complete.
5.1 A Review
Most important, among our accomplishments, we feel that we have
delineated the problems and presented the broad outlines of a solution
to development of a language for the datacomputer system. Key elements
of our approach are the primacy of data description in capturing all the
aspects of the data, the separation of logical and physical
characteristics of data description, the ability of users to define
different views of the same data, the ability to associate functions
with different uses of data items, an attempt to capture common aspects
of data at every possible level, and the ability of users to communicate
with the datacomputer in as high a level as their application permits.
5.2 Topics for Further Research
Although more work needs to be done in general to turn out a finished
design for datalanguage, we can single out certain issues which in
particular need further investigation.
So far, only hierarchal data structures (i.e. those that can be modeled
by physical containment) have been developed to any extent. We also
intend to investigate and provide other types of data structures. We are
confident that our language framework does not make assumptions that
would prohibit such additions.
Our current work on access regulation centers on the use of multiple
descriptions for data. We need to do more work on both the technical
and administrative aspects of access regulation. Problems of encrypting
data for both transmission and storage will also be investigated.
Another issue requiring further research is the protocol requirement for
process interaction with the datacomputer.
Separation of the description into independent modules needs further
research. In particular, we need to look into work which has already
been done on separate specifications of logical descriptions, physical
descriptions, and mappings between the two.
5.3 Datalanguage Syntax
We have not yet proposed a syntax for the datalanguage we are
developing. Certainly the most difficult parts of the problem have been
the semantic and pragmatic issues. We are confident that various
syntactic forms can be chosen and implemented without excessive
difficulty. It may be best to develop different syntactic forms for the
language for different types of users or even for the various subparts
of the language itself. As discussed in section 2, the user syntax for
the datacomputer is supposed to be at a low level. It should be easy
for _programs_ to generate datalanguage requests in this syntax.
5.4 Further Work on the Datalanguage Model
The model provides an excellent foundation on which to build up a
language with the facilities described in section 3. Much work is yet
to be done.
For a while, emphasis will be on sets, high-level operators, language
extension and data description.
We expect to model sets as a new datatype, whose value is ordinarily
shared with other objects. Some further work on binding and sharing of
values is needed to support this.
Sets can be regarded as a special case of generalized relations, which
will come somewhat later.
High-level operators such as FOR will be constructed from the existing
primitives, and will eventually be defined to have one effect but
several possible expansions. The expansion will depend on the
representation of the data and the presence of auxiliary structures.
Alternate expansions will be possible when the data description has been
broken up into its various modules. This, also, requires some further
research.
We feel that the language extension problem is much more easily attacked
in the environment provided by the model datacomputer. In particular,
we expect the laboratory environment to be helpful in evaluating the
complex interactions and pervasive effects of operators in the language
which extend the language.
Data description work in the near term will focus on the isolation of
attributes, the representation of variable structure in description, the
description of descriptions and the development of a sufficient set of
builtin data types.
Later, we expect to model the semantics of pointers as a datatype, when
the representation of the pointer and the semantics of the address space
into which it points are specified in the description of the pointer.
A large number of lower-level issues will be attacked, including some of
the problems discovered in the modeling to date. Some of these are
pointed out in the discussions in section 4.
5.5 Applications Support
The datalanguage we are designing is intended to provide services to
sub-systems solving a broad class of problems related to data
management. Examples of such sub-systems are: report generators, online
query systems for non-programmers, document-handling systems,
transaction processing systems, real-time data collection systems, and
library and bibliographic systems. There are many more.
The idea is that such systems will run on other machines, reference or
store data at the datacomputer, and make heavy use of datalanguage.
Such a system would not be written entirely in datalanguage, but a large
component of its function would be expressed in datalanguage requests;
some controlling module would build the requests and perform the non-
datalanguage functions.
While we have experience with such applications in other environments,
and we talk to potential users, it will require some work to determine
that our language is actually adequate for them. That is, we are not
attacking directly the problem of building a human-oriented online query
system; we are trying to provide the tools which will make it easy to
build one. There is a definite need to analyze whether the tools are
likely to be good enough. Of course, the ultimate test will be in actual
use, but we want to filter out as many problems as we can before
implementation.
An important component of supporting applications is that the using
programs will frequently be written in high-level languages such as
FORTRAN, COBOL or PL/1. We will want to investigate the ability of
datalanguage to support such users, while the design is taking shape.
5.6 Future Plans
This paper has laid the foundations for a new design of datalanguage.
Section 3 provides an outline for a datalanguage design, which will be
filled in during the coming months. Following the issue of a detailed
specification, we anticipate extensive review, revisions, and
incorporation into the implementation plans. Implementation will occur
in stages, compatible with the established plans for development of
datacomputer service and data management capabilities.
[ This RFCwas put into machine readable form for entry ]
[ into the online RFCarchives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 1/2000 ]