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

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

[Ken & Virginia Garlington]

Norman H. Cohen <ncohen@watson.ibm.com> wrote:
> Here is a half-baked proposal for Ada 0X: Allow a package to consist
> of a sequence of compilation units of the form
>
>    "package" name "(" expression "of" expression ")" "is"
>       { declaration }
>    [ "private "
>       { declaration }
>    [ "begin"
>       handled_sequence_of_statements ]
>    "end" name "(" expression "of" expression ")" ";"

I missed the post describing the rationale for this proposal; could
some one repost it?

I have one question which may have already been answered. If you
have a package in five parts, as in the original example, would you
ever add a sixth part? If so, having to change all the other package
names would seem to be counter-productive from a maintenance standpoint.

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

[John G. Volan]

In article <31273ED6.B9B@flash.net> Ken & Virginia Garlington,
redhawk@flash.net writes:
>Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>> Here is a half-baked proposal for Ada 0X: Allow a package to consist
>> of a sequence of compilation units of the form
>>
>>    "package" name "(" expression "of" expression ")" "is"
>>       { declaration }
>>    [ "private "
>>       { declaration }
>>    [ "begin"
>>       handled_sequence_of_statements ]
>>    "end" name "(" expression "of" expression ")" ";"
>
>I missed the post describing the rationale for this proposal; could
>some one repost it?

In the interest of bandwidth, rather than re-posting, I'll email you the
original post (and my follow-up to it).  But here's the gist of the
rationale, as I see it:

Norman Cohen was responding to a post from Henry Baker that was
generally bemoaning the "arbitrary restrictions" imposed by Ada's
syntax rules. Among other things, Henry voiced a criticism about the
arbitrary ordering Ada imposes on declarations in a package spec: All
the public declarations have to come first, and all the private
declarations come after the keyword "private". There's no way to
interleave public and private declarations in a way that's analogous to
the "public:" and "private:" clauses in a C++ class declaration.

Norman's proposal was in part a response to this criticism.  Although
his "package-part" syntax retains the ordering rule that puts all the
public declarations before all the private declarations, you can still
interleave public and private sections of a package by dividing it into
several package-parts.

However, Norman's proposal also attempted to tackle a couple of other
issues:

(1) Ada currently doesn't provide the capability to separately compile
the public and private parts of a package spec, but it would be quite
useful if it did.  For one thing, it would reduce recompilation
dependencies. From a design point of view, the full completion of a
private type within the private part of a package spec represents a
portion of the implementation of an abstraction.  One's first instinct
might be that such implementation details ought to go into the package
body. But an Ada compiler needs to be able to get the completion of a
type from the package spec, because it needs to be able to implement
things like a client declaring an instance of the private type, or
deriving a new type from it, etc.  But suppose we could separate the
public and private parts of a package spec.  Then we could at least
distinguish "partial" clients that only needed to "with" the public
part, from "full" clients that needed to "with" the private part as
well.  That way, if the implementation of a private type needed to be
changed later, only the "full" clients would need to be recompiled.

If the public and private parts could be separate compilation units,
presumably they could each have context clauses of their own.  As it
stands now, sometimes a package spec is forced to "with" some program
unit that it needs for its private part, but not for its public part. 
Even though a client sees nothing in the public interface of the
package that involves this "with" clause, it nevertheless becomes
dependent on that "withed" program unit.  This might be unavoidable for
"full" clients, but it would be nice if we could avoid this dependency
for "partial" clients.

Also, if the public and private parts of a package spec could be managed
as separate operating-system files, then this would simplify some
aspects of the configuration management of packages.  For instance, an
abstraction might need different implementations when ported to
different platforms.  The public part of the package spec for this
abstraction would be identical for all platforms, but the package body
and the private part of the spec would need to be different on each
platform.  It would be nice if we could leave the file that contained
the public part untouched, and just swap in new files for the private
part and the body when porting.

(2) Ada currently doesn't provide the capability to separately compile
an incomplete forward-declaration of a type, but it would be quite
useful if it did.  This would solve the problem of how to declare two
mutually-dependent tagged types in separate packages without running
into the "withing" problem -- the chicken-and-egg dilemma of two
package specs both trying to "with" each other.

I once proposed the notion of a "package-abstract": an optional,
separately-compilable part of a package, prior to the package-spec, in
which incomplete declarations could be tolerated, on the assumption
that their completions would eventually appear in the package-spec.  A
client could choose whether to "with" the whole package-spec or just
the package-abstract.  Mutually-dependent package-specs would not need
to "with" each other, they could get by with just "withing" each
other's package-abstracts.

Norman's "package-parts" proposal is a neat generalization of this idea.
Any package-part can play the role of one of my "package-abstracts,"
if it happened to contain an incomplete declaration that wasn't
completed until a later package-part.

------------------------------------------------------------------------
 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? :-) " );
------------------------------------------------------------------------

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

[John G. Volan]

In article <4gfmli$n0l@dayuc.dayton.saic.com> John G. Volan, 
John_Volan@ccmail.dayton.saic.com writes:
>Also, if the public and private parts of a package spec could be managed
>as separate operating-system files, then this would simplify some
>aspects of the configuration management of packages.  For instance, an
>abstraction might need different implementations when ported to
>different platforms.  The public part of the package spec for this
>abstraction would be identical for all platforms, but the package body
>and the private part of the spec would need to be different on each
>platform.  It would be nice if we could leave the file that contained
>the public part untouched, and just swap in new files for the private
>part and the body when porting.

It should be pointed out that the folks at ACT are planning to have GNAT
provide something close to this capability, without changing the
language. They're going to exploit the fact that the equation

    1 Ada compilation unit = 1 operating system file

is _NOT_ explicitly required by the language.  GNAT will soon allow you to
split an Ada package spec into a *.ads file containing everything up to
and including the keyword "private" (i.e., the public part of the
spec), and a *.adp file containing the rest (i.e., the private part of
the spec).

However, the two files together will still count as a single compilation
unit.  In other words, my guess is that GNAT will do little more than
some text pre-processing, combining a *.ads with *.adp to generate a
single file that is fed to the front end.

This in itself will be useful, since it will allow the private part to
be treated as a separate item for configuration management purposes. 
However, there are some desirable features that this will _not_ provide:

(1) You won't be able to just "with" the *.ads.  A "with" clause means
that you're importing the whole compilation unit, including both the
contents of the *.ads file and the *.adp file.

(2) Unless the ACT folks intend to implement some fancy text-shuffling,
a *.adp file will not be able to have its own context clause.  If they
go with a naive implementation that merely concatenates the *.ads with
the *.adp, then the top of the *.ads file will have to contain all the
"with" clauses for the package spec, including those that are only
needed for the private part (and that presumably would be different for
each different version of the *.adp).

------------------------------------------------------------------------
 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? :-) " );
