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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,45abc3b718b20aa3
X-Google-Attributes: gid103376,public
From: adam@irvine.com (Adam Beneschan)
Subject: Re: Two ideas for the next Ada standard
Date: 1996/08/30
Message-ID: <507akg$t9u@krusty.irvine.com>#1/1
X-Deja-AN: 177540179
references: <5009h5$ir4@netline-fddi.jpl.nasa.gov>
 <503sbo$j45@goanna.cs.rmit.edu.au> <DwyFuC.E0K@world.std.com>
organization: /z/news/newsctl/organization
newsgroups: comp.lang.ada
Date: 1996-08-30T00:00:00+00:00
List-Id: <comp.lang.ada>


bobduff@world.std.com (Robert A Duff) writes:

 >Independent of the question of child packages, it is definitely an
 >annoyance that a with_clause has to go up at the top, when you really
 >only want it for the private part.  The mistake, I think, is that the
 >syntax requires with_clauses outside the unit -- it makes more sense to
 >me, to put them inside:
 >
 >    package X is
 >        with Y;
 >        ...
 >    private
 >        with Z;
 >        ...
 >    end X;

To me, the mistake is that private parts have to be put in package
specs at all.  Ideally, if you declare a type "private" in the package
spec, you should be able to define the complete type in the package
body, which is the normal place to put things that you don't want
visible to other packages that use the package.  

The only reason it isn't in the body, as far as I can see, is that it
makes life more difficult for compilers, who would like to know how
big a type is before they compile other packages that use the spec.
This means that things like stack offsets and record component offsets
aren't known at compile time.  But it shouldn't be that difficult to
arrange things so that the linker can generate the correct offsets at
link time.  It may require a more sophisticated linker or more
sophisticated relocation information in the object file.  

I'm running into this problem right now.  I'm defining some new
private types, but I cannot define them in the private part, because
this would lead to recursive package dependencies.  (The types are in
package X, and package Y's spec WITH's package X, but I'd like to put
some data defined in Y in the definition of the private type.  Since I
can't do that without creating recursive dependencies, I've resorted
to the old trick of making the private type an access to a record
structure that's defined in X's body.  This works, but opens up a can
of worms related to memory allocation and garbage collection.

So my suggestion for the next Ada standard is to allow private types
to be completed in the package body, instead of requiring them to be
completed in the "private" part.  (If this would cause serious
difficulties for other language rules, or if there would be major
problems implementing this suggestion in some cases, I'm not aware of
the problem but would appreciate having someone point it out to me.)

(I know that someone [I don't remember who] made the same argument
around 1980 or 1981, pointing out that we'd all benefit from more
sophisticated linkers.  It's possible that the original Ada proposals
allowed you to complete private types in the package body, but that
this was changed at the request of implementors, leading someone to
argue against the change.  But my memory is hazy.)

                                -- Adam