Separate Compilation in Programming Languages

Separate Compilation in Programming Languages

[adaworks]

Recently, I have been engaged in some conversations with colleagues about the 
value of
separate compilation.    This is one of my favorite features in Ada.   In fact, 
as nearly as
I can tell, none of the other popular languages includes this feature in as 
well-developed
a form as Ada.   Java has no separate compilation at all.  Nor does Eiffel. 
C++ has a
rather kludgy form that is sometimes worse than none at all.    Modula includes 
a form
of separate compilation, but requires opaque types.    Older languages such as 
PL/I,
COBOL, and Fortran are pretty useless in this respect.

This morning, after an especially interesting argument about this feature and, 
"Why would
anyone want to do such a thing?" style questions, I decided to approach this 
forum.  What
is your view of Ada-style separate compilation when compared to that in other 
languages?
Do you find it useful in your own practice?   Do you still use the "is separate" 
feature in
a package body?    For my own programs, I find it helpful as a way to manage 
dependencies
when there are a lot of library units.   Also, UML does not support a capability 
for modeling
separate compilation, and that is a bit frustrating when trying to model a 
fine-grained design.

If you wish, you may reply to my Naval Postgraduate School email: 
rdriehle@nps.edu or
my personal email, laoxiaohai@juno.com .   I rarely use this adaworks account 
for email
anymore since I am no longer actively pursuing Ada consulting anymore.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Dirk Heinrichs]

adaworks@sbcglobal.net wrote:

> This morning, after an especially interesting argument about this feature
> and, "Why would
> anyone want to do such a thing?" style questions, I decided to approach
> this
> forum.  What
> is your view of Ada-style separate compilation when compared to that in
> other languages?
> Do you find it useful in your own practice?   Do you still use the "is
> separate" feature in
> a package body?

When put under version control, one can can easily track the development of
functions, instead of files as is the case for most projects developed in
C/C++, where the entire class is put in one large .cpp file.

While it is doable in C/C++ as well, it can't be expressed in the language
itself, which means that the compiler has no means of telling wether one .c
file logically belongs to another or not.

However, in either language it requires a bit of discipline from the
developers.

Bye...

        Dirk

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> Java has no separate compilation at all.

Of course it does. It has no explicit syntax dedicated to describing separate
compilation, but it doesn't need it. It is quite straightforward to make
separate libraries, etc.

It's just that the closure is implicit, but it works well in practice since
the compiler tells you if it can't find anything missing.

You can still get the benefits of separate compilation by simply having
reasonable subsystems (i.e. packages), proper information hiding and the
like. Java build environments seem pretty decent with compiling only what is
needed.

It's like the problem is not really relevant with Java.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Niklas Holsti]

adaworks@sbcglobal.net wrote:
> Recently, I have been engaged in some conversations with colleagues
> about the value of separate compilation. ...
> What is your view of Ada-style separate compilation when compared to
> that in other languages?

The Ada way, and especially the source-based library system as used 
in GNAT and relatives, is the best form of separate (modular) 
compilation that I've ever used. My experience includes various 
implementations of Algol, Pascal, Fortran, Cobol, C, and C++, but 
not very much Java.

> Do you find it useful in your own practice?

I find it hard to imagine programming *without* separate 
compilation of modules, except with special super-fast (poorly 
optimizing) compilers of the "Turbo" variety.

> Do you still use the "is separate" feature in a package body?

I never use it. My subprograms are rarely long enough to make it 
useful (given that there is no compilation-speed advantage under 
GNAT), and I seldom use nested packages.

Separate version tracking per subprogram (as mentioned by Dirk 
Heinrichs) could be an advantage, but I would prefer to get this 
from a subprogram-aware version control system, without the 
proliferation of source files that "separate" causes.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Separate Compilation in Programming Languages

[Dmitry A. Kazakov]

On Fri, 22 Feb 2008 17:35:33 GMT, adaworks@sbcglobal.net wrote:

> What
> is your view of Ada-style separate compilation when compared to that in other 
> languages?

It is the best I know, but still problematic when it comes to DLLs and
distributed stuff.

> Do you find it useful in your own practice?   Do you still use the "is separate" 
> feature in a package body?

I do but not very often. One problem is that GNAT's implementation of is
quite intolerant to errors in separate bodies. So you cannot have an
independent design - compile loop for them. Splitting things into smaller
filers after having designed them is no more actual in these days of IDEs.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Separate Compilation in Programming Languages

[Larry Kilgallen]

In article <FJDvj.10151$0o7.9092@newssvr13.news.prodigy.net>, <adaworks@sbcglobal.net> writes:
> Recently, I have been engaged in some conversations with colleagues about the 
> value of
> separate compilation.    This is one of my favorite features in Ada.   In fact, 
> as nearly as
> I can tell, none of the other popular languages includes this feature in as 
> well-developed
> a form as Ada.   Java has no separate compilation at all.  Nor does Eiffel. 
> C++ has a
> rather kludgy form that is sometimes worse than none at all.    Modula includes 
> a form
> of separate compilation, but requires opaque types.    Older languages such as 
> PL/I,
> COBOL, and Fortran are pretty useless in this respect.

VMS Pascal has support for separate compilation, with data types
coming from one or more common source files and correspondence
between compilations checked at link time.

I do not know how many of those features come from the latest Pascal
Standard.

Re: Separate Compilation in Programming Languages

[Simon Wright]

We use separates to keep (re)generated package specs and bodies well
away from the handwritten parts --having had some bad experiences with
Rose/Ada (special --begin-handwritten, --end-handwritten comments and
lots of opportunities for confusion).

Also sometimes useful for AUnit testing -- put the test case into a
package whose body is separate.

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> Recently, I have been engaged in some conversations with colleagues
> about the value of separate compilation.  This is one of my favorite
> features in Ada.  In fact, as nearly as I can tell, none of the other
> popular languages includes this feature in as well-developed a form as
> Ada.  Java has no separate compilation at all.  Nor does Eiffel.  C++
> has a rather kludgy form that is sometimes worse than none at all.
> Modula includes a form of separate compilation, but requires opaque
> types.  Older languages such as PL/I, COBOL, and Fortran are pretty
> useless in this respect.

Please define what you mean by "separate compilation".

My definition is that you can store parts of the program in separate
source files, and compile each source file separately from other source
files.  You can compile parts of incomplete programs.  In that sense,
all of the above-mentioned languages (or language implementations in
common use) have it.  So I'm puzzled by your statement to the contrary.

I've also heard the term "independent compilation" used for the above,
with "separate compilation" meaning that in addition, whatever type
checking is done within a single compilation unit should be done across
separately compiled units.  In that sense, Ada, Eiffel, Modula-2, and
Java still have separate compilation.  C and C++ do too, sort of, if you
rely on taking care with include files.  Still puzzled.

By the way, Eiffel compilers typically use incremental compilation,
which if implemented well, is strictly superior to separate
compilation on a file-by-file basis.

- Bob

Re: Separate Compilation in Programming Languages

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
> 
> This morning, after an especially interesting argument about this feature and, 
> "Why would
> anyone want to do such a thing?" style questions, I decided to approach this 
> forum.  What
> is your view of Ada-style separate compilation when compared to that in other 
> languages?
> Do you find it useful in your own practice?   Do you still use the "is separate" 
> feature in
> a package body?    For my own programs, I find it helpful as a way to manage 
> dependencies
> when there are a lot of library units.   Also, UML does not support a capability 
> for modeling
> separate compilation, and that is a bit frustrating when trying to model a 
> fine-grained design.

I find the separation of spec and body very useful, especially for programming 
in groups by setting detailed design decisions in code-crete as pkg specs. I 
find many of the features of Ada packages useful in representing the 
implementation of a good design. I primarily use body stubs to reduce the size 
of large pkgs.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ur6f4x3o3.fsf@STRIPCAPStelus.net...
>
> <adaworks@sbcglobal.net> writes:
>> Java has no separate compilation at all.
>
> Of course it does. It has no explicit syntax dedicated to describing separate
> compilation, but it doesn't need it. It is quite straightforward to make
> separate libraries, etc.
>
The issue is about dependencies.   When the class definition and the
class implementation are in the same file, any dependent units will
have to be compiled when there is a change in that file.    I don't
see any capability for managing this kind of dependency in Java.


> It's just that the closure is implicit, but it works well in practice since
> the compiler tells you if it can't find anything missing.
>
> You can still get the benefits of separate compilation by simply having
> reasonable subsystems (i.e. packages), proper information hiding and the
> like. Java build environments seem pretty decent with compiling only what is
> needed.
>
> It's like the problem is not really relevant with Java.
>
> -- 
> Cheers,                                        The Rhythm is around me,
>                                               The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul. 

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr6f4y94q.fsf@shell01.TheWorld.com...
>
> Please define what you mean by "separate compilation".
>
I knew my original post would stimulate some discussion.   You are
correct that some form of separate compilation is available in most
languages.

My concern is dependency management.  I will give an example in source
code.

with X, Y, Z, Q, R, S;  -- a set of library units on which we are dependent
package A is                -- a package specification

     -- types and methods for this package

end A;

At this point, everything that is dependent on this specification is also
dependent on the library units on which A is dependent.   In Ada, we
can move those dependencies to the package body.  So, we have:

package A is                -- a package specification

     -- types and methods for this package

end A;

with X, Y, Z, Q, R, S;  -- only body is dependent on these
package body A is                -- a package specification

     -- implementation of package A

end A;

By moving the dependencies to the package body, the specification
is dependency free, as are all of the library units that become
dependent on it.   Further, if we use the "is separate" feature,
we can push those dependencies even further down into the
implementation, not something any of the other languages
do very well.

I don't think this is possible in Java, Eiffel, or C#.  It is only possible
in C++ by using the #include in the CPP file, and that is error-prone.
As noted by someone else, an automated configuration control
software can be of help in this regard, but it is not built into the
language as it is with Ada.
>
RD> By the way, Eiffel compilers typically use incremental compilation,
RD> which if implemented well, is strictly superior to separate
RD> compilation on a file-by-file basis.

But it still does not seem to solve the dependency issue as cleanly as
Ada does.

Re: Separate Compilation in Programming Languages

[adaworks]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:47bf11df$0$14990$4f793bc4@news.tdc.fi...
> adaworks@sbcglobal.net wrote:
>
>> Do you still use the "is separate" feature in a package body?
>
> I never use it. My subprograms are rarely long enough to make it useful (given 
> that there is no compilation-speed advantage under GNAT), and I seldom use 
> nested packages.
>
Thanks.  The issue is not compilation speed, nor even size of the
source code.   Rather, the real benefit of Ada's separate compilation
model is the management of dependencies. 

Re: Separate Compilation in Programming Languages

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:19aoco1bwcscs$.v4o2kd01gbw6.dlg@40tude.net...
> On Fri, 22 Feb 2008 17:35:33 GMT, adaworks@sbcglobal.net wrote:
>
>> Do you find it useful in your own practice?   Do you still use the "is 
>> separate"
>> feature in a package body?
>
> I do but not very often. One problem is that GNAT's implementation of is
> quite intolerant to errors in separate bodies. So you cannot have an
> independent design - compile loop for them. Splitting things into smaller
> filers after having designed them is no more actual in these days of IDEs.
>
Agreed.  This is an issue with the implementation, not with the language. Not
all compilers are GNAT. 

Re: Separate Compilation in Programming Languages

[adaworks]

"Dirk Heinrichs" <dirk.heinrichs@online.de> wrote in message 
news:fpn25e$du5$1@online.de...
> adaworks@sbcglobal.net wrote:

>> Do you find it useful in your own practice?   Do you still use the "is
>> separate" feature in
>> a package body?
DH>
DH> When put under version control, one can can easily track the development of
DH> functions, instead of files as is the case for most projects developed in
DH> C/C++, where the entire class is put in one large .cpp file.
DH>
Yes. Version control is useful, even for Ada projects.   However, version
control does not solve the dependency issue.
DH>
DH> While it is doable in C/C++ as well, it can't be expressed in the language
DH> itself, which means that the compiler has no means of telling wether one .c
DH> file logically belongs to another or not.
DH>
DH> However, in either language it requires a bit of discipline from the
DH> developers.
DH>
Agree.  This is always much simpler in Ada than in other languages.   There is
question of whether it is an important enough distinction to make a difference
when choosing a language for a large-scale software system.   I know it was
a very big issue on some of the early Ada projects such as BSY-2 which
was originally designed without using Ada's dependency management via
separate compilation.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> The issue is about dependencies.   When the class definition and the
> class implementation are in the same file, any dependent units will
> have to be compiled when there is a change in that file.    I don't
> see any capability for managing this kind of dependency in Java.

In practice it's not an issue. Compilation is cheap.

But there is a way to manage explicit dependencies: express the public facing
APIs in terms of interfaces with implementation classes that truly hide the
actual implementation.

