Re: Package Parts [was: Ada GC and a bunch of other stuff]

[John G. Volan <John_Volan@ccmail.dayton.saic.com>]

In article <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com>,
Gene Ouye <geneo@rational.com> wrote:
>:John Volan <volan@BABYLON.DAYTON.SAIC.COM> wrote:
>:> (6) Here's a purely notational issue:  Personally, I dislike the notion
>:> of identifying a package-part by a number.  Part-numbers wouldn't convey
>:> any idea of the purpose that a programmer had in mind for each
>:> package-part.  I think using some kind of identifier would be a lot
>:> better, in terms of readability, self-documentation, etc.
>:
>:Actually, it's relatively simple to convey the purpose of each part of
>:the package.  Norm's proposal doesn't say the part numbers have to be
>:numeric literals, it says they're static universal integer expressions
>:(something I've seen too much of in another thread :-).  Assuming that
>:context clauses go in the same place that they do in Ada 95, all you
>:need to do is create a program configuration package (not to be confused
>:with a configuration pragma, although they may be applicable ;-).  In
>:the configuration package, you can define named numbers that will convey
>:both the purpose of the package part and the sequencing of the parts.
>:
>:> Of course, one of the things that Norman's syntax achieves is that it
>:> imposes a definite sequential order on the parts of a package.
>:> Furthermore, each package-part declares not only its own numeric
>:> position, but also the total number of package-parts in the sequence.
>:> (Presumably, all the package-parts would have to agree on this total.)
>:> Thus, within any package-part, it's always possible to know how many parts
>:> precede it and how many follow it.
>:
>:If you use named numbers for the part numbers, a cursory examination of
>:the package part source file wouldn't necessarily show how many parts
>:precede or follow the part.  You'd have to look in the configuration
>:package.  That would make it a little more difficult to find out how many
>:parts there were, but it would make it simple to change the number of
>:parts.  Of course, at compile time the package part will know how many
>:parts could potentially precede and/or follow it (it couldn't know for
>:sure unless there is some kind of requirement that there must be a part
>:corresponding to each number in the part number range).

Yes, I was assuming that there would be a consistency rule that said
that there would actually have to be a compilation unit in the library
for every part-name in the indicated set of part-names (whether that
set is implied by a total count as in Norman's syntax, or explicitly
enumerated as in my proposal).

>:This would also
>:make it easier to reorder the parts, although I would expect that to be
>:infrequent due to problems with the arbitrary rearranging of the
>:declarative region.  However, if there were some problems, they would be
>:found at compile time.
>:
>:> To achieve the same affects with identifiers instead of numbers, we'd
>:> need to be able to enumerate the identifiers of all the parts of a
>:> package somehow.  The order in which the identifiers appeared in this
>:> enumeration would determine the sequential order of the package-parts.
>:> The position of a package-part's identifier within the enumeration
>:> would determine the package-part's position within the sequence.
>:
>:I think named numbers achieves this, see the example.
>:
>:
>:   package My_Part_IDs is
>:      GUI            : constant := 1;
>:      Business_Logic : constant := GUI + 1;
>:      DBMS           : constant := Business_Logic + 1;
>:
>:      Total_Parts    : constant := DBMS;
>:   end My_Part_IDs;
>:
>:   with My_Part_IDs; use My_Part_IDs;
>:   package My_Package (Business_Logic of Total_Parts) is
>:      ...
>:   end My_Package;


For that matter, if we accept this notion of declaring the part-names in
a prior configuration package, then there's no particular reason why
the part names need to be named numbers.  I have suggested that the
part-names could be "enumerated" somehow. Although I didn't necessarily
mean for this "enumeration" to be an enumerated _type_ per se, this
configuration package idea would in fact allow us to use an actual
enumerated type for the set of part names.

Let's try out a hybrid of the syntax from Norman Cohen's proposal
and the syntax from my counter-proposal, combine it with this notion
of a configuration package, and see what we get:


    package Stack_Configuration is
        type Parts is (Interface, Completion);
    end Stack_Configuration;
    
    with Stack_Configuration; use Stack_Configuration;
    package Stack (Interface in Parts) is
        ...
    end Stack (Interface in Parts);
    
    with Stack_Configuration; use Stack_Configuration;
    package Stack (Completion in Parts) is
        ...
    end Stack (Completion in Parts);
    
    
    package body Stack is
        ...
    end Stack;
    

Like Norman's proposal, a part-id is placed in parentheses along with an
indication of the total set of part-ids from which it is taken. But
here the part-id is an enumeration literal and the set of part-ids is
indicated by the name of a previously-declared enumerated _type_. (Thus
the use of the keyword "in" conveying a sense of membership in a set, 
rather than the keyword "of".)   (Also, as in my counter-proposal, only
the package spec is split into parts; the package body keeps its distinct
syntax as in Ada 95.)

However, regardless of whether the part-names are enumeration literals
or named numbers, there's something a bit unsatisfying about having to
declare a separate configuration package first just to house the
part-names, before you can actually declare the target package in its
various parts.  I think it would be better if a package could remain an
autonomous, self-contained entity, regardless of whether it happens to
be decomposed into multiple parts or not.

What happens at the client level?  Before a client can "with" a specific
package part, it seems that it would also have to "with" (and "use") the
configuration package:

	with Stack_Configuration; use Stack_Configuration;
	with Stack (Interface in Parts);
	package Partial_Client is ...

Again, there's something unsatisfying about having to bring in this
configuration package before you can even mention the package-part
you want to "with".

>:Of course, you could also make the configuration package be the
>:parent of the parts, and define the part IDs there.

That might help alleviate some of the awkwardness, but I'd still prefer
it if a package-with-parts could be as "idempotent" as any other
package.  That's why I'd favor some kind of special syntax that would
allow a package to enumerate its parts, rather than using some kind of
conventional Ada declaration (like an enumerated type) that requires a
prior declarative region to be declared in.

With regard to possibly needing to re-order the package parts: I think
using an enumeration would actually be easier than a series of named
numbers.  All you'd have to do would be to change the order of the
enumeration literals in the type declaration, whereas in a cascade of
named numbers declarations not only do you have to change the order of
the declarations, but you also have to make sure that each one is
actually incremented from its new predecessor -- that might be quite
error-prone.

Another reason for favoring enumerations over named numbers is the
impact part names would have on Ada library management.  If package
parts were identified in the library by part-numbers, then re-arranging
the parts would force you to move all the parts to different
part-numbers.  (In terms of GNAT's source-file-based library management
scheme, the first package part would have to go in, say, a file called
*.ad1, the second in file *.ad2, and so forth, regardless of the names
we happen associate with those numbers; changing the order would
require moving the files to different names.)

On the other hand, if package parts were stored in the library under
part-names that were true identifier literals, presumably those
literals wouldn't have to change if we re-ordered the parts.  The only
thing that would change would be the positional order the compiler
associated with each literal.  (In GNAT terms, we could, for instance,
keep parts A and B of package P in files named, let's say, "p=a.ads"
and "p=b.ads". If we happened to switch the order of the parts so that
B came before A, we'd need to edit the enumeration declaration, but we
wouldn't need to rename the files.)

------------------------------------------------------------------------
 Me : Person := 
   (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
    Employer => "Science Applications International Corporation (SAIC)",
    Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
    Shameless_Commercial_Plug => 
      "RADSIM: Low-cost, real-time radar simulation *in Ada*   " &
      "Check out: http://www.dayton.saic.com/aso_homepage.html ",
    Humorous_Language_Lawyerly_Disclaimer => 
      "These opinions are undefined by my company, so any use of them" &
      "would be erroneous ... or is that a bounded error now? :-) " );
------------------------------------------------------------------------