------------------------------------------------------------------------

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

[John G. Volan]

In article <31273ED6.B9B@flash.net> Ken & Virginia Garlington,
redhawk@flash.net writes:
>I have one question which may have already been answered. If you
>have a package in five parts, as in the original example, would you
>ever add a sixth part? If so, having to change all the other package
>names would seem to be counter-productive from a maintenance standpoint.

IMHO, adding a new part to an existing package would mean that you were
making a profound change to the structure of the package.  Remember
that the parts are supposed to constitute a single extended declarative
region with an explicitly prescribed sequence.  Inserting a new part at
the beginning or middle of this sequence affects all the following
parts, but even adding a part onto the end of the sequence might have
an affect on the preceding parts.  I would not be surprised if this
forced you to revisit the other parts for reasons beyond just changing
their names.  (Actually, it's not their "names" that would change.
Rather, it's whatever clauses they each use to indicate the total set
of parts they all belong to -- in Norman's syntax, it would be the "of
Total" clauses).  Indeed, I'd be suspicious if the language allowed you
made such a profound change _without_ carefully revisiting the other
parts.  At the very least, the other parts would need to be recompiled.

As an analogy, consider what happens if you, say, add a new procedure
declaration into an existing package spec.  Ada will force you to
revisit the existing body of the package and add the corresponding
procedure body.  Is being forced to do this "counterproductive"?  It
does take a certain amount of effort to write that procedure body, but
isn't it worth it to keep the spec and body of a package consistent
with each other?  What would the cost be in maintainability if Ada were
more lax about this?  (Is it true that you can declare a member
function in C++ and then neglect to implement a "body" for it?  If so,
what's the cost in debugging time to catch this kind of error?)

(Contrast this with adding a new child unit into an existing hierarchical
library. That change should not affect existing parent and child units
any more than introducing an unrelated package would.  At worst, a new
child unit might try to exploit internal details of its parent in ways
that would cause parent code to break when both are linked into the
same program, but the mere existence of a new child unit would not, for
instance, require the parent unit to be re-compiled.)

------------------------------------------------------------------------
 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? :-) " );
------------------------------------------------------------------------

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

[John G. Volan]

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? :-) " );
------------------------------------------------------------------------

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