This gives a strict separation that gives you the control you were looking
for.

Whether that is as convenient or not as Ada is another debate.

The issue is simply not that serious, partially due to Java's dynamic loading
abilities. I can drop a new version in of my library JAR in somewhere, and if
the public API signatures have not actually changed I do not in fact need to
recompile. 

In practice however, you do, because it's easy and it catches any unexpected
API changes. But one was still doing "separate compilation".

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Niklas Holsti]

adaworks@sbcglobal.net wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:47bf11df$0$14990$4f793bc4@news.tdc.fi...
> 
>>adaworks@sbcglobal.net wrote:
>>
>>
>>>Do you still use the "is separate" feature in a package body?
>>
>>I never use it. My subprograms are rarely long enough to make it useful (given 
>>that there is no compilation-speed advantage under GNAT), and I seldom use 
>>nested packages.
>>
> 
> Thanks.  The issue is not compilation speed, nor even size of the
> source code.   Rather, the real benefit of Ada's separate compilation
> model is the management of dependencies. 

I understand this point -- in theory. In practice, although I do 
worry about dependencies in general, I haven't seen cases where "is 
separate" would have been very useful, in my opinion.

True, often only some parts (subprograms) of a large package body 
depend on some given other package, and other parts do not, but it 
is rare for this selective dependency to apply to only one 
subprogram in the package.

If there are, say, three subprograms in package A that depend on 
package B, and I make these three subprograms "separate" to remove 
the "with B" clause from A, I now have three "with B" clauses in 
three different source-code files, instead of the one clause in the 
body of A.

The dependencies are more specific, good, but also there are more 
dependencies (and more source-code files), not so good. By YMMV.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ur6f4sb5l.fsf@STRIPCAPStelus.net...
> <adaworks@sbcglobal.net> writes:
>> The issue is about dependencies.   When the class definition and the
>> class implementation are in the same file, any dependent units will
>> have to be compiled when there is a change in that file.    I don't
>> see any capability for managing this kind of dependency in Java.
>
RB> In practice it's not an issue. Compilation is cheap.
RB>
For small software systems this might be true.   However, for large
systems this is not true.  I am thinking in terms of software projects
that require over a million lines of source code and a lot of library
units where the dependencies are significant.  For systems of this
magnitude, where many different programmers are working on the
project, compilation is not cheap.
RB>
RB> But there is a way to manage explicit dependencies: express the public 
facing
RB> APIs in terms of interfaces with implementation classes that truly hide the
RB> actual implementation.
RB>
I considered Interfaces.  They appear, at first glance, to be a solution. 
However,
they fall short of what we are seeking here.   Once the Interface is 
implemented,
the rest of the software still depends on that implementation and there is no
model of separate compilation at that point where one can separate the
specification from the implementation.  The dependency becomes bound to
the implementation of the Interface not to the Interface abstraction.
RB>
RB> This gives a strict separation that gives you the control you were looking
RB> for.Whether that is as convenient or not as Ada is another debate.
RB>
It is not a matter of convenience.   It simply falls short.
RB>
RB> The issue is simply not that serious, partially due to Java's dynamic 
loading
RB> abilities. I can drop a new version in of my library JAR in somewhere, and 
if
RB> the public API signatures have not actually changed I do not in fact need to
RB> recompile.
RB>
RB> In practice however, you do, because it's easy and it catches any unexpected
RB> API changes. But one was still doing "separate compilation".
RB>
But not managing dependencies very well.

Re: Separate Compilation in Programming Languages

[Niklas Holsti]

Replying to my own post in order to add a remark:

Niklas Holsti wrote:
> adaworks@sbcglobal.net wrote:
> 
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
>> news:47bf11df$0$14990$4f793bc4@news.tdc.fi...
>>
>>> adaworks@sbcglobal.net wrote:
>>>
>>>
>>>> Do you still use the "is separate" feature in a package body?
>>>
>>>
>>> I never use it. My subprograms are rarely long enough to make it 
>>> useful (given that there is no compilation-speed advantage under 
>>> GNAT), and I seldom use nested packages.
>>>
>>
>> Thanks.  The issue is not compilation speed, nor even size of the
>> source code.   Rather, the real benefit of Ada's separate compilation
>> model is the management of dependencies. 
> 
> 
> I understand this point -- in theory. In practice, although I do worry 
> about dependencies in general, I haven't seen cases where "is separate" 
> would have been very useful, in my opinion.

What I often do instead is to divide the original package, which 
contains parts with very different dependencies, into a parent and 
one or more children, according to some logical criterion from the 
clients' point of view. I find that this often also sorts out the 
dependencies in the bodies, reducing the advantage of splitting the 
bodies into "is separate" parts.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Separate Compilation in Programming Languages

[framefritti]

On 23 Feb, 01:12, <adawo...@sbcglobal.net> wrote:
> "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote in messagenews:wccr6f4y94q.fsf@shell01.TheWorld.com...
>
> > Please define what you mean by "separate compilation".
>
> I knew my original post would stimulate some discussion.   You are
> correct that some form of separate compilation is available in most
> languages.
>
> My concern is dependency management.  I will give an example in source
> code.
(snip)
> But it still does not seem to solve the dependency issue as cleanly as
> Ada does.

Actually, I *love* the way Ada manages the dependencies between
packages.
The headache-inducing Makefiles used in some large C projects of mine
are
a (bad) memory nowdays...

Re: Separate Compilation in Programming Languages

[Georg Bauhaus]

adaworks@sbcglobal.net wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:47bf11df$0$14990$4f793bc4@news.tdc.fi...
>> adaworks@sbcglobal.net wrote:
>>
>>> Do you still use the "is separate" feature in a package body?
>> I never use it. My subprograms are rarely long enough to make it useful (given 
>> that there is no compilation-speed advantage under GNAT), and I seldom use 
>> nested packages.
>>
> Thanks.  The issue is not compilation speed, nor even size of the
> source code.   Rather, the real benefit of Ada's separate compilation
> model is the management of dependencies. 

I like separate subprograms or separate package bodies not only
because of dependency management, but also because they allow a
kind of source code organization not available without separation.
It is about distraction and separation of concerns.

Given that Ada has nesting, I can make all things local to where
they are used. Much like I can do using FPLs' let expressions
(as in Scheme or ML) or where clauses (as in Haskell).
But I don't have to "clutter the listing" between "is" and "begin"
with full implementation details that only disturb linear reading.

It's like saying, "I'll leave the details out for the moment",
or, "I'll talk about the implementation later". Still the
subp profile or package interface have been mentioned. That is,
the reader has enough information in order to follow the program
text.


function sqrt_iter(guess, x: Number) return Number is

   function improve(guessed: Number) return Number is separate;
   -- another number approximating sqrt_iter'Result

   function good_enough(guessed: Number) return Boolean is
   begin
      return abs (guessed * guessed - x) < 0.001;
   end;

begin -- sqrt_iter
   if good_enough(guess) then
      return guess;
   else
      return sqrt_iter(improve(guess), x);
   end if;
end sqrt_iter;

Re: Separate Compilation in Programming Languages

[Dirk Heinrichs]

Niklas Holsti wrote:

> Separate version tracking per subprogram (as mentioned by Dirk
> Heinrichs) could be an advantage, but I would prefer to get this
> from a subprogram-aware version control system, without the
> proliferation of source files that "separate" causes.

