Re: Ada language revision

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

   In view of the recent discussions re: appropriateness of revisions, I'm 
   hereby submitting the revisions I think appropriate for Ada 9X for general
   discussion and/or flamage:

      1) The assignment operator should be available for overloading
         as part of an ADT specification (i.e., a limited private type 
         which is enclosed within a (usually generic) package).  Currently, the
         closest we can come is to define an ASSIGN procedure.  Unfortunately,
         this is not consistent with the use of := for other object types, and
         worse yet, the ASSIGN procedure is not invoked during the evaluation of
         in parameters, making it impossible to achieve anything other than a
         shallow copy of a user-defined ADT which is used as a value parameter,
         the disastrous implications of which should be readily apparent.

      2) Similarly, there is no provision for defining the DESTROY procedure
         over an abstract data type such that UNCHECKED_DEALLOCATION is required
         to invoke it.  Again, we have inconsistency with the predefined 
         objects, and there are unfortunate implications for space efficiency.

      3) The rule that a limited private type cannot be a direct component of 
         another limited private type should be repealed.  This makes it hard
         to use one ADT as a building block in the construction of higher-level
         ADTs.  The standard workaround is to use an intervening pointer, with
         negative implications for time and space efficiency upon each access.

      4) It should be possible to overload generic packages with differing 
         generic parameter structures.  For example, suppose I have two
         generic linked list requirements: sometimes I need the ability to
         INPUT and OUTPUT the list to a file, and sometimes I don't.  If I
         can't overload the package with differing generic parameter structures,
         I'll have to include the procedures INPUT (LINKED_OBJECT) and 
         OUTPUT (LINKED_OBJECT) in every instantiation of a linked list;
         even if I have no intention of ever calling the INPUT and OUTPUT 
         procedures for this particular type of linked list.  Result: more work
         on my part to define unnecessary INPUT and OUTPUT procedures which will
         never be called, and possibly an unnecessarily large body of 
         instantiated code which contains code to handle procedures that I will
         never call. 

      5) The rule that functions must have only in parameters should be 
         repealed.  Data structures which are history-sensitive, such as tree
         structures which secretly keep a "current item" pointer in order to
         speed up groups of requests which all involve the same item, will
         subtly change as a result of calls to the Boolean function ITEM_EXISTS;
         this forces us to use an intervening pointer in order to implement
         such a function with only in parameters, and suffer the resulting time 
         and space penalties upon each and every access to the structure. 
 
      6) Exceptions should be capable of being passed as parameters.  Currently,
         it is not possible to write a function ASSERT which takes a Boolean
         expression and an exception, and raises the exception if the expression
         turns out to be false.  The workaround is to enclose every call to 
         ASSERT in a local block, with an exception handler specifying that
         the desired exception should be raised in response to the exception
         Assertion_Failed.

      7) Arrays should be initializable via named association.  It is very 
         tedious to write out 37 Falses simply in order to initialize the
         38th element of a Boolean array to True before I can finally specify 
         that all other elements of the array are False. 

       8) Record types should have the attributes NUMBER_OF_FIELDS, 
          FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).  Not having
          these attributes prevents the construction of a generic report
          generator which will accept a record type as a generic parameter,
          and provide a function GENERATE_REPORT which, given a file of those
          records, will automatically generate a report in which the column
          headers are labeled with the field names (with spaces substituted for
          underscores), and automatically laid out across the page with the
          appropriate spacing between columns.  Assuming the availability of an
          appropriate system call, the name of the source file could even be 
          used as the report title.   But without being able to read that record
          descriptor, the implementation of such a generic report generator is
          very hard to achieve in any reasonably clean way. 


   Well, there they are.   Now where was that fireproof outfit...?


                                                   Bill Wolfe

                                             wtwolfe@hubcap.clemson.edu