Re: Ada language revision

[leake@cme-durer.ARPA (Stephe Leake)]

In reference to Stanley Allen's comments in message
<8811141420.AA01652@ajpo.sei.cmu.edu>, I agree completely.  However,
he did not give adequate references for me to go out and buy the
reading material he suggested, and I have the impression they are not
available in my corner bookstore. It seems to me that this forum is an
excelent place for us novices to propose changes, giving him and
others more knowledgeble a chance to spread some education. So, I am
responding to Wolfe's list of changes with my own opinions, and I hope
others do the same.

Note to future suggestors: please include the LRM section and
paragraph when suggesting a change to a specific rule.

In article <3563@hubcap.UUCP> billwolf@hubcap.clemson.edu (William
Thomas Wolfe,2847,) writes:

	 1) The assignment operator should be available for
	    overloading as part of an ADT specification...

Hear Hear! Right on! (and other assorted agreeable noises)

	 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?

	 3) The rule that a limited private type cannot be a direct
	    component of another limited private type should be
	    repealed...

What rule are you refering to? I have a Commented_IO package which
defines a limited private FILE_TYPE, which includes as a component
Text_IO.FILE_TYPE (also limited private). It compiles just fine.

	 4) It should be possible to overload generic packages with
	    differing generic parameter structures....

This sounds good. Currently, a better work-around is to have two
packages, both using a common lists sub-package.

	 5) The rule that functions must have only in parameters
	    should be repealed....

I have often wanted to do this myself, but I usually (not always) find
that a procedure ends up making more sense. In general, I find that
the restrictions Ada imposes usually lead to better code. (See my
personal gripes below for exceptions to this.)

	 6) Exceptions should be capable of being passed as
	    parameters....

What's wrong with a small if statement? Personally, I would like to
have an EXCEPTION_IO that would let me print the name of an exception.

	 7) Arrays should be initializable via named association...

According to LRM 4.3.2 (3), they are.

	 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? You
can't expect the compiler to do _everything_ for you!

Here are a couple restrictions that I would like relaxed:

	9) LRM 10.2 (5) states that the simple names of all subunits
that have the same ancestor library unit must be distinct. This means
I can have tasks named ROBOT.PLANNER.MAIN_TASK and
ROBOT.TRAJECTORY.MAIN_TASK, but only if the task bodies are not
separately compiled; then the simple name MAIN_TASK must be changed.
This seems contrary to the intent of Ada naming. If the rule where
changed to "the simple names of all subunits that have the same
_parent_ unit must be distinct", things would be nicer.

	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; ie, _not_ an object initalization. This prevents me
from declaring an object with an anonymous array type and initializing
it; which is exactly the correct thing to do for a state table in a
lexical analyzer. I do not want a named array type, since I do not
want any other state tables; I only need one.

	11) LRM 8.5 (2) lists the things that can be renamed. I would
like to add enumerals. I like to rename some things from a package
(usually with the same name) to make them visible, instead of "use"ing
the whole package; this makes it clear I am _not_ using the whole
package. Currently, to make an enumeral visible, I must declare a
derived type, which means I have to use explicit type conversions.

Well, that's probably enough for now.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899