Re: Subunits of packages vs. subunits of subprograms

Re: Subunits of packages vs. subunits of subprograms

[Robert Dewar]

Tuck said

"In any case, our AdaMagic(tm) front end implements the approach Robert
mentions, namely that subunits nested only in packages are "truly"
separately compiled, whereas subunits nested in any non-package are
"inlined" at the point of the stub.  If the subunit is not available
when this "inlining" would take place, we issue a warning that the enclosing
unit will need to be recompiled when the subunit is available.  We don't
consider this an error, and the (pre)linker will by default perform
the needed recompilation if necessary."

OK, so interesting that we both agree on not trying to handle subunits
nested in non-packages truly separately. One can imagine programs that
would be badly affected by this (I know of one, the old Alsys
front end technology which used a separate procedure for each pass
(remember that in that compiler, all local access types were automatically
cleaned up on scope exit, so this arrangement makes reasonable sense), but
in practice there don't seem to be other examples like this.

As to the procedures, GNAT would be very similar. I am not sure about
the proper default, I am not sure I like the recompilation structure
being affected by what happens to be around when you compile, but in
any case gnatmake would work as Tuck describes their prelinker working,
it would complete any required compilations.

Re: Subunits of packages vs. subunits of subprograms

[Robert Dewar]

David Morton said

"Basically, it seems now that the separate keyword's function is to break
down a lenthy file into many small ones, mainly for easier reading, not
to speed up developement or help the concept of separate compilation.

I think I understand the reasons for it being this way, but although
it does meet the letter of the RM, it does seem to violate the spirit
of separate compilation.  Oh well, it's *not* that big a deal..."

You realize of course that subunits are, in many instances, obsoleted by
the notion of child units. Most, but not all, uses of subunits in Ada 83
are more comfortably replaced by the use of child units in Ada 95.
So to a certain extent subunits are being provided for backwards
compatibility.

Subunits of packages vs. subunits of subprograms

[Tucker Taft]

[NOTE: This is a continuation of the discussion of subunits, but I couldn't
bear to see "separate" misspelled yet again.  I would think that
Ada programmers, of all people, would know that "separate" has two "a"s.
Perhaps the misspelling just proves that subunits are no longer being 
used as much in Ada 95 ;-).]

In any case, our AdaMagic(tm) front end implements the approach Robert 
mentions, namely that subunits nested only in packages are "truly"
separately compiled, whereas subunits nested in any non-package are
"inlined" at the point of the stub.  If the subunit is not available
when this "inlining" would take place, we issue a warning that the enclosing
unit will need to be recompiled when the subunit is available.  We don't
consider this an error, and the (pre)linker will by default perform
the needed recompilation if necessary.

Interestingly, when we retargeted AdaMagic to generate Java byte codes
(our "AppletMagic(r)" product), we had to shift to fully "inlining"
all subunits, as well as generating code for package specs only when
encountering the package body (presuming there is one).  This was necessary
because, given our Ada => Java mapping, all code for a single Ada package 
needs to be in the same Java ".class" file.  In fact, the whole 
source->object model breaks down a bit with Java byte codes, because Java
"object modules" (.class files) are required to be one-to-one with Java 
classes, which relate to Ada entities, not to Ada source files.

So our front end now supports both approaches, fully "inlined" 
subunits, and separate compilation of package-enclosed subunits, 
depending on the target.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Subunits of packages vs. subunits of subprograms

[David Morton]

Tucker Taft wrote:
> 
> [NOTE: This is a continuation of the discussion of subunits, but I couldn't
> bear to see "separate" misspelled yet again.  I would think that
> Ada programmers, of all people, would know that "separate" has two "a"s.
> Perhaps the misspelling just proves that subunits are no longer being
> used as much in Ada 95 ;-).]


:)   
Remember, there are those (college students, even) who are still 
learning the language...
C.l.a. is a great place to find help (As I am teaching myself,
with help from all of you)
As such, I had never used the separate keyword before, therefore
never learning the error.  c.l.a has now taught me the err of my ways!  :)
Yes, I was the one who started this thread, and I can admit a mistake.

Basically, it seems now that the separate keyword's function is to break
down a lenthy file into many small ones, mainly for easier reading, not
to speed up developement or help the concept of separate compilation.

I think I understand the reasons for it being this way, but although
it does meet the letter of the RM, it does seem to violate the spirit
of separate compilation.  Oh well, it's *not* that big a deal...  

-- 
David Morton
 mailto:dmorton@jinx.sckans.edu   http://www.sckans.edu/~dmorton/
 205 College, Winfield, KS 67156    
 This signature will self-destruct in 10 seconds...

Re: Subunits of packages vs. subunits of subprograms

[Michael Feldman]

In article <31E534FE.12370608@jinx.sckans.edu>,
David Morton  <dmorton@jinx.sckans.edu> wrote:

>Basically, it seems now that the separate keyword's function is to break
>down a lenthy file into many small ones, mainly for easier reading, not
>to speed up developement or help the concept of separate compilation.