[John G. Volan]

In article <4gh2da$ffb@dayuc.dayton.saic.com> John G. Volan,
John_Volan@ccmail.dayton.saic.com writes:
>...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.

How about this 7/8-baked counter-counter-proposal for Ada 0X? :-)

Introduce a new kind of compilation unit called (let's say) a "package-spec
configuration unit", with the following syntax perhaps:

    package <name> separate ( <identifier> {, <identifier> } );
    
For instance, here's the configuration unit for the Stack package example:

    package Stack separate (Interface, Completion);
    
This unit provides one handy place where all the package-spec-parts can
be enumerated.  Each individual package-spec-part implicitly imports
this unit, and does not need to repeat the enumeration.  Then we could
have the following syntax for a package-spec-part:

    package <name> ( <identifier> ) is
        { <basic-declaration> ; }
    private
        { <basic-declaration> ; }
    end <name> ( <identifier> );
    
For example, the parts of the Stack package-spec would be:

    package Stack (Interface) is
        type Object is ... private;
        ...
    end Stack (Interface);
    
    package Stack (Completion) is
    private
        type Object is ... [full type declaration];
        ...
    end Stack (Completion);
    
If a compiler saw this <name>(<identifier>) syntax, it would know that it
was dealing with a package-spec-part, so it would look for the package-spec
configuration unit in the library.  That would enable it to determine
the part's position in the sequence of parts, as well as the prior
parts implicitly "withed" into that part.

For backwards compatibility with Ada 95, we'd still support the existing
syntax of single-part package specs, but this syntax would be
mutually-exclusive with the multi-part syntax -- either you have a
simple package spec, or you have one of those configuration units and
the corresponding package-spec-parts.

We'd also have the following alternative syntax for a "with" clause:

    with <name> ( <identifier> );
    
For example, a "partial" client of Stack could be:

    with Stack (Interface);
    package Partial_Client is ...
    
and a "full" client could be:

    with Stack (Completion);
    package Full_Client is ...
    
but given that Completion was the last part in the sequence, this would
be considered equivalent to:

    with Stack;
    package Full_Client is ...
    
A GNAT-like compiler could use a source-file naming convention something
like the following:

- p.ads would either contain a conventional single-part package-spec
  for package P, or it would contain a package-spec configuration unit
  for package P.
  
- In the latter case, for every part-name X enumerated in p.ads, there
  should be a file p,x.ads containing package-spec-part P(X).
  (Note: I'm using "," to separate the part name vs. GNAT's "-" for child
  units.  Various UNIXes I've tried seem to accept this, but I don't know
  whether other OS's (DOS, etc.) will like it.)
  
- When a client says "with P;", the compiler will look for p.ads.  If it
  finds an ordinary package spec there, it procedes as usual.  But if it
  finds a package-spec configuration unit instead, the compiler will 
  procede to "with" the whole sequence of p,x.ads package-spec-parts.
  
- When a client says "with P(X);", the compiler will look for p,x.ads. 
  It will also get file p.ads so it can determine P(X)'s position in
  the part sequence; it then will get the appropriate files for all
  the parts prior to P(X).

------------------------------------------------------------------------
 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? :-) " );
------------------------------------------------------------------------

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

[Robert A Duff]

I'll cc this to report@gnat.com, in case they're interested.

In article <4gglnj$9r8@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>It should be pointed out that the folks at ACT are planning to have GNAT
>provide something close to this capability, without changing the
>language. They're going to exploit the fact that the equation
>
>    1 Ada compilation unit = 1 operating system file
>
>is _NOT_ explicitly required by the language.

Actually, the equation that most Ada 83 compilers followed was
"1 Ada compilation = 1 operating system file".  Until GNAT came
along, everybody seemed to assume this.  Although it's not required
by the RM, the RM certainly implies that this was the intent, so it's
not surprising that everybody did it that way.  I'm glad the GNAT folks
have recognized that it's possible to be more flexible.  (Actually, GNAT
is *less* flexible, in that they disallow multiple compilation units per
file, but the case we're talking about here, of allowing the private
part to be split out, is *more* flexible.)

