From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Ada language revision
Message-ID: <3656@hubcap.UUCP>
Date: 23 Nov 88 22:22:13 GMT
References: <733@marvin.cme-durer.ARPA>
Sender: news@hubcap.UUCP
Reply-To: wtwolfe@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <733@marvin.cme-durer.ARPA>, by leake@cme-durer.ARPA (Stephe Leake):
> In article <3563@hubcap.UUCP> billwolf@hubcap.clemson.edu (William
> Thomas Wolfe,2847,) writes:
> 
> 	 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...
> 
> This needs clarification; what does a DESTROY procedure do that
> UNCHECKED_DEALLOCATION doesn't?

      Consider an ADT which contains pointers to substructures.
      A user declares an access type pointing to an instance of your
      ADT, and uses UNCHECKED_DEALLOCATION to destroy that instance
      after finishing with it.  UNCHECKED_DEALLOCATION will not 
      recursively chase down and free up what might constitute 
      over 99% of the space occupied by the ADT.   Similarly, if your
      ADT uses another ADT in its implememtation, your DESTROY procedure
      will include a call to the DESTROY procedure of the sub-ADT,
      but UNCHECKED_DEALLOCATION will remain oblivious to the method
      which must be used to properly destroy the sub-ADT.

> 	 8) Record types should have the attributes NUMBER_OF_FIELDS,
> 	    FIELD_NAME (Field Number), and FIELD_TYPE (Field Number)....
> 
> This sounds good, but I suspect it would be difficult to handle
> [limited] private types and variant records. Does NUMBER_OF_FIELDS
> return the number for the current discriminant, or something else? 

      Generally, what I would like to do is be able to read everything
      about that record type that is contained in the type's description.
      We have attributes that allow us to know everything about an integer
      type, fixed type, float type, etc; we can tell what the bounds 
      of an array are, but we can't find out much of anything about records.
      ('FIRST_BIT, which tells us how far into the first storage unit 
      occupied by the record we have to go in order to find the first bit 
      of the record, and 'POSITION, which tells us how far past the first 
      storage unit occupied by the record we have to go in order to find 
      the specified component of the record, are the only attributes 
      pertaining specifically to the record)   Also, FIELD_TYPE was
      an error; I meant to say FIELD (Field Number), which would allow
      me to loop through the fields of a given record without knowing
      the names of the fields at compile time.
 
> Here are a couple restrictions that I would like relaxed:
> 
> 	10) LRM 4.3.2 (6) says if I have an array aggregate with named
> association and an others clause, it must be an actual parameter or
> function result; 

      This is what I meant about initializing arrays.  Thanks!