Well, that is certainly _a_ function of subunits. I think it goes too
far to always be looking for _one_ purpose, to the exclusion of others.

I agree that it certainly does serve the purpose you describe. I've
found - as a textbook author - that it's a clever way for me to
introduce a package, with full spec but with stubs for all the
bodies of the operations, then bring in each operation body as a
separate (pun intended) example, in a separate file.

Even if GNAT requires that all the body files be available for
code generation, Robert Dewar and others pointed out that these are
_not_ required for syntactic and semantic checking of the package
body. This can be seen as a variant of the fact that Ada does not
require a package body to be present _at all_ in order to do syntax/
semantic checking - even code generation - of a client program. 

Many students don't focus on that either, and insist on writing a 
complete package body before going on to develop a client. In a team
situation, in school or in industry - often the client and the package
body are developed in parallel by different team members (or even
different teams!).

>I think I understand the reasons for it being this way, but although
>it does meet the letter of the RM, it does seem to violate the spirit
>of separate compilation.  Oh well, it's *not* that big a deal...  

Well, if you buy Robert Dewar's definition of compilation as syntax/
semantic checking but no code generation, there's no violation. I've
just been looking in the RM 95, especially Chapter 10, and I find no 
straightforward definition of compilation in it. That is, there's nothing 
like "compilation includes syntax/semantic checking and code generation". 

The details of the various phases of production of an executable program 
are left to the implementer: the door is evidently open to all sorts of 
compilation models; it's the result that counts. 

That's fine - it is not the role of the standard to micromanage  
mechanics.
>
>-- 
>David Morton
> mailto:dmorton@jinx.sckans.edu   http://www.sckans.edu/~dmorton/
> 205 College, Winfield, KS 67156    
> This signature will self-destruct in 10 seconds...

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/education
------------------------------------------------------------------------

Re: Subunits of packages vs. subunits of subprograms

[James A. Squire]

Robert Dewar wrote:

> You realize of course that subunits are, in many instances, obsoleted by
> the notion of child units. Most, but not all, uses of subunits in Ada 83
> are more comfortably replaced by the use of child units in Ada 95.
> So to a certain extent subunits are being provided for backwards
> compatibility.

.... assuming that the only separates one uses are packages.  Some of us
use separates for subprograms within a package, for the reasons implied
by David Morton in his last posting on this thread, and so for us, child
units certainly do not obsolete subunits "in many instances."
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Subunits of packages vs. subunits of subprograms

[Robert A Duff]

In article <4s8h0o$s6u@felix.seas.gwu.edu>,
Michael Feldman <mfeldman@seas.gwu.edu> wrote:
>Well, if you buy Robert Dewar's definition of compilation as syntax/
>semantic checking but no code generation, there's no violation. I've
>just been looking in the RM 95, especially Chapter 10, and I find no 
>straightforward definition of compilation in it. That is, there's nothing 
>like "compilation includes syntax/semantic checking and code generation". 

Well, this is all very language-lawyerly, but here's the
chapter-and-verse:

RM-1.1.2(27), 1.1.3(4), and 1.1.5(3-4) say that Legality Rules have to
be checked at "compile time", and that the compiler has to tell you (at
compile time) whether each compilation unit submitted to the compiler is
legal or illegal.  (Of course, a good compiler will attempt to explain
*why* it's illegal, but the RM doesn't require that.)

10.1(2) and 10.1.4(5,8) make it clear that "compile time" is not the
same as link time -- the "compiler" has to be able to detect legality
errors in incomplete programs (i.e. before link time).

The RM never says that the implementation has to generate code (although
1.1.3(2) comes close), and certainly never says *when* code is
generated.

Interpretive execution is legal, but there still has to be a
legality-checking compiler that comes before.  Incremental code
generation is another possibility, or even code generation at run-time
("just in time").

>That's fine - it is not the role of the standard to micromanage  
>mechanics.

Right.

- Bob

Re: Subunits of packages vs. subunits of subprograms

[Robert A Duff]

In article <31EA9976.5CD6@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>.... assuming that the only separates one uses are packages.  Some of us
>use separates for subprograms within a package, for the reasons implied
>by David Morton in his last posting on this thread, and so for us, child
>units certainly do not obsolete subunits "in many instances."

Library units (i.e. child units) can be procedures, too.

- Bob

P.S. IMHO most library units should be private library units.

Re: Subunits of packages vs. subunits of subprograms

[JamesS1889]

In article <DuwKL6.Lsx@world.std.com>, bobduff@world.std.com (Robert A
Duff) writes:

>Library units (i.e. child units) can be procedures, too.

Dohh!!!!!  I didn't know that.  Well, then I guess Robert's answer makes
more sense.  Of course, the visibility is still at the end of the package,
not somewhere in the middle.  I guess as long as you declare specs for all
internal subprograms, there's really no reason not to make them child
units.

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"