>(2) Unless the ACT folks intend to implement some fancy text-shuffling,
>a *.adp file will not be able to have its own context clause.  If they
>go with a naive implementation that merely concatenates the *.ads with
>the *.adp, then the top of the *.ads file will have to contain all the
>"with" clauses for the package spec, including those that are only
>needed for the private part (and that presumably would be different for
>each different version of the *.adp).

Yeah, this issue is a bit tricky.  It is clearly desirable for the
private part to have its own with_clauses.  (In fact, I consider
the lack of this feature to be a language design flaw.)

Now suppose GNAT allows that, and does some fancy text shuffling.
That is, they move the with_clauses up to the front.  Well, that's
certainly allowed by the RM (nobody says you have to store your
code in any particular form).  But it's undesirable, because it
means that the foo.ads file can refer to things that are not
mentioned in that file's with_clauses, but only in the corresponding
foo.adp file.

On the other hand, one might consider making the with_clauses in the
foo.adp file just apply to the private part.  That seems logical, but it
would be an incorrect implementation of Ada, because then if somebody
moved the with_clauses up, and concatenated the two files together, in
order to feed it to another compiler, it could become illegal.  (I don't
care about the fact that an illegal package could become legal, but it
should be impossible for a legal package to become illegal.)

A third possibility would be to say that the with_clauses are moved up
by the compiler, and the named packages can cause hiding and ambiguity,
but it is illegal to refer to them.  It's important that this be a
(post-overload resolution) Legality Rule.  This seems the most desirable
from the user's point of view, but it's no longer a trivial text
shuffle.  This rule would ensure that any pair of .ads/.adp files can be
text-shuffled and fed to another compiler, and it will still be legal.
It seems like a correct implementation, in the sense that GNAT would be
saying, "You may put some stuff in a .adp file, but if you do, you have
to obey an extra rule."  The extra rule would of course be wrong, if
it were not conditional in that way.

Another issue about this feature: The way it was originally described,
it sounded like the rule was: If the .ads file ends in "private",
without anything after it, then the compiler looks for a .adp file,
and concatenates that onto the end.  That seems undesirable.  Instead,
the rule should be: If a .adp file exists, then it is concatenated onto
the end.  In addition, if the .adp file exists, then the .ads file has
to end in "private".  This rule is better, because it avoids the problem
of silently ignoring the .adp file.

