RFC 195 (rfc195) - Page 2 of 4


Data computers-data descriptions and access language



Alternative Format: Original Text Document



RFC 195                      Data Computers                    July 1971


      4. Data items in files may be stored in arbitrary representations
         (e.g., those of the originating user's HOST rather than that of
         the data computer or other "standard" representation).

      5. Access to a file will normally be to some subset of it. (I.e.,
         the unit for transmission will usually be part of a file rather
         than the whole file, and access will not necessarily be
         sequential).

   Consequences
   ------------

      1. A method of data description significantly more powerful than
         now commonly available (as with COBOL or PL/I) is required.
         The descriptions must be stored with the files.  Data item
         representations and storage organizations must be describable.

      2. The data computer must offer a "data reconfiguration service",
         based on use of the data descriptions.

      3. A representation and organization-independent level of
         discourse must be made available for controlling access.

   Data Description
   -----------------

   As it happens, the descriptive facilities in ELl (References 1 and 2)
   are almost adequate as they stand.  ELl is an extensible language --
   the compiler and interpreter for ELl are principal components of a
   system implemented on the PDP-lO at Harvard -- which allows the
   definition of arbitrary data structures in terms of a few primitive
   data types (BOOL, CHAR, INT, REAL, SYMBOL, MODE, FORM, and ROUTINE).
   These data types are of the sort I called "generic" in Reference 3.
   To the EL1 implementation on the PDP-10, say, we would have to add
   methods to describe a specific representation of INT, etc. and
   primitive routines to convert between specific representations.

   In the ECL system (in which EL1 is embedded), there is no rigid
   distinction between compile time and run time.  In particular, if the
   arguments and free variables of a routine are evaluable at compile
   time, then the routine is evaluated and the value replaces the call.
   More generally, arbitrarily large amounts of a routine being compiled
   may collapse into values.  As far as the data computer is concerned,
   this offers the possibility of producing tailor-made data
   reconfiguration programs, taking maximum advantage of the data
   descriptions at compile time rather than using a strictly
   interpretative mode of operation.




Healy