The only problem is that there is no subprogram-aware version control system
today. (My main job is doing SCM, btw., so I know what I'm talking about.)
And IMHO there doesn't need to be one. It would have to know the syntax of
the program's language(s) to find out when particular subprograms change so
that it can raise their versions. That's next to impossible because people
always want to put something under version control which is written exactly
in the single one language the system isn't aware of.

So the solution is to keep putting just files under version control, and if
each of those files represent exactly one subprogram, your version control
_is_ (sort of) subprogram-aware, but still language independant.

Bye...

        Dirk

Re: Separate Compilation in Programming Languages

[Dirk Heinrichs]

adaworks@sbcglobal.net wrote:

> My concern is dependency management.  I will give an example in source
> code.
> 
> with X, Y, Z, Q, R, S;  -- a set of library units on which we are
> dependent package A is                -- a package specification
> 
> -- types and methods for this package
> 
> end A;
> 
> At this point, everything that is dependent on this specification is also
> dependent on the library units on which A is dependent.   In Ada, we
> can move those dependencies to the package body.  So, we have:
> 
> package A is                -- a package specification
> 
> -- types and methods for this package
> 
> end A;
> 
> with X, Y, Z, Q, R, S;  -- only body is dependent on these
> package body A is                -- a package specification
> 
> -- implementation of package A
> 
> end A;
> 
> By moving the dependencies to the package body, the specification
> is dependency free, as are all of the library units that become
> dependent on it.   Further, if we use the "is separate" feature,
> we can push those dependencies even further down into the
> implementation, not something any of the other languages
> do very well.

Maybe I misunderstood something, but isn't it so that (with gnat) when A.adb
is recompiled, it sort of "includes" the subunits and compiles them as
well, which means that internally, the compiler handles them all as one
entity? If this is true, then it doesn't matter wether the dependencies are
moved into the subunits or not.

However, even if it doesn't make a difference for the compiler, it can still
make a difference for the reader/maintainer of the code.

Bye...

        Dirk

Re: Separate Compilation in Programming Languages

[Niklas Holsti]

Dirk Heinrichs wrote:
> Niklas Holsti wrote:
> 
> 
>>Separate version tracking per subprogram (as mentioned by Dirk
>>Heinrichs) could be an advantage, but I would prefer to get this
>>from a subprogram-aware version control system, without the
>>proliferation of source files that "separate" causes.
> 
> 
> The only problem is that there is no subprogram-aware version control system
> today. (My main job is doing SCM, btw., so I know what I'm talking about.)

Agreed. (I did say I *would* prefer it, not that I *can* do it :-)

Several years ago I implemented something of the sort, by writing 
some scripts to chop version "diff" reports per Ada subprogram, 
using fairly simple patterns to match the start and end of 
subprograms (greatly helped by a coding rule that forbade nested 
subprograms).

The result showed version history per subprogram, and I found it 
very useful, especially for maintaining unit tests.

> And IMHO there doesn't need to be one. It would have to know the syntax of
> the program's language(s) to find out when particular subprograms change so
> that it can raise their versions. That's next to impossible because people
> always want to put something under version control which is written exactly
> in the single one language the system isn't aware of.

Well, it is a little like syntax coloring in editors, isn't it? 
Editors do it for the major languages, but not for every little 
language someone has invented. I admit that it is harder to 
identify subprogram boundaries than tokens and keywords, of course, 
and then there is the nesting problem.

> So the solution is to keep putting just files under version control, and if
> each of those files represent exactly one subprogram, your version control
> _is_ (sort of) subprogram-aware, but still language independant.

At the cost of a great number of files, and some language-specific 
means to combine the files into a program (eg. "is separate" for 
Ada). Ugh. Perhaps something could be done with a language-specific 
intermediate tool, similar to "gnatchop", that would mediate 
between the view that I want (one file per package, but version 
history per subprogram, or other segment of a file) and the view of 
the version control system.

But in my context, the need is not so great. I'm just day-dreaming.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Separate Compilation in Programming Languages

[Brian Drummond]

On Fri, 22 Feb 2008 17:35:33 GMT, <adaworks@sbcglobal.net> wrote:

>Recently, I have been engaged in some conversations with colleagues about the 
>value of
>separate compilation.    This is one of my favorite features in Ada.   In fact, 
>as nearly as
>I can tell, none of the other popular languages includes this feature in as 
>well-developed
>a form as Ada.  

One language which does have an equivalent mechanism (perhaps not surprisingly,
given its origin), and in which a similar debate is currently active, is VHDL.

There, the separation takes the form of the "component" specification, within
the consumer of a component. The consumer can instantiate a "component",
(similar to declaring a variable of a type defined separately) whose interface
is guaranteed consistent with its use by the compiler - and at this stage,
nothing is known about the implementation.

Separately, the component is defined as an "entity", and implemented as an
"architecture", which are again guaranteed consistent with each other during
compilation.

It is only at elaboration that an attempt is made to find an "entity" to match
each "component" specification; if there are any failures to match, of course,
elaboration fails with an error.

But there is also a way to bypass separate compilation by direct entity
instantiation, in which an entity specification is embedded in the consumer, in
the place of the component specification. In this case, the matching entity must
be found (already compiled and correct) for the consumer to compile.

Interestingly, in comp.lang.vhdl, the concensus seems to be that direct
instantiation is to be preferred where possible. (google comp.lang.vhdl for
"direct entity instantiation" if you need more of the debate). Two reasons are
usually mentioned: the component specification is just one more piece of code to
write and maintain; (and VHDL is perceived as verbose enough without it), and
forcing the entity/arch to compile concurrently with the consumer is perceived
as catching any errors earlier (i.e. compile time vs elaboration). In other
words, as said here for Java, compilation is cheap.

>This morning, after an especially interesting argument about this feature and, 
>"Why would
>anyone want to do such a thing?" style questions, I decided to approach this 
>forum.  What
>is your view of Ada-style separate compilation when compared to that in other 
>languages?
>Do you find it useful in your own practice?  

I am  out on a limb in still using components, and I'm not entirely clear why I
do, other than mild personal preference, and because the toolset I use
encourages it; it works perfectly well for me. Though I have occasionally had
elaboration failures due to component mis-specification, they haven't caused any
real headaches.

I'm not clear why the theoretical advantages of separate compilation aren't seen
as advantages in practice (in the VHDL world); the outspoken critics are
respected consultants and trainers; possibly they are in one-man or small-team
environments rather than million line projects. 

Possibly separate compilation was a big win when you had 8K of core and a drum
store, but a bit less important nowadays? (coming back to "compilation is cheap"
again)

I'm in a one-man project environment myself, where I can't see a clear win for
either side of the debate; separate compilation certainly doesn't impose
significant drag, except where tool bugs prevent making good use of packages and
libraries. But that's another issue...

- Brian

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> My concern is dependency management.

OK, but I still don't fully understand what you're getting at.
You said elsewhere in this thread that you are NOT concerned with
recompilation costs.  That's good -- recompilation cost should
primarily be an implementation concern.

I'm guessing that your point has nothing to do with "compilation" at
all, separate or otherwise.  It has to do with the organization of the
program into separate source files -- specifically separation of spec
and body (interface and implementation, to use more language-neutral
terms).  Right?

>...I will give an example in source
> code.
>
> with X, Y, Z, Q, R, S;  -- a set of library units on which we are dependent
> package A is                -- a package specification
>
>      -- types and methods for this package
>
> end A;
>
> At this point, everything that is dependent on this specification is also
> dependent on the library units on which A is dependent.   In Ada, we
> can move those dependencies to the package body.  So, we have:
>
> package A is                -- a package specification
>
>      -- types and methods for this package
>
> end A;
>
> with X, Y, Z, Q, R, S;  -- only body is dependent on these
> package body A is                -- a package specification
>
>      -- implementation of package A
>
> end A;
>
> By moving the dependencies to the package body, the specification
> is dependency free, as are all of the library units that become
> dependent on it.

OK, so you like having textually separate spec and body,
as do I.  But what specific advantages are you talking
about in this thread?

Readability?  That is, when looking at a client of A, you don't
need to worry about X,Y,...S.  This is good, but it's got little to do
with separate compilation.

Source modification?  A change in X could introduce a bug
into a client of A -- so there really _is_ a dependency
in that sense.

One advantage of Ada over some languages (e.g. C) is that the
implementation can know what source files are part of each program,
by following the with clauses.  I really hate having to write a make
file that lists out all the .o files that need to be linked together --
Ada allows that to be completely automated (that's what gnatmake does).

Something else?

Note that Ada requires some implementation details to appear in the
package spec -- namely, the stuff that goes in the private part, plus
the with clauses needed by that private part.  That's ugly, IMHO.

>...Further, if we use the "is separate" feature,
> we can push those dependencies even further down into the
> implementation, not something any of the other languages
> do very well.

Shrug.  I don't use "is separate" much.  Child packages are almost
always better, because you can separate the spec _and_ the body,
and because the parent need not know about the child.  Child packages
provide the same advantage of being able to "push down" the
dependencies.

> I don't think this is possible in Java, Eiffel, or C#.

It's possible using interfaces.  Clients of an interface do not depend
on classes that implement the interface, any more than clients of an Ada
package spec depend on its body.  You suggested otherwise elsewhere in
this thread, but I think you're wrong, or else I'm misunderstanding what
you mean by "depend".

Interfaces are more flexible than spec/body in that they allow multiple
"bodies".  And of course Ada 2005 has interfaces.  Note that an
interface will typically be declared in a package spec with no
corresponding body.

>...It is only possible
> in C++ by using the #include in the CPP file, and that is error-prone.

I agree that #include is a kludge.

> As noted by someone else, an automated configuration control
> software can be of help in this regard, but it is not built into the
> language as it is with Ada.
>>
> RD> By the way, Eiffel compilers typically use incremental compilation,
> RD> which if implemented well, is strictly superior to separate
> RD> compilation on a file-by-file basis.
>
> But it still does not seem to solve the dependency issue as cleanly as
> Ada does.

Eiffel has separate specs and bodies -- except that the spec is
automatically generated from the body, rather than being written by
hand.  I prefer to consider the spec to be a source file in its own
right, as in Ada, but it's not _that_ different from Eiffel.

- Bob

Re: Separate Compilation in Programming Languages

[adaworks]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:47bfc7b5$0$21890$4f793bc4@news.tdc.fi...
> Replying to my own post in order to add a remark:
>  What I often do instead is to divide the original package, which contains 
> parts with very different dependencies, into a parent and one or more 
> children, according to some logical criterion from the clients' point of view. 
> I find that this often also sorts out the dependencies in the bodies, reducing 
> the advantage of splitting the bodies into "is separate" parts.
>
This is an excellent solution.   However, I still prefer to design so my
dependencies are, as often as possible, at the package body or
separate subprogram level as possible. 

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc63wfpus7.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
>> My concern is dependency management.
>
> OK, but I still don't fully understand what you're getting at.
> You said elsewhere in this thread that you are NOT concerned with
> recompilation costs.  That's good -- recompilation cost should
> primarily be an implementation concern.
>
Sometimes recompilation costs are important.   This is true for very
large software systems where one does not want to recompile the
entire system for one change somewhere way down in a function
within one package body.

> I'm guessing that your point has nothing to do with "compilation" at
> all, separate or otherwise.  It has to do with the organization of the
> program into separate source files -- specifically separation of spec
> and body (interface and implementation, to use more language-neutral
> terms).  Right?
>
Right.  My primary concern, in this discussion,is with dependency management.

>
> OK, so you like having textually separate spec and body,
> as do I.  But what specific advantages are you talking
> about in this thread?
>
> Readability?  That is, when looking at a client of A, you don't
> need to worry about X,Y,...S.  This is good, but it's got little to do
> with separate compilation.
>
In my view, it does.  The less code I have to look at to make a
change or to understand the code, the better.  Granted, this does
not always work as well as I might like, but it frequently is of
value.
> Source modification?  A change in X could introduce a bug
> into a client of A -- so there really _is_ a dependency
> in that sense.
>
However, the dependency is at the iimplementation level, not at
the specification level.

> One advantage of Ada over some languages (e.g. C) is that the
> implementation can know what source files are part of each program,
> by following the with clauses.  I really hate having to write a make
> file that lists out all the .o files that need to be linked together --
> Ada allows that to be completely automated (that's what gnatmake does).
>
Well, Yes.   If, in one of my separately compiled subprograms within a
package body Q, uses a depth-search routine from a parent package
specification K, and we decide to use the breadth-search instead, there
is no need to alter any part of the package specification of Q.  It remains
stable.

This becomes an architectural issue, as well.   The more stable my
architecture when a change is made to some element of that architecture,
the better for my overall design.

> Something else?
>
> Note that Ada requires some implementation details to appear in the
> package spec -- namely, the stuff that goes in the private part, plus
> the with clauses needed by that private part.  That's ugly, IMHO.
>
Modula-2 solved that problem through the use of opaque types. I
often code opaque types in Ada using access types.   This eliminates
any dependencies at the specification level, in many cases.   As you
know, the private part of a package was a compromise that allows
separate compilation.

We can even create a tagged type as an opaque type, thereby hiding
any implementation details and still making that type extensible.  This
was difficult in Modula-2, so the designers of Modula-3 also had to
make some compromises.   Engineering is always about trade-offs
between conflicting solutions.   Java certainly has its share of trade-offs.
>
> Shrug.  I don't use "is separate" much.  Child packages are almost
> always better, because you can separate the spec _and_ the body,
> and because the parent need not know about the child.  Child packages
> provide the same advantage of being able to "push down" the
> dependencies.
>
I did not mention Child packages, but you are certainly correct that they
are a powerful contributing solution to this issue.   In particular, private
children are a great benefit.   However, in very large software systems,
a million SLOC or more, "is separate" continues to play an important
role.  As noted earlier, specifications should be an architectural concern,
and the more stable an architecture, the better.   Implementation should
be dependent on architecture, not the other way around.

When I want to change the upholstery in my car, I don't want to have to
alter the architecture of that car.   I don't want the performance of the car
to depend on whether I choose Zebra seat covers or chartreuse trim
on green Naugahyde.

>> I don't think this is possible in Java, Eiffel, or C#.
>
> It's possible using interfaces.  Clients of an interface do not depend
> on classes that implement the interface, any more than clients of an Ada
> package spec depend on its body.  You suggested otherwise elsewhere in
> this thread, but I think you're wrong, or else I'm misunderstanding what
> you mean by "depend".
>
> Interfaces are more flexible than spec/body in that they allow multiple
> "bodies".  And of course Ada 2005 has interfaces.  Note that an
> interface will typically be declared in a package spec with no
> corresponding body.
>
Even with an interface, a la Java, once the interface is implemented, the
children dependent on that unit will be dependent on the implementaion,
not on the interface.   And Java still has no way of separating the
specification of that implementing class from its implementation.   In
another forum (comp.lang.programming) someone submitted an
example to show how interfaces would solve this problem, but the
example did not separate interface from implementation..
>
> Eiffel has separate specs and bodies -- except that the spec is
> automatically generated from the body, rather than being written by
> hand.  I prefer to consider the spec to be a source file in its own
> right, as in Ada, but it's not _that_ different from Eiffel.
>
Yes.  In Ada, the specification is most certainly a separate source
file.  As noted earlier, the specifications and the relatioships between
specifications, represent the overall architecture of the software
system.   I'll take another look at Eiffel, a language design I do admire,
and examine this in more detail.   However, at my present understanding,
the implementation and specification do not present the same independence
one finds in Ada.   Perhaps someone will post an example.

Thanks for your details reply.

Richard 

Re: Separate Compilation in Programming Languages

[adaworks]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:q760s392l0g6klikofa4gs2ba4jiv1isf0@4ax.com...
>
> One language which does have an equivalent mechanism (perhaps not 
> surprisingly,
> given its origin), and in which a similar debate is currently active, is VHDL.
>
I would like to know more about this debate.   Could you provide
some sources for review.   You may send me an email at my office
if you wish:  rdriehle@nps.edu

Thanks

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> > But there is a way to manage explicit dependencies: express the public
> > facing APIs in terms of interfaces with implementation classes that truly
> > hide the actual implementation.
>
> I considered Interfaces.  They appear, at first glance, to be a solution.
> However, they fall short of what we are seeking here.  Once the Interface is
> implemented, the rest of the software still depends on that implementation
> and there is no model of separate compilation at that point where one can
> separate the specification from the implementation.  The dependency becomes
> bound to the implementation of the Interface not to the Interface
> abstraction.

I don't understand what you mean. The rest of the software explicitly does not
depend on that implementation. That is the point of using an interface.

I have made such interface-based APIs, and would tend to build API clients
with only the public API present. The implementation would be loaded at run
time. The client could not ever be effected by implementation changes; it
could not even see the implementation.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> Even with an interface, a la Java, once the interface is implemented, the
> children dependent on that unit will be dependent on the implementaion,
> not on the interface.

This is not true. I can show you code if you are interested.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wcc63wfpus7.fsf@shell01.TheWorld.com...
>> <adaworks@sbcglobal.net> writes:
>>
>>> My concern is dependency management.
>>
>> OK, but I still don't fully understand what you're getting at.
>> You said elsewhere in this thread that you are NOT concerned with
>> recompilation costs.  That's good -- recompilation cost should
>> primarily be an implementation concern.
>>
> Sometimes recompilation costs are important.

Yes, of course.  If the implementation can't recompile my entire program
in less than 0.2 second, then it's too slow.  Here, "too slow" means I
wish it would be faster.  ;-)  But recompilation speed is primarily
an implementation issue, although the language design can facilitate
fast compilers.

>...This is true for very
> large software systems where one does not want to recompile the
> entire system for one change somewhere way down in a function
> within one package body.

Sure, but a well-designed incremental compilation facility is strictly
better than the usual Ada way of doing this.

>> I'm guessing that your point has nothing to do with "compilation" at
>> all, separate or otherwise.  It has to do with the organization of the
>> program into separate source files -- specifically separation of spec
>> and body (interface and implementation, to use more language-neutral
>> terms).  Right?
>>
> Right.  My primary concern, in this discussion,is with dependency management.
>
>>
>> OK, so you like having textually separate spec and body,
>> as do I.  But what specific advantages are you talking
>> about in this thread?
>>
>> Readability?  That is, when looking at a client of A, you don't
>> need to worry about X,Y,...S.  This is good, but it's got little to do
>> with separate compilation.
>>
> In my view, it does.  The less code I have to look at to make a
> change or to understand the code, the better.  Granted, this does
> not always work as well as I might like, but it frequently is of
> value.

I don't understand the above paragraph.  You claim it DOES have to do
with compilation, but then you talk about how much code you (a human)
have to look at, which has nothing whatsoever to do with compilation.

>> Source modification?  A change in X could introduce a bug
>> into a client of A -- so there really _is_ a dependency
>> in that sense.
>>
> However, the dependency is at the iimplementation level, not at
> the specification level.
>
>> One advantage of Ada over some languages (e.g. C) is that the
>> implementation can know what source files are part of each program,
>> by following the with clauses.  I really hate having to write a make
>> file that lists out all the .o files that need to be linked together --
>> Ada allows that to be completely automated (that's what gnatmake does).
>>
> Well, Yes.   If, in one of my separately compiled subprograms within a
> package body Q, uses a depth-search routine from a parent package
> specification K, and we decide to use the breadth-search instead, there
> is no need to alter any part of the package specification of Q.  It remains
> stable.
>
> This becomes an architectural issue, as well.   The more stable my
> architecture when a change is made to some element of that architecture,
> the better for my overall design.
>
>> Something else?
>>
>> Note that Ada requires some implementation details to appear in the
>> package spec -- namely, the stuff that goes in the private part, plus
>> the with clauses needed by that private part.  That's ugly, IMHO.
>>
> Modula-2 solved that problem through the use of opaque types. I
> often code opaque types in Ada using access types.   This eliminates
> any dependencies at the specification level, in many cases.

Right, but there's a huge disadvantage of Modula-2's opaque types, and
the Ada equivalent using access types: namely, you now have to deal
with heap management.

>...As you
> know, the private part of a package was a compromise that allows
> separate compilation.

A completely unnecessary compromise.  This particular area of Ada
(private parts) really is a mess, IMHO.

> We can even create a tagged type as an opaque type, thereby hiding
> any implementation details and still making that type extensible.  This
> was difficult in Modula-2, so the designers of Modula-3 also had to
> make some compromises.   Engineering is always about trade-offs
> between conflicting solutions.

Not always.  Sometimes there's a way that's uniformly better
than the alternatives.

>...Java certainly has its share of trade-offs.
>>
>> Shrug.  I don't use "is separate" much.  Child packages are almost
>> always better, because you can separate the spec _and_ the body,
>> and because the parent need not know about the child.  Child packages
>> provide the same advantage of being able to "push down" the
>> dependencies.
>>
> I did not mention Child packages, but you are certainly correct that they
> are a powerful contributing solution to this issue.   In particular, private
> children are a great benefit.   However, in very large software systems,
> a million SLOC or more, "is separate" continues to play an important
> role.

I don't see why the size of the software has anything to do with
subunits vs. child units.  Subunits are occassionally useful,
but child units are usually better (for large systems and small),
and are never much worse.  You can always change code that uses
subunits to use child units instead, in a way that avoids changing
any clients, at the cost of some annoying verbosity.

>...As noted earlier, specifications should be an architectural concern,
> and the more stable an architecture, the better.   Implementation should
> be dependent on architecture, not the other way around.
>
> When I want to change the upholstery in my car, I don't want to have to
> alter the architecture of that car.   I don't want the performance of the car
> to depend on whether I choose Zebra seat covers or chartreuse trim
> on green Naugahyde.
>
>>> I don't think this is possible in Java, Eiffel, or C#.
>>
>> It's possible using interfaces.  Clients of an interface do not depend
>> on classes that implement the interface, any more than clients of an Ada
>> package spec depend on its body.  You suggested otherwise elsewhere in
>> this thread, but I think you're wrong, or else I'm misunderstanding what
>> you mean by "depend".
>>
>> Interfaces are more flexible than spec/body in that they allow multiple
>> "bodies".  And of course Ada 2005 has interfaces.  Note that an
>> interface will typically be declared in a package spec with no
>> corresponding body.
>>
> Even with an interface, a la Java, once the interface is implemented, the
> children dependent on that unit will be dependent on the implementaion,
> not on the interface.

You said that before, and my response is as above: I think you're wrong,
or else I'm misunderstanding what you mean by "depend".  For example:

    package P1 is
        type Iface is interface;
        ... declare some abstract procedures ...
    end P1;

    package P2 is
        pragma Elaborate_Body;
        -- Note that this package spec can be entirely empty (except we
        -- need the pragma so we are allowed to have a body).
        -- So this package spec isn't defining any interface to
        -- anything at all!
    end P2;

    with P1;
    package body P2 is
        type Impl is new P1.Iface with ...
        ... override procedures ...
        ...
    end P2;

    -- No body for P1!

Then the client can "with P1", and call operations on Iface objects
without knowing anything about package P2 (neither spec nor body).
There is no dependence of clients on P2 (unless I'm misunderstanding
what you mean by "depend").

It works the same way in Java, which is not surprising, since Ada's
interfaces were designed with Java interfaces in mind.

>...And Java still has no way of separating the
> specification of that implementing class from its implementation.

...which is irrelevant, since clients don't depend on that class.

>...In
> another forum (comp.lang.programming) someone submitted an
> example to show how interfaces would solve this problem, but the
> example did not separate interface from implementation..
> 
>> Eiffel has separate specs and bodies -- except that the spec is
>> automatically generated from the body, rather than being written by
>> hand.  I prefer to consider the spec to be a source file in its own
>> right, as in Ada, but it's not _that_ different from Eiffel.
>>
> Yes.  In Ada, the specification is most certainly a separate source
> file.  As noted earlier, the specifications and the relatioships between
> specifications, represent the overall architecture of the software
> system.   I'll take another look at Eiffel, a language design I do admire,
> and examine this in more detail.   However, at my present understanding,
> the implementation and specification do not present the same independence
> one finds in Ada.   Perhaps someone will post an example.

Eiffel doesn't have specs in the language.  They're just pieces of text
automatically generated by a separate tool.  But they serve the same
purpose as Ada's specs -- you can read them to understand the interface
supported by a given class.

> Thanks for your details reply.

...and thanks for an interesting discussion.

> Richard 

- Bob

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccbq679zah.fsf@shell01.TheWorld.com...

In the example you provided (shown below) you did defer the with clause
for the Package P1 to the package body of P2.   This illustrates my point.
If the specification for P1 changes, only the body for P2 needs to be  compiled.
Had the with clause been at the specification level for P2, and had the
specification for P1 changed, the entire package would have had to be
compiled.

I think the same is true for Java.   If the specification for the Interface is
changed, everything needs to be recompiled.   In Ada, by deferring the
with clause to the package body, we only need to re-compile the body.

So, I think your example actually supports my original assertion.  The
essential point is that changes in the specifications for a package (or
a Java class) should not require re-compilation of the dependent
specifications.   Only the implementations should be dependent on
other specifications.   This has the effect of keeping the high-level
architecture more stable.

  package P1 is
        type Iface is interface;
        ... declare some abstract procedures ...
    end P1;

    package P2 is
        pragma Elaborate_Body;
        -- Note that this package spec can be entirely empty (except we
        -- need the pragma so we are allowed to have a body).
        -- So this package spec isn't defining any interface to
        -- anything at all!
    end P2;

    with P1;
    package body P2 is
        type Impl is new P1.Iface with ...
        ... override procedures ...
        ...
    end P2;

    -- No body for P1!

Then the client can "with P1", and call operations on Iface objects
without knowing anything about package P2 (neither spec nor body).
There is no dependence of clients on P2 (unless I'm misunderstanding
what you mean by "depend").

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:u3arjcxx3.fsf@STRIPCAPStelus.net...
> <adaworks@sbcglobal.net> writes:
>> Even with an interface, a la Java, once the interface is implemented, the
>> children dependent on that unit will be dependent on the implementaion,
>> not on the interface.
>
> This is not true. I can show you code if you are interested.
>
I think I was not clear.   When a specification (interface, package 
specification,
etc.) remains stable, the implementation is not as much of a factor as changes
in the specification.   When one specification is dependent on another, a change
to the parent specification will require recompiling all of the dependent
specifications.   When the effect of the specification is deferred to the 
implementation
level, none of the other specifications should have to be compiled.   This is 
quite
easy to do in Ada.

When the dependencies are deferred to the implementation module (an Ada
package body) a change to a parent specification requires only that body to
be recompiled.   When the specification is at the level of another 
specification,
and a change is made to a higher level unit, everything needs to be recompiled.

I think this is as true of Java as it is of Ada.   The only difference is that 
Ada allows
one to defer the dependency to the package body.   This does not seem to be
true of Java.   I hope I am more clear.   If not, perhaps someone can state it 
more
clearly than I since it is a pretty simple idea.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> When the dependencies are deferred to the implementation module (an Ada
> package body) a change to a parent specification requires only that body to
> be recompiled.  When the specification is at the level of another
> specification, and a change is made to a higher level unit, everything needs
> to be recompiled.

No, not necessarily. It is quite possible that the only an implementation was
client of the changed spec, and that the change's effects do not perculate
out. That is, the change is not transitive.

> I think this is as true of Java as it is of Ada.  The only difference is
> that Ada allows one to defer the dependency to the package body.  This does
> not seem to be true of Java. 

The deferral to a package body is precisely equivalent to the deferral to
another implementation class. The implementation class is (or can be) private,
hidden in exactly the same way the body of a package is.

That is what allows Java interfaces to serve as equivalent controls for
separate compilation as Ada's package bodies. Mind you, they're not
necessarily as convenient, mind you, but I am objecting only to the notion
that Java does not support separate compilation.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccbq679zah.fsf@shell01.TheWorld.com...
>
> In the example you provided (shown below) you did defer the with clause
> for the Package P1 to the package body of P2.   This illustrates my point.
> If the specification for P1 changes, only the body for P2 needs to be  compiled.
> Had the with clause been at the specification level for P2, and had the
> specification for P1 changed, the entire package would have had to be
> compiled.

Earlier, you said that this conversation was not about compilation
costs, but now you seem quite interested in compilation costs.
That's OK.  So let's talk about compilation costs.  ;-)

I think you miss the point of my example (still shown below).
Package P1 is the interface, and P2 is the implementation
of that interface.  P2 is NOT a client of P1, it's an
implementation of P1!

There are perhaps 37 clients of P1, not shown.  The question is,
if we modify the implementation (i.e. P2) do we need to recompile
those 37 clients.  The answer is "no".

As you point out, if you change the interface, you have to recompile the
implementation.  That's true in my example.  It's also true if
the interface/implementation is split in the more traditional
Ada way (spec/body).

The issue of recompiling the spec of P2 is irrelevant, since it's empty!

> I think the same is true for Java.   If the specification for the Interface is
> changed, everything needs to be recompiled.   In Ada, by deferring the
> with clause to the package body, we only need to re-compile the body.
>
> So, I think your example actually supports my original assertion.  The
> essential point is that changes in the specifications for a package (or
> a Java class) should not require re-compilation of the dependent
> specifications.   Only the implementations should be dependent on
> other specifications.   This has the effect of keeping the high-level
> architecture more stable.
>
>   package P1 is
>         type Iface is interface;
>         ... declare some abstract procedures ...
>     end P1;
>
>     package P2 is
>         pragma Elaborate_Body;
>         -- Note that this package spec can be entirely empty (except we
>         -- need the pragma so we are allowed to have a body).
>         -- So this package spec isn't defining any interface to
>         -- anything at all!
>     end P2;
>
>     with P1;
>     package body P2 is
>         type Impl is new P1.Iface with ...
>         ... override procedures ...
>         ...
>     end P2;
>
>     -- No body for P1!
>
> Then the client can "with P1", and call operations on Iface objects
> without knowing anything about package P2 (neither spec nor body).
> There is no dependence of clients on P2 (unless I'm misunderstanding
> what you mean by "depend").

Let me try a more concrete example -- the trusty stack example.

First, the traditional Ada way, using what you like to call "opaque"
types:

    package Stacks is
        type Stack is private;
        procedure Push(...);
        ...
    private
        type Stack_Rec;
        type Stack is access Stack_Rec;
    end Stacks;

    package Stacks is
        type Stack_Rec is record ...;
        procedure Push(...) is
        begin
           ...
        end Push;
        ...
    end Stacks;

If we change the implementation of the stacks abstraction (i.e. the body
of package Stacks), we do not normally need to recompile the clients.

We can accomplish the same thing with interfaces.  I'll use a child
package this time, just for fun:

    package Stacks is
        type Stack is interface;
        procedure Push(...) is abstract;
        ...
    end Stacks;

    package Stacks.Implementation is
        type Stack_Impl is new Stack with private;
    private
        type Stack_Impl is ...;
        overriding procedure Push(...);
        ...
    end Stacks.Implementation;

    package Stacks.Implementation is

        procedure Push(...) is
        begin
           ...
        end Push;
        ...
    end Stacks.Implementation;

If we change the implementation of the stacks abstraction (i.e. the
package Stacks.Implementation -- spec or body, it doesn't matter), we do
not normally need to recompile the clients.

Both ways of writing the stacks abstraction have the same property --
the 37 clients that say "with Stacks" do not need to be recompiled when
we modify the implementation.

The second example matches what is normally done in Java, except that in
Java, we wouldn't split the implementation into two parts.  Note that in
the second example, that split has no value, since there are no clients
of Stacks.Implementation.  In fact, in some cases, we can choose to move
all of the code from the spec of Stacks.Implementation to its body (as I
did in my P1/P2 example), making the spec empty.

(I'm glossing over the fact that there probably needs to be some sort of
factory for creating stack objects, but that's not relevant to my
point.)

- Bob

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

>...  When the effect of the specification is deferred to the
>implementation level, none of the other specifications should have to
>be compiled.  This is quite easy to do in Ada.

Except for those pesky private parts.  And generics.  :-(

- Bob

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccve4eff0d.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>> news:wccbq679zah.fsf@shell01.TheWorld.com...
>>
>> In the example you provided (shown below) you did defer the with clause
>> for the Package P1 to the package body of P2.   This illustrates my point.
>> If the specification for P1 changes, only the body for P2 needs to be 
>> compiled.
>> Had the with clause been at the specification level for P2, and had the
>> specification for P1 changed, the entire package would have had to be
>> compiled.
>
> Earlier, you said that this conversation was not about compilation
> costs, but now you seem quite interested in compilation costs.
> That's OK.  So let's talk about compilation costs.  ;-)
>
Actually, it is not about compilation "cost." Rather, it is about architecture
stability, where compilation does play a role.

> I think you miss the point of my example (still shown below).
> Package P1 is the interface, and P2 is the implementation
> of that interface.  P2 is NOT a client of P1, it's an
> implementation of P1!
>
> There are perhaps 37 clients of P1, not shown.  The question is,
> if we modify the implementation (i.e. P2) do we need to recompile
> those 37 clients.  The answer is "no".
>
Yes.  I agree.  When we defer the implementation to the body, there is
no need to recompile anything, unless the implementation is tightly
bound to the specification.   The architectural concern is when we
recompile the specification.   Any change to the specification will
imply a change to everything dependent upon it.

> As you point out, if you change the interface, you have to recompile the
> implementation.  That's true in my example.  It's also true if
> the interface/implementation is split in the more traditional
> Ada way (spec/body).
>
This is not true in the traditional Ada way when the dependencies are
deferred to the implementation level.   When the specification is dependent
on something that has changed, it is true.   When the specification is not
dependent on that change, the high-level architecture remains intact and
does not need recompiling.

> The issue of recompiling the spec of P2 is irrelevant, since it's empty!
>
In your example, you have deferred the dependency to the body of P2.
So there is no need to recompile the spec for P2. However, if the with
clause had been at the specification level of P2, and if the specification
for P1 had changed, there is certainly a danger of an architectural
problem if we did not recompile the specification and body for P2.

>
> Let me try a more concrete example -- the trusty stack example.
>
> First, the traditional Ada way, using what you like to call "opaque"
> types:
>
Opaque type is not my name for this.  It seems to be a commonly accepted
term for the idiom.

>    package Stacks is
>        type Stack is private;
>        procedure Push(...);
>        ...
>    private
>        type Stack_Rec;
>        type Stack is access Stack_Rec;
>    end Stacks;
>
>    package Stacks is
>        type Stack_Rec is record ...;
>        procedure Push(...) is
>        begin
>           ...
>        end Push;
>        ...
>    end Stacks;
>
> If we change the implementation of the stacks abstraction (i.e. the body
> of package Stacks), we do not normally need to recompile the clients.
>
Correct.  A change to the implementation does not require a recompilation.
However, a change to the specification does.   Also, in the example shown,
you accidentally omitted the word "body" from the implementation unit.

> We can accomplish the same thing with interfaces.  I'll use a child
> package this time, just for fun:
>
>    package Stacks is
>        type Stack is interface;
>        procedure Push(...) is abstract;
>        ...
>    end Stacks;
>
>    package Stacks.Implementation is
>        type Stack_Impl is new Stack with private;
>    private
>        type Stack_Impl is ...;
>        overriding procedure Push(...);
>        ...
>    end Stacks.Implementation;
>
>    package Stacks.Implementation is
>
>        procedure Push(...) is
>        begin
>           ...
>        end Push;
>        ...
>    end Stacks.Implementation;
>
> If we change the implementation of the stacks abstraction (i.e. the
> package Stacks.Implementation -- spec or body, it doesn't matter), we do
> not normally need to recompile the clients.
>
Note the inadventant omission of the word "body" in the example.

I agree, we do not need to recompile the clients or dependent children
if only the implementation has changed.    This is exactly my point.  When
the scope clause (with clause) is deferred to the package body, the
dependencies are also deferred to that level.   When the dependencies
are at the specification level, and some specification on which there is
a dependency changes, the specification does have to be recompiled.
This is the point of deferring with clauses to the body.

It is not about recompilation costs.  It is about preservatation of 
architectural
integrity.   When any parent unit changes, there should be as few other
changes as possible, especially at the architectural level.   If the entire
architecture is characterized by with clauses at the specification level,
then the entire architecture must be recompiled, and potentially evalutated
to preserve that architecture's stability.

> Both ways of writing the stacks abstraction have the same property --
> the 37 clients that say "with Stacks" do not need to be recompiled when
> we modify the implementation.
>
Agree.  It is not about modifying the implementation, in Ada. The package
body is unlikely to have any dependency issues in Ada.

> The second example matches what is normally done in Java, except that in
> Java, we wouldn't split the implementation into two parts.  Note that in
> the second example, that split has no value, since there are no clients
> of Stacks.Implementation.  In fact, in some cases, we can choose to move
> all of the code from the spec of Stacks.Implementation to its body (as I
> did in my P1/P2 example), making the spec empty.
>
I don't think so.   In you example, there are no dependencies.  If there were,
and if those dependencies were additional children, we could certainly have
issues at the specification level.   In your opaque type example, those
dependencies are less severe if we provide appropriate query function to
ensure the client (or child unit) can query the state of the elements of a
type instance during its lifetime.

Whenever one unit has an existing dependency on another, a change that
affects that dependency needs to be addressed.   While I admire the
virtues of the Interface model in Java and Ada, the dependency concerns
have not vanished with the introduction of Interfaces.

An Interface requires an implementation.   One of its virtues is that it can
have multiple implementations.   Each implementation will have its own
identifier.   If the specification for the Interface should change, everything
dependent on that interface will also change.    If that change could be
deferred to the implementation of a dependent class instead of the class
specification, that change would have less effect on the rest of the
architecture.  In Ada, this is usually pretty easy.

In a separate reply, you mentioned generics.   In most cases, there is no
reason why a generic cannot be instantiated at the package body level.
Further, I am not asserting that dependencies can always be deferred. One
example of this is Ada.Finalization which must be with'ed at the package
specification level.   There are other examples.

My contention is that the Ada model of dependency management is far
superior to most other models for the preservation of architectural
stability.   Am I alone in this view?

Richard Riehle 

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ulk5a8zcu.fsf@STRIPCAPStelus.net...
> <adaworks@sbcglobal.net> writes:
>> When the dependencies are deferred to the implementation module (an Ada
>> package body) a change to a parent specification requires only that body to
>> be recompiled.  When the specification is at the level of another
>> specification, and a change is made to a higher level unit, everything needs
>> to be recompiled.
>
> No, not necessarily. It is quite possible that the only an implementation was
> client of the changed spec, and that the change's effects do not perculate
> out. That is, the change is not transitive.
>
Absolutely true, and confirmation of my original point.  We want to defer
dependencies to the implementation whenever possible so those changes
do not "percolate" throughout the rest of the architecture.

>> I think this is as true of Java as it is of Ada.  The only difference is
>> that Ada allows one to defer the dependency to the package body.  This does
>> not seem to be true of Java.
>
Agree.  It certainly does not seem to be true of Java.

> The deferral to a package body is precisely equivalent to the deferral to
> another implementation class. The implementation class is (or can be) private,
> hidden in exactly the same way the body of a package is.
>
> That is what allows Java interfaces to serve as equivalent controls for
> separate compilation as Ada's package bodies. Mind you, they're not
> necessarily as convenient, mind you, but I am objecting only to the notion
> that Java does not support separate compilation.
>
Java's notion of separate compilation is not evil.  However, it does fall short
of what can be done in Ada.   Interfaces, while such a good idea in Java that
they have been adopted by Ada, do not solve the dependency issue and do
not provide the capabilities for architectural integrity possible in Ada.  An
implementation of an Interface (in Java) is still tightly bound to its 
specification,
and any change of that implementation will carry forward.  It is true that the
Interface specification remains unchanged, and that is a good thing.  However,
if any part of the Interface specification changes, every other unit dependent
on that specification will also have to be recompiled.   In the Ada model, where
I defer the dependency on that Interface to the body of the dependent package,
I need not recompile the specification of the dependent package.   Rather,
I can compile only the body, leaving the rest of my architecture intact.

I'm not sure why this is such a difficult idea.  It is probably because I am not
expressing it with sufficient skill.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> Yes.  I agree.  When we defer the implementation to the body, there is
> no need to recompile anything, unless the implementation is tightly
> bound to the specification.   The architectural concern is when we
> recompile the specification.   Any change to the specification will
> imply a change to everything dependent upon it.

Right, but in Java, you can always move that dependence into an
implementation of an interface, just like you can move that dependence
down into a package body in Ada.

> In your example, you have deferred the dependency to the body of P2.
> So there is no need to recompile the spec for P2. However, if the with
> clause had been at the specification level of P2, and if the specification
> for P1 had changed, there is certainly a danger of an architectural
> problem if we did not recompile the specification and body for P2.

Yes, the spec of P2 would need to be recompiled in that case.
I don't see why that's an "architectural problem".

>> First, the traditional Ada way, using what you like to call "opaque"
>> types:
>>
> Opaque type is not my name for this.  It seems to be a commonly accepted
> term for the idiom.

Well, the only time I've heard "opaque type" is in the Modula-N context,
and in cases where you have imported the term into the Ada context.
The usual term for this is "stt access types" or "Taft Amendment types",
named after their inventor.

> Correct.  A change to the implementation does not require a recompilation.
> However, a change to the specification does.   Also, in the example shown,
> you accidentally omitted the word "body" from the implementation unit.

Yes, thanks for pointing out that I forgot "body".

>> If we change the implementation of the stacks abstraction (i.e. the
>> package Stacks.Implementation -- spec or body, it doesn't matter), we do
>> not normally need to recompile the clients.
>>
> Note the inadventant omission of the word "body" in the example.

Another missing "body" -- thanks again.

> I agree, we do not need to recompile the clients or dependent children
> if only the implementation has changed.    This is exactly my point.  When
> the scope clause (with clause) is deferred to the package body, the
> dependencies are also deferred to that level.   When the dependencies
> are at the specification level, and some specification on which there is
> a dependency changes, the specification does have to be recompiled.
> This is the point of deferring with clauses to the body.

Right.  But the point of my example is that you can always defer the
"with" to an implementation of an interface.

> In a separate reply, you mentioned generics.   In most cases, there is no
> reason why a generic cannot be instantiated at the package body level.

I don't agree with that.  In my experience, when I declare a type T,
I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to
clients, that is done by generic instantiation.

> My contention is that the Ada model of dependency management is far
> superior to most other models for the preservation of architectural
> stability.   Am I alone in this view?

I'm not entirely sure what you mean by "architectural stability" here,
but I guess I'd agree if you changed "far superior" to "slightly more
convenient". ;-)

- Bob

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:

> An implementation of an Interface (in Java) is still tightly bound to
> its specification, and any change of that implementation will carry forward.

But of course. And that is exactly analogous a change to an Ada package spec
impacting the package body.

> It is true that the Interface specification remains unchanged, and that is a
> good thing.  However, if any part of the Interface specification changes,
> every other unit dependent on that specification will also have to be
> recompiled.  

Again, exactly the same as changing an Ada package spec.

> In the Ada model, where I defer the dependency on that
> Interface to the body of the dependent package, I need not recompile the
> specification of the dependent package.  Rather, I can compile only the
> body, leaving the rest of my architecture intact.

Recompiling a file does not imply the need to imply client files if the
public signatures have not changed. Most IDEs can handle this.

Also, recompiling an implementation class will not cause a recompilation of
the interface clients at all, since they do not even (necessarily) see the
implemetation in the first place.

Again, exactly analogous to an Ada package body needing to be
recompiled. Ada's separation of spec and body is what allows you to do this. A
Java interface and its implementation class is an analogous separation.

> I'm not sure why this is such a difficult idea.  It is probably because I am
> not expressing it with sufficient skill.

Well, as politely as possible, I submit that it is not about the skill, but
that I think you are mistaken.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:uy799dama.fsf@STRIPCAPStelus.net...
> <adaworks@sbcglobal.net> writes:
>
>> An implementation of an Interface (in Java) is still tightly bound to
>> its specification, and any change of that implementation will carry forward.
>
> But of course. And that is exactly analogous a change to an Ada package spec
> impacting the package body.
>
>> It is true that the Interface specification remains unchanged, and that is a
>> good thing.  However, if any part of the Interface specification changes,
>> every other unit dependent on that specification will also have to be
>> recompiled.
>
> Again, exactly the same as changing an Ada package spec.
>
Only when dependencies are at the specification level.  But, in Ada we
can defer the dependency to the package body.  In Java you cannot
defer that dependency.  A dependent unit, when the specification
changes is combined with its implementation.   Therefore, every dependent
specification must also be compiled.   As noted below, we can defer
the dependency in Ada to the package body.  There is nothing analogous
to this in Java.

>> In the Ada model, where I defer the dependency on that
>> Interface to the body of the dependent package, I need not recompile the
>> specification of the dependent package.  Rather, I can compile only the
>> body, leaving the rest of my architecture intact.
>
> Recompiling a file does not imply the need to imply client files if the
> public signatures have not changed. Most IDEs can handle this.
>
Exactly my point.  If the public signatures do not change, there is no
need for recompilation.  When the public signature does change, the
entire dependent architecture goes out of phase.  If, however, that public
signature change is isolated to the the implementation files, the separately
compiled package body (as it is in Ada) the architecture remains intact.

In Java, all public signatures, including implementations, are dependent on
parent public signatures.  There is no way to separate them.   When one
changes, everything dependent on that one change is also changed.  In
Ada, we move the dependency to the pacakge body so changes to a
specification has no effect on the Ada specification, thereby preserving
architectural integrity.   This is not possible, as nearly as I can tell from
all the examples given to me so far, in Java.

> Also, recompiling an implementation class will not cause a recompilation of
> the interface clients at all, since they do not even (necessarily) see the
> implemetation in the first place.
>
> Again, exactly analogous to an Ada package body needing to be
> recompiled. Ada's separation of spec and body is what allows you to do this. A
> Java interface and its implementation class is an analogous separation.
>
>> I'm not sure why this is such a difficult idea.  It is probably because I am
>> not expressing it with sufficient skill.
>
> Well, as politely as possible, I submit that it is not about the skill, but
> that I think you are mistaken.
>
Perhaps.  But I still don't see how one can defer the dependency of a
Java signature to the implementation of the Java class and prevent
the need for recompiling the entire architecture when the signature of
a parent class changes.   The ripple effect through the entire chain
of dependencies when one of those signatures changes is almost
certain to be affected by such a change of signature.   If Java can
somehow accomodate that change automatically, it must be some
kind of magic that is not immediately apparent, even to the Java
developers I know.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Jean-Pierre Rosen]

adaworks@sbcglobal.net a �crit :
> What
> is your view of Ada-style separate compilation when compared to that in other 
> languages?
> Do you find it useful in your own practice?

I think that the most useful feature is separate compilation of specs 
and bodies.

When designing a module (a body), you can design the specifications of 
the modules that you will need to implement it (what I call an 
abstraction layer). Then you can compile your body against these 
specifications, and make sure you specs serve the intended purpose 
/before/ any implementation effort. You can even provide body stubs, and 
prototype your abstraction layer.

With Ada's separate compilation features, you do not only design 
top-down, you can also code top-down.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Separate Compilation in Programming Languages

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> Perhaps.  But I still don't see how one can defer the dependency of a
> Java signature to the implementation of the Java class and prevent
> the need for recompiling the entire architecture when the signature of
> a parent class changes.   The ripple effect through the entire chain
> of dependencies when one of those signatures changes is almost
> certain to be affected by such a change of signature.

I think perhaps what you are missing is that in Java, you can use the
same "trick" all along the chain.  (The "trick" illustrated by the
examples I showed.)

E.g., in Ada, you are advocating something like this:

    E spec (no with's)
    E body (says "with D")

    D spec (no with's)
    D body (says "with C")

    C spec (no with's)
    C body (says "with B")

    B spec (no with's)
    B body (says "with A")

    A spec (no with's)
    A body (no with's)

...to the extent possible, pushing with's into bodies.
So if, say, B spec changes, you need to recompile
B body and C body, but not (down the chain) D or E.
Here, we have 10 source files.

The analogous thing with interfaces is:

    E interface (no with's)
    E.Implementation (says "with D")

    D interface (no with's)
    D.Implementation (says "with C")

    C interface (no with's)
    C.Implementation (says "with B")

    B interface (no with's)
    B.Implementation (says "with A")

    A interface (no with's)
    A.Implementation (no with's)

In Ada, each "implementation" is a spec and a body, whereas in Java it's
just one class file -- but that's irrelevant.  In Ada, we have 15 source
files (5 of which are empty or nearly so), but in Java, only 10, as in
the previous Ada case.

If you change B interface, you have to recompile B.Implementation (spec
and body) and C.Implementation (spec and body), but not anything down
the chain (D/E).

Note that in this method, there are no dependences on the Implementation
packages, or very few.  Clients such as C.Implementation do NOT say
"with B.Implementation"!

(I'm ignoring private parts and generics, which throw a monkey wrench
into the works.)

>...If Java can
> somehow accomodate that change automatically, ...

Ah, maybe that's the problem.  No, it's not automatic.
In Java, you have to choose to split out all those interfaces,
all down the chain.  And you have to take care to make every
implementation class depend on interfaces, rather than other
implementations.  A simpler structure is:

    E (says "with D")

    D (says "with C")

    C (says "with B")

    B (says "with A")

    A (no with's)

(except Java doesn't call it "with").  In this simpler structure, you do
indeed have the ripple effect you're worried about.

>...it must be some
> kind of magic that is not immediately apparent, even to the Java
> developers I know.

It's not magic!  It requires effort.  It is perhaps easier in Ada.
But I think the "trick" (or "technique") is well known among
Java programmers.

- Bob

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> But, in Ada we can defer the dependency to the package body.  In Java you
> cannot defer that dependency.  A dependent unit, when the specification
> changes is combined with its implementation.  Therefore, every dependent
> specification must also be compiled.  As noted below, we can defer the
> dependency in Ada to the package body.  There is nothing analogous to this
> in Java.

This is simply false.

I am starting to think that *I* don't have the sufficient communication
skills. There is a fundamental disconnect here.

Consider this Ada situation:

  Client C ------> Package P spec
                     |
                     |
                   P body

When P's spec changes, both C and P's body need to be recompiled.

When only P's body changes, C is unaffected.

Consider this Java situation:

  Client C ------> interface P_Spec
                     |
                     |
                   class P_Body implements P

When P_Spec changes, both C and P_Body need to be recompiled.

When only P_Body changes, C is unaffected, P_Spec is unaffected.

I don't know how else to say it more clearly.

Note that if anyone is referring to P_Body then they will be affected, but the
idea is that one takes the care so the clients only use P_Spec. This takes
effort and discipline, making things less convenient than Ada, but the ability
to have the separation is there in the Java language.

> Perhaps.  But I still don't see how one can defer the dependency of a
> Java signature to the implementation of the Java class and prevent
> the need for recompiling the entire architecture when the signature of
> a parent class changes.   

Maybe the disconnect is here. Are you talking about how spec changes ripple
down, or are you talking about how body changes ripple down? Spec changes
affect clients and bodies, both in Java in Ada. Body (implementation) do not
affect clients that only refer to the spec, both in Java and Ada.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> > Perhaps.  But I still don't see how one can defer the dependency of a
> > Java signature to the implementation of the Java class and prevent
> > the need for recompiling the entire architecture when the signature of
> > a parent class changes.   
> 
> Maybe the disconnect is here. Are you talking about how spec changes ripple
> down, or are you talking about how body changes ripple down? Spec changes
> affect clients and bodies, both in Java in Ada. Body (implementation) do not
> affect clients that only refer to the spec, both in Java and Ada.

It also occurs to me to wonder if you were assuming the Java interface and
implementation are in the same file. If so, the issues you say would indeed
happen. 

But usually the interface and its implementations are in separate files, as
per the usual Java rule of one class per file. That separation is what allows
Java to have separate compilation.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[John W. Kennedy]

Ray Blaak wrote:
> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>>> Perhaps.  But I still don't see how one can defer the dependency of a
>>> Java signature to the implementation of the Java class and prevent
>>> the need for recompiling the entire architecture when the signature of
>>> a parent class changes.   
>> Maybe the disconnect is here. Are you talking about how spec changes ripple
>> down, or are you talking about how body changes ripple down? Spec changes
>> affect clients and bodies, both in Java in Ada. Body (implementation) do not
>> affect clients that only refer to the spec, both in Java and Ada.
> 
> It also occurs to me to wonder if you were assuming the Java interface and
> implementation are in the same file. If so, the issues you say would indeed
> happen. 
> 
> But usually the interface and its implementations are in separate files, as
> per the usual Java rule of one class per file. That separation is what allows
> Java to have separate compilation.

Actually, this doesn't accomplish as much as you wish, in practice, as 
it will eventually be necessary to have a constructor for the real 
class, or else a static factory method.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:uprulnd6u.fsf@STRIPCAPStelus.net...
>
> Maybe the disconnect is here. Are you talking about how spec changes ripple
> down, or are you talking about how body changes ripple down? Spec changes
> affect clients and bodies, both in Java in Ada. Body (implementation) do not
> affect clients that only refer to the spec, both in Java and Ada.
>
That is, indeed, the disconnect.    When a specification changes, the effect
will ripple downward.   This is not true of Ada when with clause for the
a package is deferred to the package body.    When the with clause is
at the package specification, the effect certainly does ripple downward.

With the exception of the Interface model, in Java, all signature changes
occur at a level which will have that ripple effect.   In some circumstances,
an Interface will alleviate this concern.   However, Interfaces are only
a small part of the story when designing with Java.   So, most Java
designs will incur a penalty for this inability to separate the specification
(the signature) from the implementation, thereby deferring dependencies
to the package body as we can do in Ada.

Also, the dependency model in Java can lead to some strange behaviors,
including circular dependencies.  This is one reason why tools such as
Ant, Maven, and Ivy have been invented -- to detect dependency
problems that are so easily created with standard Java.  Such problems
have the potential of disrupting the software architecture and Java
programmers realize they must be very careful about doing just that.

So. Yes.  There has been a disconnnect.   In Ada, we can defer the
dependencies to the package body, regardless of what kind of package
we are designing -- with or without Interfaces.   Java is much more
limited in this regard.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ulk58of6r.fsf@STRIPCAPStelus.net...
> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>> > Perhaps.  But I still don't see how one can defer the dependency of a
>> > Java signature to the implementation of the Java class and prevent
>> > the need for recompiling the entire architecture when the signature of
>> > a parent class changes.
>>
>> Maybe the disconnect is here. Are you talking about how spec changes ripple
>> down, or are you talking about how body changes ripple down? Spec changes
>> affect clients and bodies, both in Java in Ada. Body (implementation) do not
>> affect clients that only refer to the spec, both in Java and Ada.
>
> It also occurs to me to wonder if you were assuming the Java interface and
> implementation are in the same file. If so, the issues you say would indeed
> happen.
>
> But usually the interface and its implementations are in separate files, as
> per the usual Java rule of one class per file. That separation is what allows
> Java to have separate compilation.
>
But only for Interface-based designs.   Further, the implementation of the
Interface, with its extended signature is in the same file with the algorithmic
code.  This is significantly different from how we design in Ada where the
implementation code (package body) is kept separate from the specification.
Also, if the signature of the Interface changes, everything dependent on that
signature will also have to change.   And everything dependent on that
Interface implementation will have to change.  The ripple-effect will occur
since most of a Java design is not based on Interfaces, and that is the
problem with inability to defer dependencies as we can in Ada.

Richard Riehle
> -- 
> Cheers,                                        The Rhythm is around me,
>                                               The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul. 

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccmyppg7yd.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
>> Yes.  I agree.  When we defer the implementation to the body, there is
>> no need to recompile anything, unless the implementation is tightly
>> bound to the specification.   The architectural concern is when we
>> recompile the specification.   Any change to the specification will
>> imply a change to everything dependent upon it.
>
> Right, but in Java, you can always move that dependence into an
> implementation of an interface, just like you can move that dependence
> down into a package body in Ada.
>
Even if this completely accurate, the vast majority of Java applications
use only a small number of packages that consist of interfaces.  The
rest of the design does not use the Interface model.   For those classes,
in those packages, the dependency problem is not only possible but,
after doing some additional research today, I find is fairly common.

>> In your example, you have deferred the dependency to the body of P2.
>> So there is no need to recompile the spec for P2. However, if the with
>> clause had been at the specification level of P2, and if the specification
>> for P1 had changed, there is certainly a danger of an architectural
>> problem if we did not recompile the specification and body for P2.
>
> Yes, the spec of P2 would need to be recompiled in that case.
> I don't see why that's an "architectural problem".
>
It is an architectural problem because, in Java, a corrupted dependency,
something that apparently actually occurs in large-scale Java designs,
is also going to corrupt the architecture of the software.  As noted in
a separate post, this problem has required the introduction of special
dependency management tools such as Ivy, Maven, and Ant -- and
these tools are not yet able to detect all the problems though they are
getting better.

Every software entity has an architecture, planned or ad hoc.  One of the
more important aspects of an architecture is to take every action possible
to reduce or manage dependencies between the artifacts of that
architecture.   The separate compilation model of Ada does that better
than most other languages.  Modula has some virtues in this respect.
However, the research I have been doing on Java leads me to believe
that the language has significant weaknesses in architectural stability
for large-scale systems.   There are quite a few articles on the Internet
describing these problems..
>
> Right.  But the point of my example is that you can always defer the
> "with" to an implementation of an interface.
>
Even if we allow for the benefit of the Interface in this situation, we have not
dealt with the larger body of a Java program that is not built using Interfaces.

>> In a separate reply, you mentioned generics.   In most cases, there is no
>> reason why a generic cannot be instantiated at the package body level.
>
> I don't agree with that.  In my experience, when I declare a type T,
> I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to
> clients, that is done by generic instantiation.
>
But that does not have to be instantiated at the package spec level.  In many
cases, the instantiation is possible, and preferred at the body level.  Granted,
we sometimes have to instantiate at the spec level,  but not always.  Java
templates are usually instantiated at the specification level, and that most
certainly introduces a level of dependency with system-wide effects.

>> My contention is that the Ada model of dependency management is far
>> superior to most other models for the preservation of architectural
>> stability.   Am I alone in this view?
>
> I'm not entirely sure what you mean by "architectural stability" here,
> but I guess I'd agree if you changed "far superior" to "slightly more
> convenient". ;-)
>
Architectural stability implies that, except under extraordinary circumstances,
any change to some artifact of the architecture will have minimal impact on
the rest of that architecture.   This is one valuable property of Ada's ability
to let us defer most of our dependencies to the lowest level of the design
possible.  This is not a property of Java, C++, or most other languages
in current use today.  Even incremental compilation falls a little short. Oh,
and does Rational Apex  still support incremental compilation in Ada? GNAT
is not the only Ada environment around.

Richard Riehle

Re: Separate Compilation in Programming Languages

[Alex R. Mosteo]

Ray Blaak wrote:
> <adaworks@sbcglobal.net> writes:
>> But, in Ada we can defer the dependency to the package body.  In Java you
>> cannot defer that dependency.  A dependent unit, when the specification
>> changes is combined with its implementation.  Therefore, every dependent
>> specification must also be compiled.  As noted below, we can defer the
>> dependency in Ada to the package body.  There is nothing analogous to this
>> in Java.
> 
> This is simply false.
> 
> I am starting to think that *I* don't have the sufficient communication
> skills. There is a fundamental disconnect here.
> 
> Consider this Ada situation:
> 
>   Client C ------> Package P spec
>                      |
>                      |
>                    P body
> 
> When P's spec changes, both C and P's body need to be recompiled.
> 
> When only P's body changes, C is unaffected.
> 
> Consider this Java situation:
> 
>   Client C ------> interface P_Spec
>                      |
>                      |
>                    class P_Body implements P
> 
> When P_Spec changes, both C and P_Body need to be recompiled.
> 
> When only P_Body changes, C is unaffected, P_Spec is unaffected.
> 
> I don't know how else to say it more clearly.
> 
> Note that if anyone is referring to P_Body then they will be affected, but the
> idea is that one takes the care so the clients only use P_Spec. This takes
> effort and discipline, making things less convenient than Ada, but the ability
> to have the separation is there in the Java language.

I'd go farther and say that proper OO programming practice stresses the
fact that  clients must operate on interfaces, and not on particular
implementation classes. Yes, it takes discipline, but it is what is
expected. (Or what I would expect?)

Still, having used both Java and Ada, I find true that Ada, by forcing
always the separation, helps in "indoctrinating" this into programmers.
Specifications in Ada are a blessing.

Re: Separate Compilation in Programming Languages

[Stephen Leake]

<adaworks@sbcglobal.net> writes:

> The ripple-effect will occur
> since most of a Java design is not based on Interfaces, 

This is a description of a common Java _practice_, not a requirement
of the Java _language_.

So, as others have said, keeping the interface specification separate
from the implementation is _easier_, and possibly more common, in Ada.
But it is also _possible_ in Java.

-- 
-- Stephe

Re: Separate Compilation in Programming Languages

[adaworks]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uprujvnv4.fsf@stephe-leake.org...
> <adaworks@sbcglobal.net> writes:
>
>> The ripple-effect will occur
>> since most of a Java design is not based on Interfaces,
>
> This is a description of a common Java _practice_, not a requirement
> of the Java _language_.
>
> So, as others have said, keeping the interface specification separate
> from the implementation is _easier_, and possibly more common, in Ada.
> But it is also _possible_ in Java.
>
But, as Mr. Kennedy notes in a separate contribution to this
thread,

"Actually, this doesn't accomplish as much as you wish, in practice, as
it will eventually be necessary to have a constructor for the real
class, or else a static factory method."

Until I began this conversation, and after doing additional research, I
was unaware of just how bad the situation with Java was.   The more
I examined this issue, with that additional research, it became clear
that Ada's model is even better than I had realized.

All the protestations in favor of Java simply fail to square with the
reality of Java practice.

Richard Riehle


> -- 

> -- Stephe 

Re: Separate Compilation in Programming Languages

[adaworks]

"Alex R. Mosteo" <amosteo@unizar.es> wrote in message 
news:62ic8uF230f4oU1@mid.individual.net...
>
> I'd go farther and say that proper OO programming practice stresses the
> fact that  clients must operate on interfaces, and not on particular
> implementation classes. Yes, it takes discipline, but it is what is
> expected. (Or what I would expect?)
>
The reality is that this practice is rare.  Interfaces are not as abundant
in Java programs as you might wish.

> Still, having used both Java and Ada, I find true that Ada, by forcing
> always the separation, helps in "indoctrinating" this into programmers.
> Specifications in Ada are a blessing.

Yes.  Prior to the conversation in this thread, I was not as sure of that
as I am now.   It has become clear to me that the Ada model, based
on the notion of compilation units, continues to be much better than
the Java model where, in practice, dependency management on
large-scale software systems can range from simply annoying to
absolutely wrong.

The argument from C++ programmers use to be, "We don't have
such problems if we are careful ..."   "... if we are good programmers ..."
"... if we follow good practices ..."

But the fact is that a language design needs to prevent "bad practices"
and Ada tends to do that.   When hundreds of messages appear on
the Internet complaining about Java's dependency problems, this is
an indication that the issue is not about programming practice, but about
a deficiency in the design of the language.

Richard Riehle

Re: Separate Compilation in Programming Languages

[Alex R. Mosteo]

adaworks@sbcglobal.net wrote:

> The argument from C++ programmers use to be, "We don't have
> such problems if we are careful ..."   "... if we are good programmers ..."
> "... if we follow good practices ..."

Of course C/C++ with the transitive, low level #include mechanism are
even in a worse situation.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

"John W. Kennedy" <jwkenne@attglobal.net> writes:
> Actually, this doesn't accomplish as much as you wish, in practice, as it will
> eventually be necessary to have a constructor for the real class, or else a
> static factory method.

That is true. There are ways around this. The simplest way is to have a
factory class that is dynamically loaded by some other startup class that
client code does not see. That way clients are never affected by the
implementation classes.

interface IWidgetFactory
{
  // Root client API methods:
  public IWidget createWidget(blah, blah) {...}
  ...
}

class WidgetFactoryAccess
{
  static private IWidgetFactory instance = null;

  static public IWidgetFactory getInstance() {return instance;}

  // Called by start up logic.
  static public void register(IWidgetFactory f) {instance = f;}
}

You can also do tricks like dynamically loading the implementation class at
runtime from some environment-specified jar. That way there are also no
compilation dependencies.

Again, all this takes effort and discipline. For larger applications, one also
needs to take the trouble to control the subsystem layering, since a good
orthogonal design actually improves compilation times when the dependencies
are minimized.

This kind of thing is easier in Ada.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> > But usually the interface and its implementations are in separate files, as
> > per the usual Java rule of one class per file. That separation is what allows
> > Java to have separate compilation.
> >
> But only for Interface-based designs.   

Well yes. The point is only that it is possible in Java, the denial of which
is what I was objecting to.

Furthermore, interface designs are indeed done in practice when necessary
precisely since they address the situations when dependencies need to be
controlled.

> Further, the implementation of the Interface, with its extended signature is
> in the same file with the algorithmic code.

Actually no. This is highly unusual. The vast majority of implementation
classes would reside in different files from their inferfaces.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> But, as Mr. Kennedy notes in a separate contribution to this
> thread,
> 
> "Actually, this doesn't accomplish as much as you wish, in practice, as
> it will eventually be necessary to have a constructor for the real
> class, or else a static factory method."

I have addressed this question in another post. There are perfectly adequate
work arounds.

Ada does dependency control better, but it is perfectly possible in Java, and
I make use of these techniques myself.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> It is an architectural problem because, in Java, a corrupted dependency,
> something that apparently actually occurs in large-scale Java designs,
> is also going to corrupt the architecture of the software.  As noted in
> a separate post, this problem has required the introduction of special
> dependency management tools such as Ivy, Maven, and Ant -- and
> these tools are not yet able to detect all the problems though they are
> getting better.

Does the existence of gnatmake indicate corrupted dependency management in
Ada?

Tools like Ant fill the same kind of role.

> Architectural stability implies that, except under extraordinary
> circumstances, any change to some artifact of the architecture will have
> minimal impact on the rest of that architecture.  This is one valuable
> property of Ada's ability to let us defer most of our dependencies to the
> lowest level of the design possible.  This is not a property of Java, C++,
> or most other languages in current use today.

I program in a lot of languages, and I used to be heavily into Ada. I just do
not encounter the problem in a serious way with the other languages.

I easily agree that Ada is better at this, but in every language I use
currently, there are always ways to readily control dependency and separate
compilation issues.

It's just not a problem in practice.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Ray Blaak]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> <adaworks@sbcglobal.net> writes:
> > Further, the implementation of the Interface, with its extended signature is
> > in the same file with the algorithmic code.
> 
> Actually no. This is highly unusual. The vast majority of implementation
> classes would reside in different files from their inferfaces.

I think I misread this. Yes, or course, the implementation contains the
algorithmic code. That is the point. But clients need not see this class, and
thus are not impacted by changes to it.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>> <adaworks@sbcglobal.net> writes:
>> > Further, the implementation of the Interface, with its extended signature is
>> > in the same file with the algorithmic code.
>> 
>> Actually no. This is highly unusual. The vast majority of implementation
>> classes would reside in different files from their inferfaces.
>
> I think I misread this. Yes, or course, the implementation contains the
> algorithmic code. That is the point. But clients need not see this class, and
> thus are not impacted by changes to it.

I initially misread it the same way you did, I think ("the interface is
in the same file as...") but on second reading, I see Richard is correct
-- "the IMPLEMENTATION OF the interface WITH ITS EXTENDED SIGNATURE is
in the same file as...", here emphasized.

I agree, though, that "clients need not see this class...".

- Bob

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:uhcfv5xql.fsf@STRIPCAPStelus.net...
>
> Does the existence of gnatmake indicate corrupted dependency management in
> Ada?
>
No. It might indicate a problem with the GNAT implementation, but not
with Ada.  Not all Ada compilers are GNAT, and some handle this
more easily.   One of the issues for GNAT is that it depends on
the GNU model.  This is not true of Rational Apex, Aonix, or
even the ICC compiler.

> I program in a lot of languages, and I used to be heavily into Ada. I just do
> not encounter the problem in a serious way with the other languages.
>
I also program in a lot of languages.  I even program in Java sometimes.
However, I have not programmed any large-scale programs in Java,
as I have in Ada.

Although you have certainly made your point that my original statement
may have been too strong, this conversation has, as noted in another
contribution, led me to do some research into this issue.  What I have
found is not encouraging.  In fact, it is even a little horrifying.

As Java programs get larger, the dependency problems become more
and more messy.   Over and over this is discussed by  various forums
on the Internet.   Until I began researching this, I had not idea just how
pervasive the problem was in Java.

Apparently, for toy programs, and small projects this problem with Java
does not manifest itself.  However, as Java programs get larger, the
programmers are required to do a lot of workarounds.   Further, the
compiler does not actually trap all the kinds of errors that can occur
with dependency issues.  Third-party tools are required to analyze these
problems, and those third-party tools are not foolproof -- at least, not
so far.

> I easily agree that Ada is better at this, but in every language I use
> currently, there are always ways to readily control dependency and separate
> compilation issues.
>
This may be true in your practice, but there are hundreds of developers out
there who are find this to be a real problem.   As I see it right now, Ada
continues to be a much better solution when a software architecture is
large and needs to scale-up to even larger.

The scary thing for me, now that I am in the DoD, is that so many contractors
are naive about this issue and continue to insist on using Java for weapon
systems development. In my view, based on this week's research, Java should
not be used for safety-critical systems.  There are too many possibilities for
serious hidden problems based on these dependency issues.   It is probably
OK for Web solutions, but no one will accidentally get killed or maimed
because of a corrupted Internet solution.   Ooooops!   I forgot about SOA
where reusable components are integrated into safety-critical solutions.  I
guess it is better to be safe and not use it at all for any kind of software
where life and limb could be at risk.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
> news:uhcfv5xql.fsf@STRIPCAPStelus.net...
> >
> > Does the existence of gnatmake indicate corrupted dependency management in
> > Ada?
> >
> No. It might indicate a problem with the GNAT implementation, but not
> with Ada.  Not all Ada compilers are GNAT, and some handle this
> more easily.   One of the issues for GNAT is that it depends on
> the GNU model.  This is not true of Rational Apex, Aonix, or
> even the ICC compiler.

I guess what I object to here is the idea that tools like gnatmake or Ant
indicate a problem at all.

GNAT's library model lives on a different place on the tradeoff curve as
compared to the other Ada vendors. It allows some problems to be avoided at
the expense of suffering from other possible problems that the other Ada
vendors do not.

It is also pretty simple.

So, if one considers gnatmake to be an essential part of the GNAT build
system, then my view is that this how the build dependency problem is solved
for GNAT. 

There is no problem with the implementation as such.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> <adaworks@sbcglobal.net> writes:
>> "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
>> news:uhcfv5xql.fsf@STRIPCAPStelus.net...
>> >
>> > Does the existence of gnatmake indicate corrupted dependency management in
>> > Ada?
>> >
>> No. It might indicate a problem with the GNAT implementation, but not
>> with Ada.  Not all Ada compilers are GNAT, and some handle this
>> more easily.   One of the issues for GNAT is that it depends on
>> the GNU model.  This is not true of Rational Apex, Aonix, or
>> even the ICC compiler.
>
> I guess what I object to here is the idea that tools like gnatmake or Ant
> indicate a problem at all.

I agree.  I'm completely mystified by Richard's assertion that the
existence of gnatmake might indicate a problem with GNAT.  Any decent
Ada implementation comes with a tool that knows how to rebuild (what to
recompile/relink/whatever, and in what order, if that matters) based on
what source files changed.  The fact that such a tool can exist is one
thing that makes Ada better than (for example) C.

What does the "GNU model" mean, by the way?

> GNAT's library model lives on a different place on the tradeoff curve as
> compared to the other Ada vendors. It allows some problems to be avoided at
> the expense of suffering from other possible problems that the other Ada
> vendors do not.

What's the "suffering" you see here?

- Bob

Re: Separate Compilation in Programming Languages

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > GNAT's library model lives on a different place on the tradeoff curve as
> > compared to the other Ada vendors. It allows some problems to be avoided at
> > the expense of suffering from other possible problems that the other Ada
> > vendors do not.
> 
> What's the "suffering" you see here?

None myself. I am speaking theoretically. There must be *some* advantage to the
library approaches the other vendors use, right? Right? :-)

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[Randy Brukardt]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message
news:uwsoq6khn.fsf@STRIPCAPStelus.net...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > > GNAT's library model lives on a different place on the tradeoff curve
as
> > > compared to the other Ada vendors. It allows some problems to be
avoided at
> > > the expense of suffering from other possible problems that the other
Ada
> > > vendors do not.
> >
> > What's the "suffering" you see here?
>
> None myself. I am speaking theoretically. There must be *some* advantage
to the
> library approaches the other vendors use, right? Right? :-)

At the user level, they all pretty much look the same. The differences
between Gnatmake and Corder (in Janus/Ada) aren't that significant - both
allow the building of a program and recompilation of any needed
dependencies. The details of the implementation are quite different, of
course, but that's not very relevant to using either compiler. And what I've
seen about other compilers also are pretty similar (ignoring some "advanced
capabilities" that hardly anyone would use).

There are big differences in the tradeoffs at the implementation level, and
those manifest themselves in terms of significant differences in compilation
speed, memory footprint, and needed disk space. (Although with the massive
disks and CPU speeds of today, those differences are much less important
than they used to be).

                                  Randy.

Re: Separate Compilation in Programming Languages

[Georg Bauhaus]

Ray Blaak wrote:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> GNAT's library model lives on a different place on the tradeoff curve as
>>> compared to the other Ada vendors. It allows some problems to be avoided at
>>> the expense of suffering from other possible problems that the other Ada
>>> vendors do not.
>> What's the "suffering" you see here?
> 
> None myself. I am speaking theoretically. There must be *some* advantage to the
> library approaches the other vendors use, right? Right? :-)

E.g., gnatmake without gnatchop is incomplete. The GNAT
compiler proper succeeds translating Ada programs when the
source text is organized into one-file:one-unit. Or, maybe you'll
have to create a number of specially named files in the presence
of subunits. The advantages have been explained...

Q: "What source files is the compilation system actually using?"

The answer would probably have to be a detailed
one in the GNAT case. For other compilers, it might be

A: "Read the file that lists the units."

GNAT's default model delegates source code organisation to
the programmer, suggesting a suitable set of files. (The
advantages have been explained...). This doesn't remove a need
for tools that let you switch views of spec and body.
Can you submit this Ada source program to just gnatmake?

-- %< -- %< -- %<
procedure Foo;
--  Does nothing, really

procedure Foo is
begin
    null;
end Foo;
-- %< -- %< -- %<

Perhaps gnatchop with gnatmake is be easier to implement
than some other schemes. The advantages have been explained...

But in the end, gnatchop + gnatmake is good enough.
Just use the GNAT scheme for every Ada project. ;-)

Re: Separate Compilation in Programming Languages

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccfxverpyo.fsf@shell01.TheWorld.com...
>
> I agree.  I'm completely mystified by Richard's assertion that the
> existence of gnatmake might indicate a problem with GNAT.  Any decent
> Ada implementation comes with a tool that knows how to rebuild (what to
> recompile/relink/whatever, and in what order, if that matters) based on
> what source files changed.  The fact that such a tool can exist is one
> thing that makes Ada better than (for example) C.
>
It was not my intention to suggest any problem with GNAT.   I probably
did not phrase my response to the question very well.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccfxverpyo.fsf@shell01.TheWorld.com...
> >
> > I agree.  I'm completely mystified by Richard's assertion that the
> > existence of gnatmake might indicate a problem with GNAT.  Any decent
> > Ada implementation comes with a tool that knows how to rebuild (what to
> > recompile/relink/whatever, and in what order, if that matters) based on
> > what source files changed.  The fact that such a tool can exist is one
> > thing that makes Ada better than (for example) C.
> >
> It was not my intention to suggest any problem with GNAT.   I probably
> did not phrase my response to the question very well.

In the interests of keeping any controversy alive, if you accept the use of
tools that help an Ada compiler know what to rebuild based on what source
files have changed, how is the use of tools that help a Java compiler to do
the same thing a sign of deficient dependency control? I.e. Ant.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:u1w6y87fd.fsf@STRIPCAPStelus.net...
>
> I guess what I object to here is the idea that tools like gnatmake or Ant
> indicate a problem at all.
>
Both tools are needed, and I am not implying any problem with gnatmake.

My issue is with Java and its many many many problems with dependency
management.  The tools available for Java are apparently incomplete and
hundreds of developers are complaining about those problems.  Further,
I just read an article in IEEE Software by Charlie Kai describing some
entertaining security problems in Java that simply do not exist in Ada.

My concern is that Java is being used for software systems where our
military personnel have their lives on the line, and the more I learn
about Java, the more worried I am about that software.    It is an OK
language for small software systems where no one's life is at risk,
but it apparently does not scale up well without the potential for a
great many problems.

Consequently, I will, whenever I can, recommend against using Java
for military safety-critical software systems.  Ada, although not
perfect, continues to be the most appropriate foundation for
safety-critical software development.    It is, even with its minor
flaws, less flawed than any of the alternatives.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Alex R. Mosteo]

Ray Blaak wrote:
> <adaworks@sbcglobal.net> writes:
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
>> news:wccfxverpyo.fsf@shell01.TheWorld.com...
>>> I agree.  I'm completely mystified by Richard's assertion that the
>>> existence of gnatmake might indicate a problem with GNAT.  Any decent
>>> Ada implementation comes with a tool that knows how to rebuild (what to
>>> recompile/relink/whatever, and in what order, if that matters) based on
>>> what source files changed.  The fact that such a tool can exist is one
>>> thing that makes Ada better than (for example) C.
>>>
>> It was not my intention to suggest any problem with GNAT.   I probably
>> did not phrase my response to the question very well.
> 
> In the interests of keeping any controversy alive, if you accept the use of
> tools that help an Ada compiler know what to rebuild based on what source
> files have changed, how is the use of tools that help a Java compiler to do
> the same thing a sign of deficient dependency control? I.e. Ant.

I guess the difference here is that Ada mandates a consistent build
environment, be it via some library or what gnat does, while with Java
you must go out to look for extra tools explicitly, and the features of
these extra tools are not clearly defined by the Java spec. But I'm
jumping in late and could be wrong.

Re: Separate Compilation in Programming Languages

[adaworks]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message 
news:ud4qgnvqt.fsf@STRIPCAPStelus.net...
>
> In the interests of keeping any controversy alive, if you accept the use of
> tools that help an Ada compiler know what to rebuild based on what source
> files have changed, how is the use of tools that help a Java compiler to do
> the same thing a sign of deficient dependency control? I.e. Ant.
>
Tools are fine.  Every programming language benefits from tools.   As I
noted in another post, there is no perfect programming language.  However,
the problems of Java are inherent in the language design.   While we all
know that C++ is a language that is error-prone, that is not what we would
expected of Java.

On the other hand, Ada is a more consistent design that does not have as
many design flaws as Java, and certainly not nearly as many as C++.  In
the case of C++, the tools have never been enough.   For Java, it turns
out, the tools are also insufficient for ensuring that language-based problems
are elmininated from an application design, especially when that application
is a large-scale software system.

My concern is the dependability of software systems embedded in the tools
and weapons used by our military personnel.   They go into battle, placing
their lives on the line using the software tools we provide.   I long ago 
realized
that any decision to use C++ for these kinds of systems was irresponsible
(unless C++ was reigned-in drastically, as it is on JSF).  I did not, until
recently, worry as much about Java.   Now, with my recent investigation of
Java, I have concluded that it is also fraught with problems that can (and
apparently do) produce errors in software that are difficult to trace and
even more difficult to predict.

The more I examine the evidence about Java, the more I realize it is not
dependable enough for the kind of systems where people's lives are at
stake. Therefore, I will, as noted earlier, recommend against the use of
Java for military systems where dependability is an issue, whenever I can.

When we are required to apply engineering practices in the development of
computer software, neither C++ nor Java are sufficiently well-designed to
measure-up to a rigorous model of engineering.   Ada also falls short in some
respects, but is not as bad as the alternatives.  SPARK certainly comes closer
to satisfying engineering principles and practices.   As of this moment, there 
is
no language that satisfies engineering as well as we might like.  But that does 
not
justify using languages that are so flawed that an engineer cannot depend on 
them
to actually behave in predictable ways.

Richard Riehle 

Re: Separate Compilation in Programming Languages

[Ray Blaak]

<adaworks@sbcglobal.net> writes:
> The more I examine the evidence about Java, the more I realize it is not
> dependable enough for the kind of systems where people's lives are at
> stake. Therefore, I will, as noted earlier, recommend against the use of
> Java for military systems where dependability is an issue, whenever I can.
> 
> When we are required to apply engineering practices in the development of
> computer software, neither C++ nor Java are sufficiently well-designed to
> measure-up to a rigorous model of engineering.  Ada also falls short in some
> respects, but is not as bad as the alternatives.  SPARK certainly comes
> closer to satisfying engineering principles and practices.  As of this
> moment, there is no language that satisfies engineering as well as we might
> like.  But that does not justify using languages that are so flawed that an
> engineer cannot depend on them to actually behave in predictable ways.

In spite of my rooting for Java with regards to dependency control, I
basically agree with the position of preferring Ada for rigorous environments.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.