(GNAT has a similar bug, in that it silently ignores .adb files in the
case where the .ads file does not require a body.  ACT knows about that,
and I believe they intend to fix it.)

- Bob

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

[Robert A Duff]

In article <4ggpkg$bl4@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>IMHO, adding a new part to an existing package would mean that you were
>making a profound change to the structure of the package.
>...
>Indeed, I'd be suspicious if the language allowed you
>made such a profound change _without_ carefully revisiting the other
>parts.

Then I guess you're suspicious of child packages, which allow you allow
you to add new parts *without* modifying the existing stuff.

>...  At the very least, the other parts would need to be recompiled.

...and without recompiling the existing stuff.

>As an analogy, consider what happens if you, say, add a new procedure
>declaration into an existing package spec.  Ada will force you to
>revisit the existing body of the package and add the corresponding
>procedure body.  Is being forced to do this "counterproductive"?

Yes.  This was recognized as a real problem with Ada 83, which is why
child packages were invented.  (Part of the problem can be solved with
incremental compilation, but incremental compilers aren't easy to
write.)

>...  It
>does take a certain amount of effort to write that procedure body, but
>isn't it worth it to keep the spec and body of a package consistent
>with each other?  What would the cost be in maintainability if Ada were
>more lax about this?  (Is it true that you can declare a member
>function in C++ and then neglect to implement a "body" for it?  If so,
>what's the cost in debugging time to catch this kind of error?)

No, I believe that in C++ you will get an error at link time if you do
that.  (In Ada, you will get an error at link time if the entire package
body is missing.)

>(Contrast this with adding a new child unit into an existing hierarchical
>library. That change should not affect existing parent and child units
>any more than introducing an unrelated package would.  At worst, a new
>child unit might try to exploit internal details of its parent in ways
>that would cause parent code to break when both are linked into the
>same program, but the mere existence of a new child unit would not, for
>instance, require the parent unit to be re-compiled.)

OK, now I'm confused.  I don't see the "contrast".  You're building a
subsystem out of multiple pieces.  In one case, you're horrified at the
idea of adding a new piece without having to modify existing pieces, and
in the other case (child packages), you're perfectly happy with that.
It seems to me that in *either* case, when you add a new piece, you
*might* want to modify existing pieces, and you might not.  I don't see
how a language rule requiring you to make a particular modification is
going to help you recognize the logically necessary modifications --
it's just going to cost extra compile time.

You can break things by adding a procedure to a package, but only if you
add some code that calls the new procedure.  And you can break things by
adding a child (your "at worst...") above, but only if you add some code
that references the new stuff.  I don't see any contrast, and I don't
see any need for language rules to get in the way of making changes.

- Bob

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

[Robert A Duff]

In article <4gh2da$ffb@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>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.

You're getting closer and closer to child packages.  It seems to me that
if you want to think about this, you should start out with child
packages, and enumerate the things they can't do, or can't do well
enough for your taste (such as the mutually recursive types thing), and
think about how to modify the semantics of child packages to fix those
problems.  Inventing a whole new feature seems like overkill.

- Bob

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

[Robert I. Eachus]

In article <4gh2da$ffb@dayuc.dayton.saic.com> John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:

  > 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.

   How about:

   package Stack(Interface, Extended_Interface, Completion);

   package Stack(Interface) is...
   end Stack(Interface);

   package Stack(Extended_Interface) is...
   end  Stack(Extended_Interface);
 
   etc.

   (Lots of other good ideas that work well with this approach deleted.)

   In the GNAT library model, the one line declaration of the parts
would have to be in a separate file with a new extension, .adp?, but
other than that no problem.  Or you could make the part enumeration a
header for the first package part:

   parts(Interface, Extended_Interface, Completion);
   package Stack(Interface) is...
   end Stack(Interface);

   Making each part list all of the partitions is the third approach:

   package Stack(Interface of Interface, Extended_Interface, Completion) is
   end Stack(Interface);

   But this could lead to more hassle in maintenance.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...