comp.lang.ada
 help / color / mirror / Atom feed
From: John G. Volan <John_Volan@ccmail.dayton.saic.com>
Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff]
Date: 1996/02/21
Date: 1996-02-21T00:00:00+00:00	[thread overview]
Message-ID: <4gfmli$n0l@dayuc.dayton.saic.com> (raw)
In-Reply-To: 31273ED6.B9B@flash.net

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




  reply	other threads:[~1996-02-21  0:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com>
1996-02-18  0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington
1996-02-21  0:00   ` John G. Volan [this message]
1996-02-22  0:00   ` John G. Volan
1996-02-23  0:00     ` Robert A Duff
1996-02-22  0:00   ` John G. Volan
1996-02-23  0:00     ` Robert A Duff
1996-02-22  0:00 ` John G. Volan
1996-02-22  0:00   ` John G. Volan
1996-02-23  0:00   ` Robert A Duff
1996-02-23  0:00 ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox