Is Ada the future? [was: Is C++ the future?]

Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

The original question was, "Is C/C++ the future?"  The
answer is "probably not" (modulo side discussions on
"the future of what?").  Although C and C++ may reason-
ably be considered "the present" for the same sorts of
applications and markets that Ada is intended to target,
they are not the future state of the art for those mar-
kets.

The new question is, "Is *Ada* the future?" -- for those
same applications and markets.  And the answer is, again,
"probably not."  Although Ada is (arguably) technically
superior to C++ in many regards, it is not a *sufficient*
improvement as to warrant abandoning C++ as a language of
choice.  In other words, it would not be cost effective
for most orginizations (that have a choice) to dump their
investment in C++ and switch to Ada9x.

The future will be some new language (or an enhanced ver-
sion of some existing language) that solves new problems
in ways that C++ and Ada can not.

Convince me that I'm wrong.

More's the point (if dual-use is to succeed), convince
commercial development companies that I'm wrong.

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[David Weller]

(Of course, y'all just _knew_ I'd say something here :-)

In article <milodCwwqMy.CK@netcom.com>,
John DiCamillo <milod@netcom.com> wrote:
>
>The new question is, "Is *Ada* the future?" -- for those
>same applications and markets.  And the answer is, again,
>"probably not."  Although Ada is (arguably) technically
>superior to C++ in many regards, it is not a *sufficient*
>improvement as to warrant abandoning C++ as a language of
>choice.  In other words, it would not be cost effective
>for most orginizations (that have a choice) to dump their
>investment in C++ and switch to Ada9x.
>
In general, I agree that it would be unwise to abandon using C++ in
favor of Ada 9X.  The economics of changing languages is staggering
-- politically _and_ technically.  If I was knee deep in C++, you'd
have a snowball's chance in hell of convincing me to change.

However, heavy C++ usage is the exception in the C/C++ world, not the
rule.  Ada 9X, in fact, is a "smarter" language to migrate to for C
users.  Just ask these guys:
	- Bob Metcalfe, Editor of InfoWorld and creator of the Ethernet
	standard
	- Peter Coffee, regular columnist of PC Week
	- Alexander Wolfe, regular columnist of Electronic Engineering
	Times
	- Jerry Pournelle, noted author and regular columnist in Byte
	magazine.

>The future will be some new language (or an enhanced ver-
>sion of some existing language) that solves new problems
>in ways that C++ and Ada can not.
>
I, for one, would welcome such a language.  In the meantime, I have a
responsibility to write reliable software.  Ada 9X does that for me
in ways that C++ folks are now only dreaming about.

>Convince me that I'm wrong.
>
I can't.  Making Ada successful starts from the heart.  Mandates
won't do it, threats won't do it, and long-winded debates and
language flamewars won't do it.  You must _believe_ that you can
succeed, and you must _believe_ you will succeed by using Ada.

>More's the point (if dual-use is to succeed), convince
>commercial development companies that I'm wrong.
>
Agreed.  But this is a change that requires time.  C++ has gained a
lot of momentum, but there's room for other languages (Eiffel,
Smalltalk, and Ada).  Nobody has to come out "on top".  The real
winner will be the language that is the most interoperable.  Guess
which on stands the best chance? :-)



-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

dweller@Starbase.NeoSoft.COM (David Weller) writes:
>John DiCamillo <milod@netcom.com> wrote:
>>The new question is, "Is *Ada* the future?" -- for those
>>same applications and markets.  And the answer is, again,
>>"probably not."

>In general, I agree that it would be unwise to abandon using C++ in
>favor of Ada 9X.  The economics of changing languages is staggering
>-- politically _and_ technically.  If I was knee deep in C++, you'd
>have a snowball's chance in hell of convincing me to change.

>However, heavy C++ usage is the exception in the C/C++ world, not the
>rule.

True enough, with one caveat: in the personal/workstation world
most C programmers are using C++ compilers (all that the vendors
now sell).  This makes the transition easier.

>Ada 9X, in fact, is a "smarter" language to migrate to for C
>users.

But not politically easie.  Technically, I'd say it's a push.
There's a lot to learn either way.

>Just ask these guys:
>	- Jerry Pournelle, noted author and regular columnist in Byte
>	magazine.

While I like Jerry's column, I'm not prepared to take language
advice from him.  Jeez, the guy likes OS/2 for heaven's sakes!

>>The future will be some new language (or an enhanced ver-
>>sion of some existing language) that solves new problems
>>in ways that C++ and Ada can not.
>I, for one, would welcome such a language.  In the meantime, I have a
>responsibility to write reliable software.  Ada 9X does that for me
>in ways that C++ folks are now only dreaming about.

Not *all* of us are dreaming.  Some of us are doing.

>>More's the point (if dual-use is to succeed), convince
>>commercial development companies that I'm wrong.

>Agreed.  But this is a change that requires time.  C++ has gained a
>lot of momentum, but there's room for other languages (Eiffel,
>Smalltalk, and Ada).  Nobody has to come out "on top".

Of course not.  Ada will survive for quite a while on the
DoD's anemic backing alone.  But if Ada folks expect non-
mandated use to rise beyond a blip, they will have to make
clear *what* advantage Ada provides to the developer.  Some-
thing along the lines of:

C++       - based on C, efficient, popular (widely available)
Eiffel    - correctness, good library, good IDE
Smalltalk - simple, expressive, dynamic, interpreted
Ada9x     - ???

--milo

P.S. "Team OS/2"?  sheesh!

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[Robert I. Eachus]

In article <milodCx0K79.11n@netcom.com> milod@netcom.com (John DiCamillo) writes:

  > Of course not.  Ada will survive for quite a while on the
  > DoD's anemic backing alone.  But if Ada folks expect non-
  > mandated use to rise beyond a blip, they will have to make
  > clear *what* advantage Ada provides to the developer.  Some-
  > thing along the lines of:

  > C++       - based on C, efficient, popular (widely available)
  > Eiffel    - correctness, good library, good IDE
  > Smalltalk - simple, expressive, dynamic, interpreted
  > Ada9x     - ???

   Let me be the first to fill in the blank:

   Ada9X -- safe, reliable, maintainable, best choice for large projects.

   (I'm not sure of the best way to state the last.  Everyone in this
group should know that I mean something like:  If you are writing more
than a half-million lines of code in any language other than Ada, you
should have your head and budget examined.  But that doesn't fit in a
single snappy line.)

   I also have to object to the "efficient" in the C++ line.  Any good
C++ programmer knows how to skate around the holes in the ice.  But
doing that results in "C-like" code, not C++.  A better statement
might be "efficient interface to C," but a lot of other languages have
that too.

--

					Robert I. Eachus

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

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <milodCx0K79.11n@netcom.com> milod@netcom.com (John DiCamillo) writes:

>  > C++       - based on C, efficient, popular (widely available)
>  > Eiffel    - correctness, good library, good IDE
>  > Smalltalk - simple, expressive, dynamic, interpreted
>  > Ada9x     - ???

>   Let me be the first to fill in the blank:
>   Ada9X -- safe, reliable, maintainable, best choice for large projects.

Please define "safe" and "reliable" in this context.  How
are they different?  How are they the same?  How are they
different from "correctness" in the Eiffel feature-list?

Languages are not maintainable.  Rather, programs are main-
tainable.  A good language and environment coupled with
dedicated engineers and good development practices can pro-
mote the generation of maintainable code.  In what specific
ways does Ada9x promote program maintainability that are
*not* provided by C++ or Eiffel?

>   (I'm not sure of the best way to state the last.  Everyone in this
>group should know that I mean something like:  If you are writing more
>than a half-million lines of code in any language other than Ada, you
>should have your head and budget examined.  But that doesn't fit in a
>single snappy line.)

It's also ludicrous.  In any event, given the first three
items, the last is implied.

>   I also have to object to the "efficient" in the C++ line.  Any good
>C++ programmer knows how to skate around the holes in the ice.  But
>doing that results in "C-like" code, not C++.

The last sentence is untrue for most definitions of "C-like".
C++ does not require the programmer to use a procedural style
to gain efficiency.

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[Robb Nebbe]

In article <milodCx46t7.FIB@netcom.com>,
   milod@netcom.com (John DiCamillo) writes:

|> Languages are not maintainable.  Rather, programs are main-
|> tainable.  A good language and environment coupled with
|> dedicated engineers and good development practices can pro-
|> mote the generation of maintainable code.  In what specific
|> ways does Ada9x promote program maintainability that are
|> *not* provided by C++ or Eiffel?

In my opinion there are two important factors that make software
maintainable. The ability to define an abstraction and have the
compiler enforce this abstraction and the ability for the person
doing the maintenance to understand the abstraction.

For defining and particularly enforcing an abstraction you could
make a fairly strong case that Ada is better than C++. The case
wouldn't be that you can't define and enforce an abstraction in
C++, which would be a bit naive, but that in some cases the effort
required goes far beyond what is required in Ada.

Understandability is probably more closely related to the quality
of the code than the language used but I know for a fact that the
language has at least some influence. I have yet to see any Ada
code as badly written as some of the C I have seen (not even close
in fact).

- Robb Nebbe

Re: Is Ada the future? [was: Is C++ the future?]

[John Volan]

merlin@annwfn.com (Fred McCall) writes:

>In <1994Oct4.090807@di.epfl.ch> Robb.Nebbe@di.epfl.ch Robb Nebbe writes:

>>The case
>>wouldn't be that you can't define and enforce an abstraction in
>>C++, which would be a bit naive, but that in some cases the effort
>>required goes far beyond what is required in Ada.

>I disagree. In fact, the circumlocutions shown here recently in order to
>get mutual recursion seem to me to show that it is *harder* in Ada, not
>easier. 

Decoupled mutual recursion is only one particular kind of situation
that is somewhat harder to do in Ada.  It's not impossible, and in
fact it doesn't really require drastic circumlocutions to achieve it
(see my solution on another thread).  But to use this as a broad brush
to paint all of Ada as being obstructive to abstraction, is not
entirely fair.

The reason decoupled mutual recursion is *somewhat* harder in Ada has
to do with broader decisions that pervade the design of the language,
relating to modularity, encapsulation, separate compilation, scope,
visibility, and so forth.  IMHAARO (In My Humble And Admittedly
Religious Opinion :-), those design decisions lead to a "cleaner"
treatment of abstraction in most other areas, which is desirable
even if it comes at the expense of some difficulty in this one area.
But I'll let other folks fight that language war ... :-)

>If you detect some annoyance on my part, you're right.  Some (note that
>that's 'some', not 'all') of the Ada proponents in this group leave me
>feel like I'm talking to converted Amigoids.  It appears to be the same
>sort of viewpoint.  Ada is *not* the Number 1 language on the planet in
>popularity and you're not going to change that by obnoxiously bashing
>the languages that are.  If you expect to convert people by telling them
>that they're stupid rather than by pointing out *REAL* advantages of the
>language, then Ada9X isn't going to do any better than Ada83 has (and
>you'd better pray that the Mandate is continued).

Well, would it help if some of us "Ada Amigoids" did the following: 

(1) Honestly raise a technical issue wherever Ada appears to be weak.

(2) Face that issue squarely and with dogged persistence, refusing to
be satisfied by "solutions" that merely avoid the problem or
trivialize it, rather than actually solving it.

(3) Be just as persistent in being dissatisfied with schemes that
replace the original problem with even worse problems, or workarounds
that require horrendous circumlocutions.

(4) Be even more persistent in rejecting "solutions" that require
changing the language itself in ways that do violence to its
underlying design principles.

(5) And in the end, show how Ada can, in fact, overcome the problem
cleanly and elegantly, by virtue of other strengths that it already
has at its disposal.

Would that, perhaps, convert a few more zealots from other denominations? :-)

-- John Volan

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------

Re: Is Ada the future? [was: Is C++ the future?]

[Matt Kennel]

John Volan (jgv@swl.msd.ray.com) wrote:
: The reason decoupled mutual recursion is *somewhat* harder in Ada has
: to do with broader decisions that pervade the design of the language,
: relating to modularity, encapsulation, separate compilation, scope,
: visibility, and so forth.

Specifically what are these decisions?  As far as I can tell, 
you could allow mutual dependency with no other change to the
language except saying "it is now allowed", and let the compiler
do The Right Thing that it should have done to begin with.

Why doesn't it?

: Well, would it help if some of us "Ada Amigoids" did the following: 

: (1) Honestly raise a technical issue wherever Ada appears to be weak.

: (2) Face that issue squarely and with dogged persistence, refusing to
: be satisfied by "solutions" that merely avoid the problem or
: trivialize it, rather than actually solving it.

Exactly.  Solve the problem.  

The core issue:  doing this should be possible.  (Indeed it
was hard for me to imagine that it should ever have been
not possible).

-- Obvious Eiffel construction.
class ONE is
 	a:TWO;
end;

class TWO is
	b:ONE;
end;


: -- John Volan

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

Matt, exactly what *is* the *right thing*?

Re: Is Ada the future? [was: Is C++ the future?]

[Robb Nebbe]

mbk@inls1.ucsd.edu (Matt Kennel) writes:

|> 
|> The core issue:  doing this should be possible.  (Indeed it
|> was hard for me to imagine that it should ever have been
|> not possible).
|> 
|> -- Obvious Eiffel construction.
|> class ONE is
|>  	a:TWO;
|> end;
|> 
|> class TWO is
|> 	b:ONE;
|> end;
|> 

To do this ONE and TWO must have an implicit level of indirection.
If you use expanded types if Eiffel, which corespond to normal
types in Ada, you can't do this.

In Ada you can write:

type TWO_Implementation;

type TWO is access TWO_Implementation;

type ONE_Implementation is
   record
      a : TWO;
   end record;

type ONE is access ONE_Implementation;

type TWO_Implementation is
   record
      b : ONE;
   end record;

Which is more or less the same thing as your Eiffel example. The
problem is not declaring it, it is distributing it over multiple
packages. In Ada the assumption that a type will be handled through
a pointer is not valid.

- Robb Nebbe

Re: Is Ada the future? [was: Is C++ the future?]

[Bob Duff]

In article <1994Oct14.103430@di.epfl.ch>,
>mbk@inls1.ucsd.edu (Matt Kennel) writes:

>|> The core issue:  doing this should be possible.  (Indeed it
>|> was hard for me to imagine that it should ever have been
>|> not possible).
>|> 
>|> -- Obvious Eiffel construction.
>|> class ONE is
>|>  	a:TWO;
>|> end;
>|> 
>|> class TWO is
>|> 	b:ONE;
>|> end;

I think at least part of the reason Ada makes this a bit harder than
some other languages is that in Ada, declarations contain a lot of
executable code.  For example:

    X: Integer range 1..Function_Call(...) := Other_Function_Call(...);

Since declarations have a lot of run time semantics, there needs to be a
well-defined order in which the declarations get executed ("elaborated"
in Ada jargon).  Given this implied run-time ordering, forward
references are a Bad Thing.  Hence the need for incomplete type
declarations, and the restriction that they don't work across multiple
library units.

Note that for multiple library units, the order is implied by the
with_clauses, and is really only a partial order.

Languages that freely allow forward references usually do not have any
way to initialize variables at their declaration point, or else they
restrict the expressions to very simple forms that can be known at
compile time, so the issue of run-time execution doesn't come up.

Certainly initializing a variable with a function call can be useful.
Would it be worth it to sacrifice that in order to achieve a slightly
simpler method for doing mutual recursion across multiple library units?
I don't know.  It's a trade-off.

Note also that the designers believed that the linear elaboration model
also makes the code more readable -- at least in theory, it allows you
to read your program in order, and you won't run across references to
things you've never heard of.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Is Ada the future? [was: Is C++ the future?]

[Val Kartchner]

In article <1994Oct4.090807@di.epfl.ch>,
Robb Nebbe <Robb.Nebbe@di.epfl.ch> wrote:
|In my opinion there are two important factors that make software
|maintainable. The ability to define an abstraction and have the
|compiler enforce this abstraction and the ability for the person
|doing the maintenance to understand the abstraction.
|
|For defining and particularly enforcing an abstraction you could
|make a fairly strong case that Ada is better than C++. The case
|wouldn't be that you can't define and enforce an abstraction in
|C++, which would be a bit naive, but that in some cases the effort
|required goes far beyond what is required in Ada.

Ada 83 is *very* strict about enforcing the abstraction.  (i.e.:
private data types are *only* accesible through the defined interface.)
As a programmer who uses Ada 83 at work daily, this is both a blessing
and a curse.  But since I wrote the package, I can just add a necessary
function to the interface.  ;-)

I have also been reading about Ada 9X.  In the booklet "Introducing Ada
9X", Section 2.7, "Hierarchical Libraries", pp 20-23 and Section 2.8,
"Private Child Units", pp. 24-26 have text and code examples which
demonstrate these secion summaries (in the report's own words):

   The important special visibility rule is that the private part (if any)
   and the body of the child have visibility of the private part of their
   parent.

   The private part and body of any child can access the private part of
   its parent (and grandparent...).

Unless there is some subtlty that I've missed in the pages of *both* text
and code, all that one has to do to get access to the private datatypes
is to declare a child package.  (Note: this doesn't include renaming of
private interfaces, but does allow the foreign child to call private
interfaces and thereby effectively rename a private interface.)

Would an Ada programmer /ever/ knowingly defeat the intent of the package
interface and do this?  No, I don't think so.  Do you?  :-S

-- 
|================= #include <stddisclaimer.h> ================/// KB7VBF/P11 =|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State  |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\///   University  |
|=== "I think, therefore I AMiga" -- val@cs.weber.edu ====\///= Ogden UT USA =|

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

It is true that you can "defeat" the private abstraction by making an
"unauthorized" child package, but then you can also do this by simply
editing the spec or body of the package in the first place. A child is
an extension of a package. Generally speaking one would expect from a
configuration management point of view that writing children would be
strictly controlled, on a level comparable with the control used over
the package providing the abstraction in the first place.

Basically you can extend a package either by adding declarations to it,
or by adding a child package. The latter may be more convenient from a
modularity point of view, but from a configuration management point
of view the two methods of extension should be treated as both requiring
appropriate and comparable control.

Re: Is Ada the future? [was: Is C++ the future?]

[Robb Nebbe]

val@cs.weber.edu (Val Kartchner) writes:

|> I have also been reading about Ada 9X.  In the booklet "Introducing Ada
|> 9X", Section 2.7, "Hierarchical Libraries", pp 20-23 and Section 2.8,
|> "Private Child Units", pp. 24-26 have text and code examples which
|> demonstrate these secion summaries (in the report's own words):
|> 
|>    The important special visibility rule is that the private part (if any)
|>    and the body of the child have visibility of the private part of their
|>    parent.
|> 
|>    The private part and body of any child can access the private part of
|>    its parent (and grandparent...).
|> 
|> Unless there is some subtlty that I've missed in the pages of *both* text
|> and code, all that one has to do to get access to the private datatypes
|> is to declare a child package.  (Note: this doesn't include renaming of
|> private interfaces, but does allow the foreign child to call private
|> interfaces and thereby effectively rename a private interface.)
|> 
|> Would an Ada programmer /ever/ knowingly defeat the intent of the package
|> interface and do this?  No, I don't think so.  Do you?  :-S

One way to think of child packages is that they are equivalent (not
exactly but close) to nested packages except you get the benefit of
separate compilation. I believe the intent is that a module may be
extended without disturbing the parent or to provide special interfaces
for certain clients.

As long as you express what you are doing clearly in the code a
language really shouldn't get in your way. (Ada83 is guilty of this)
This is quite different than the language doing things implicitly
that you didn't ask it to do. The is no way to accidently gain
visibility of the private part of a package and as you said you
cannot accidently make any private declarations visible in the
public part of the child.

- Robb Nebbe

Child packages [nn,pedo,incest,cons]

[Robert Firth]

In article <1994Oct14.094121@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

>|>    The private part and body of any child can access the private part of
>|>    its parent (and grandparent...).

In principle, any mechanism that allows one to extend an abstraction
also allows one to break it.  That's a hard choice for the language
designer to make.

However, let's remember that there are tools other than compilers,
and you don't have to rely on the compiler to enforce *all* your
good programming habits.  It is still possible for an organsation
that prefers the Ada 83 style to prohibit the creation of child
packages, and this could be enforced by the development system,
just as specific local standards concerning Use clauses or Unchecked
Programming can be enforced.

Re: Child packages [nn,pedo,incest,cons]

[Robert I. Eachus]

     A couple of years ago the issue of permitting or forbidding
illegitimate children was strongly debated (at the Portsmouth
meeting). It was a close call, and I think the sentiment was in favor
of forbidding.

     However, there were several other needed changes in the
visibility model involving child units (involving who could see whose
private parts).  Tucker's (elegent) solutions to those forced the
morality (and legality) of illegitimate children to become an
environmental issue, while mitigating the harm that they can do.

     As an early opponent of illegitimate children, I support the
current position.  Yes, you can shoot yourself in the foot by creating
an illegitimate child, but it is hard to shoot others feet as well.


--

					Robert I. Eachus

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

Re: Child packages [nn,pedo,incest,cons]

[Robb Nebbe]

In article <EACHUS.94Oct14171302@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:

|> 
|>      As an early opponent of illegitimate children, I support the
|> current position.  Yes, you can shoot yourself in the foot by creating
|> an illegitimate child, but it is hard to shoot others feet as well.
|> 

But you have to want to shoot yourself in the foot. I would think it
would be almost impossible to "accidently" declare a child package
and muck around with private information.

- Robb Nebbe

Re: Child packages [nn,pedo,incest,cons]

[Robert I. Eachus]

In article <1994Oct17.091621@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > But you have to want to shoot yourself in the foot. I would think it
 > would be almost impossible to "accidently" declare a child package
 > and muck around with private information.

   Never underestimate stupidity, you can't overestimate it.

   "Against stupidity, the Gods themselves contend in vain." Schiller(sp?)

   You have to know why it is a bad thing. There are no warning signs
posted.  And I don't expect people to spend lots of effort adding
comments to package specifications explaining what catastrophes can be
created by illegitimate children.

   Also, it is possible to write packages so that illegitimate
children are inherently safe.  It takes a little more effort, but
since it is possible many coding practices will favor it.

   But look what happens when someone whose entire experience was in
such an envirionment moves to a company with different practices.

   Maybe what we need are a few "stickers."  One line comments to be
put as the first thing in a private part and explain the relative risk
of illegitimate children:

   "This package is designed to freely allow child units to be added."

   "Any child unit which updates state in this private part must
observe the locking protocol."

   "This subsystem was not designed to allow addition of child units.
User defined child units may be broken by new implementations of the
subsystem."

   "This package will break in the presence of unanticipated child units."

    I guess I'll have to start doing that for Ada 9X code.  They
certainly belong in any published code (including in RM9X) but there
is a lot of Ada 83 code around without the stickers on it.

    (I'll turn this into an "official" 9X comment.  The private parts
of all the language defined packages say:

    private
      ... -- not specified by the language
    end...

    At a minimum, either paragraphs 1.1.3(18-19) should specify that
not specified is the same as unspecified, or all those comments shoul
change.  But I think the best idea would be to also explicitly define
for which language defined packages, if any, user defined children
should not take advantage of visibility into the private part.  (As I
indicated, and I hope as implementors will do it, it should be
possible to allow (implementation dependant) user defined child units
for most language defined packages without risk.)

--

					Robert I. Eachus

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

Re: Child packages [nn,pedo,incest,cons]

[Bob Duff]

In article <EACHUS.94Oct17115240@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>   Never underestimate stupidity, you can't overestimate it.

Language rules can't possbily protect against stupidity (or gross
negligence) in any case.  So why bother trying?  The language rules
should make Doing Good easier than Doing Evil.  But the language
designer can't possibly prevent the latter, nor even know for sure
what's Evil in a given situation.

>   Maybe what we need are a few "stickers."  One line comments to be
>put as the first thing in a private part and explain the relative risk
>of illegitimate children:
>
>   "This package is designed to freely allow child units to be added."
>
>   "Any child unit which updates state in this private part must
>observe the locking protocol."
>
>   "This subsystem was not designed to allow addition of child units.
>User defined child units may be broken by new implementations of the
>subsystem."
>
>   "This package will break in the presence of unanticipated child units."

This sort of comment might be useful, but how does it differ from
comments addressed to maintainers who need to change the package itself?
"-- If you change this code, be sure to obey the locking strategy."
Etc.  Think of adding a child as similar to changing the parent package
itself -- you're adding functionality to the abstraction, and you need
to know what you're doing lest you break something.

>    (I'll turn this into an "official" 9X comment.  The private parts
>of all the language defined packages say:
>
>    private
>      ... -- not specified by the language
>    end...
>
>    At a minimum, either paragraphs 1.1.3(18-19) should specify that
>not specified is the same as unspecified, or all those comments shoul
>change.

Sorry Robert, but I'm not going to say in the RM that "not" = "un".
It's not our job to teach people the rules of the English language.

> ...But I think the best idea would be to also explicitly define
>for which language defined packages, if any, user defined children
>should not take advantage of visibility into the private part.  (As I
>indicated, and I hope as implementors will do it, it should be
>possible to allow (implementation dependant) user defined child units
>for most language defined packages without risk.)

Whether or not an implementation allows the user to extend language
defined packages is defined by the implementation.  And, since the
private parts of those packages are not specified, the meaning of such
children is not necessarily portable.  Seems pretty obvious -- I don't
see any need for additional verbiage in the RM.  There's enough verbiage
there as it is.  :-(

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Child packages

[Robb Nebbe]

In article <EACHUS.94Oct17115240@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
|> In article <1994Oct17.091621@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
|> 
|>  > But you have to want to shoot yourself in the foot. I would think it
|>  > would be almost impossible to "accidently" declare a child package
|>  > and muck around with private information.
|> 
|>    Never underestimate stupidity, you can't overestimate it.
|> 
|>    "Against stupidity, the Gods themselves contend in vain." Schiller(sp?)
|> 
|>    You have to know why it is a bad thing. There are no warning signs
|> posted.  And I don't expect people to spend lots of effort adding
|> comments to package specifications explaining what catastrophes can be
|> created by illegitimate children.
|> 

It is sort of like a rail at the edge of a cliff to keep people
from falling off. Something simple is sufficient but if you want
to worry about all the really stupid people then maybe you should
put up a 12 foot high barier in plexiglass or something. I think
that would really enhance places like the Grand Canyon. :-)

I find that child packages make my code safer. They frequently 
replace things like unchecked conversion where I know that it
will always work but I couldn't get Ada83 to check it without
giving up information hiding. I feel a little safer knowing that
the compiler can check everything and that some accidental error
didn't slip in when I had to use unchecked conversion.

As far as illegitemate child packages I find that there are plenty
of warning signs along the way. To write a child package you have to
preference the package name with the name of the parent(s). When
you with the package you have to give the full name including the
parent(s).

I don't buy the arguement that a stupid programmer might declare a
child package by accident. That a programmer might do something
wrong on purpose seems more like paranoia than anything worth
getting concerned about.

A version control system seems like a much better place to worry
about who can do what to which packages.

- Robb Nebbe

Re: Child packages

[Robert I. Eachus]

In article <1994Oct18.103131@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > It is sort of like a rail at the edge of a cliff to keep people
 > from falling off. Something simple is sufficient but if you want
 > to worry about all the really stupid people then maybe you should
 > put up a 12 foot high barier in plexiglass or something. I think
 > that would really enhance places like the Grand Canyon. :-)

   I don't think we disagree.  I think a simple railing is sufficient,
although a low stone wall may be more aesthetically pleasing.  As I
said, originally I was opposed to illegitimate children, but in the
current design, they are a net win.

   But I do think that the packages that are like scenic lookouts on
cliff edges do need the railings.  For example, if a creation function
does more than just create objects, then a note in the private part to
that effect may avoid a few missteps.  A horrible but perfectly
natural example would be a package with a private type which is a
pointer to a record type declared in the private part.  In the
implementation the create operation would do the needed locking, and
the initial value operations on the hidden type count on the locking
having been done.  A one line comment in the hidden object type can
save a lot of grief.  (The alternative is to put the hidden type in
the pacakge body.  That is why such a package is the programming
equivalent of an attractive nuisance.)




--

					Robert I. Eachus

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

Re: Child packages

[Robert Dewar]

One thing that should be emphasized about child packages (since some of
the posts of this thread have not been clear on this point) is that
child packages in no way change their parents. If you have a parent A,
and a child A.B, then if A.B does horrible things to the abstractions
in A, it still does not affect anyone who with's only package A. It is
only if package A.B is with'ed that the effects of the child are
noticable.

Re: Child packages

[Robert I. Eachus]

In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

 > One thing that should be emphasized about child packages (since some of
 > the posts of this thread have not been clear on this point) is that
 > child packages in no way change their parents. If you have a parent A,
 > and a child A.B, then if A.B does horrible things to the abstractions
 > in A, it still does not affect anyone who with's only package A. It is
 > only if package A.B is with'ed that the effects of the child are
 > noticable.

     Very misleading.  If a PROGRAM doesn't include any withs of a
child, the child is not part of that program and can't harm it.  But a
child unit can--even during elaboration--change hidden state in the
parent's private part.  So a child added by one portion of a large
project can harm other users of the parent package and it can be very
hard to track down.  This risk on large projects should not be
understated.  (And, yes, project management tools can control or
eliminate the problem, but these tools do not yet exist for Ada 9X.
At least tools which address this particular issue.)

     Note that on many projects the interfaces between subsystems are
specified as packages with only type and subprogram declarations in
the public part.  If 9X were only used for new projects, the simple
solution would be to outlaw state in the private part as well.  As it
is, the solution is to strongly restrict children of such packages.

     As I said, child units like fire are a net win.  But we still
need to learn how to handle them safely.  They can easily be abused.

--

					Robert I. Eachus

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

Re: Child packages

[Norman H. Cohen]

In article <EACHUS.94Oct19110308@spectre.mitre.org>, eachus@spectre.mitre.org
(Robert I. Eachus) writes: 

|>                   If 9X were only used for new projects, the simple
|> solution would be to outlaw state in the private part as well.  As it
|> is, the solution is to strongly restrict children of such packages.

No, as the other article I just posted illustrated, a child can be used
to violate the representation variants maintained for ADTs even by
stateless packages.  The only solution is to treat the writing of a child
for a package as tantamount to modifying the text the parent, and to
impose the same access controls.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Child packages

[Robert Dewar]

Norman, there is still a big difference between modifying the text of a 
package and adding a child, much to big for tantamout :-)

The big difference is that if you modify the text of a package you can
blow up existing clients of that package in different programs.

If you write a child, it is completely separate, and affects on programs
that use the child,

so the level of access controls needed is quite different. a given program
may want to lock out any additional child units, and another program may
wish to allow them, but neither could permit the mucking with a shared
package's text.

Re: Child packages

[Norman H. Cohen]

In article <38496c$1l1@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> Norman, there is still a big difference between modifying the text of a
|> package and adding a child, much to big for tantamout :-)
|>
|> The big difference is that if you modify the text of a package you can
|> blow up existing clients of that package in different programs.
|>
|> If you write a child, it is completely separate, and affects on programs
|> that use the child,
|>
|> so the level of access controls needed is quite different. a given program
|> may want to lock out any additional child units, and another program may
|> wish to allow them, but neither could permit the mucking with a shared
|> package's text.

This is true.  I should have said that adding a child is tantamount to
modifying a program's OWN COPY of a package.  (The point is that
encapsulation in a package provides no more protection against breaking
an abstraction by writing a child than it does against breaking an
abstraction by modifying the text of the package.  Access controls CAN
provide such protection, and I agree that child packages facilitate
access controls with a finer granularity.)

Even the comparison of a shared package with a program-specific child to
a program-specific copy of the package is not quite right, of course,
because a change to the shared copy is immediately reflected in each
program-specific copy.

Some changes to a shared parent may invalidate assumptions on which
children depended, thus breaking program-specific virtual copies of the
package.  However, others may not.  For example, if a bug is found in the
body of a subprogram provided by the parent, causing the subprogram to
violate its specifications in obscure cases, a fix to the parent package
immediately fixes the bug in all programs that use the package or its
children.  (If a program exploited the bug as a "feature", the bug fix
will break that program, but given my hypothesis that the bug violated
the subprogram's specifications, the fault in that case lies with the
program.)

The issue of maintaining a parent package shared by multiple programs
brings out a serious drawback of child units.

One of the breakthroughs provided by Ada 83 was the separation of a
module into distinct textual regions defining a module's interface (the
package visible part) and its implementation (the private part and body).
In languages not providing this clear textual distinction, it is common
to speak of "documented features" and "undocumented features" rather than
properties of the interface and properties of the implementation.  In Ada
83, the maintainer of a package always had complete freedom to change the
details of the implementation.  (Caveat unchecked-convertor.)

In Ada 94 there is a third category of features.  Between the interface
that may be exploited by clients and the implementation details that the
parent-package maintainer reserves the right to change, there is a set of
IMPLEMENTATION features that the package maintainer agrees to leave
unchanged, in the expectation that child units may exploit these
features.  (This distinction is analogous to the C++
public/protected/private trichotomy.)  Unfortunately, the distinction
between "private" implementation details (which even children should not
exploit) and "protected" implementation details (hidden from ordinary
clients but part of the interface as far as child units are concerned) is
not reflected in any way in the text of a parent package, except of
course in comments.  Thus we are back to distinguishing between
"documented features" of a package implementation and "undocumented
features".  (We would like to hope that the so-called "undocumented
features" are actually clearly DOCUMENTED, in comments, as not to be
relied on by child units!)

While child packages provide many more advantages than disadvantages, I
feel we have lost something important from Ada 83--a clearly marked,
compiler-recognized distinction between those aspects of a module that do
and do not form a part of its "contract".

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Child packages

[Robert I. Eachus]

In article <385thq$kh6@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > While child packages provide many more advantages than
  > disadvantages, I feel we have lost something important from Ada
  > 83--a clearly marked, compiler-recognized distinction between
  > those aspects of a module that do and do not form a part of its
  > "contract".

   Exactly!  And there may be no better way to "fix" this problem than
the current language specification.  The problem is not that you can't
write Ada 9X code so that the private part is exactly the contract
with the child units, but that there is a lot of Ada 83 code that is
not written this way.  (Note that one method of making it explicit is
to move some declarations from the private part to a private child.)

    With education and tool support, the problem should disappear
relatively quickly as old code is updated to new standards.  I'm sorry
if Robert Dewar doesn't think that comp.lang.ada is the right place to
discuss those issues.  Back to the previous idiom, I am not objecting
to all the new senic lookouts.  I am just trying to make sure that the
fences there look pleasing, don't interfere with the view, and do
provide the needed safety.

--

					Robert I. Eachus

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

Re: Child packages

[Benjamin Ketcham]

In article <EACHUS.94Oct20110915@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
[...]
>    With education and tool support, the problem should disappear
>relatively quickly as old code is updated to new standards.
[...]

Wait, I thought the benefit of Ada (even Ada 83, which is, after
all, still the only validated standard, isn't it?) was that you
didn't *need* to "update old code to new standards" because the
standard was so safe and readable and mission-critical and a
whole bunch of other things that supposedly justify paying ten
times as much up front, because it will last ten times as long
and maintenance costs will be lower and so you'll save money in
the long run and....

So which is it?  Will the "problem" "disappear relatively quickly"
because all that "legacy" Ada code that was supposed to last 1000
years now needs to be changed to the Even Better, Enhanced, Last
Language You'll Ever Need (And This Time, We Mean It) standard?
Or will the "problem" be hanging around for *decades* because all
that yucky Old-Style Ada 83 just keeps going, and going, and....

<picture your favourite emoticon here>

--ben

Re: Child packages

[Robert I. Eachus]

In article <386eru$8m7@nntp1.u.washington.edu> bketcham@u.washington.edu (Benjamin Ketcham) writes:

 > Wait, I thought the benefit of Ada (even Ada 83, which is, after
 > all, still the only validated standard, isn't it?) was that you
 > didn't *need* to "update old code to new standards" because the
 > standard was so safe and readable and mission-critical and a
 > whole bunch of other things that supposedly justify paying ten
 > times as much up front, because it will last ten times as long
 > and maintenance costs will be lower and so you'll save money in
 > the long run and....

 > So which is it?  Will the "problem" "disappear relatively quickly"
 > because all that "legacy" Ada code that was supposed to last 1000
 > years now needs to be changed to the Even Better, Enhanced, Last
 > Language You'll Ever Need (And This Time, We Mean It) standard?
 > Or will the "problem" be hanging around for *decades* because all
 > that yucky Old-Style Ada 83 just keeps going, and going, and....

   The particular situation I was discussing involved legacy code,
which didn't need to be changed to compile to meet the new standards.
The code was then extended using Ada 9X features.  The "problem" I was
addressing was not the in the old code, or the new code, but educating
programmers about the new features.  If someone wants to use Ada 83
techniques forever, God Bless.  But if a program or a programmer wants
to start using the new features, it is up to us to let them know where
the potential pitfalls are so they never have to fall in.

 > <picture your favourite emoticon here>

   Okay ;-)

--

					Robert I. Eachus

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

Re: Child packages

[Bob Duff]

In article <385thq$kh6@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>While child packages provide many more advantages than disadvantages, I
>feel we have lost something important from Ada 83--a clearly marked,
>compiler-recognized distinction between those aspects of a module that do
>and do not form a part of its "contract".

This is an interesting point.  Note, however, that the contents of a
package body, and the contents of a *private* child package, are hidden
from clients and from new (public) children.

By the way, this whole discussion has been about what happens when
somebody extends an existing system by adding children.  Don't forget
that a hierarchy of children is a good way to organize a subsystem being
written by one person or team -- we don't need to imagine a separate
organization extending the subsystem in order to find a use for child
units.  A lot of cases that in Ada 83 would be done as a single package
will tend to be split into a hierarchy in Ada 9X.

Note also that the distinction between public and private has never been
perfect in Ada.  If you see (in the visible part of a package):

    Message: constant String := "File not found.";

You can't be sure exactly what information is being exported.  
Is the package promising that this string will always be 15 characters
long, and/or contain exactly those characters?  Or is it merely
promising that the thing is called Message, and it's of type String.
If somebody wants to change the message to be more informative, will
that break existing clients?  We don't know for sure.

Now, you may say that one ought to have made it a function, so changing
the message would only require a change to the body.  Well, perhaps, but
that interface promises less to the client in one respect -- the client
can be sure that a reference to Message above will not have side
effects, and will always produce the same value.  Using a function
doesn't make any such promise.  Furthermore, it's more verbose (by a
factor of 5, if you're counting lines of code), so a lot of people will
choose the constant-declaration way.

-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Child packages

[Bob Duff]

In article <CxzCu0.D8I@inmet.camb.inmet.com>,
I wrote:
>This is an interesting point.  Note, however, that the contents of a
>package body, and the contents of a *private* child package, are hidden
>from clients and from new (public) children.

That's not quite right, of course.  Private children are not hidden from
the *bodies* of their public siblings.
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Child packages

[Mark Biggar, 5172]

In article D8I@inmet.camb.inmet.com, bobduff@dsd.camb.inmet.com (Bob Duff) writes:
> Note also that the distinction between public and private has never been
> perfect in Ada.  If you see (in the visible part of a package):
> 
>     Message: constant String := "File not found.";
> 
> You can't be sure exactly what information is being exported.  
> Is the package promising that this string will always be 15 characters
> long, and/or contain exactly those characters?  Or is it merely
> promising that the thing is called Message, and it's of type String.
> If somebody wants to change the message to be more informative, will
> that break existing clients?  We don't know for sure.
> 
> Now, you may say that one ought to have made it a function, so changing
> the message would only require a change to the body.  Well, perhaps, but
> that interface promises less to the client in one respect -- the client
> can be sure that a reference to Message above will not have side
> effects, and will always produce the same value.  Using a function
> doesn't make any such promise.  Furthermore, it's more verbose (by a
> factor of 5, if you're counting lines of code), so a lot of people will
> choose the constant-declaration way.

I'd say that if you put the above declaration in the visible part of
your package spec then you are pretty well promising that the string
won't change in the future and that users can depend on it always being
15 characters long and containing exactly those characters.

But if you had instead written (in Ada9x, but unfortunataly not in Ada83):

...
	Message: constant String:
    private
        Message: constant String := "File Not Found.";
...

Then all you are promising is that it is a constant string and you
should fell free to change it anytime you want and if a user writes
code that, for example, depends on the string being 15 characters long,
then you can reasonably claim that they are cheating and making use of
a property that you didn't want exported.

Actually, if I was attending a walkthough of a users code and they had
used anything other then Message'Length in either case I would red flag
it.

I know that the above are just personal conventions, but isn't this one
of the major reasons why 9x allows deferred constants of any type not
just private types, and besides users of a package arn't suppose to
peek into private parts anyway, are they?

--
Mark Biggar
mab@wdl.loral.com

Re: Child packages

[Robb Nebbe]

In article <385thq$kh6@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) 
|> 
|> While child packages provide many more advantages than disadvantages, I
|> feel we have lost something important from Ada 83--a clearly marked,
|> compiler-recognized distinction between those aspects of a module that do
|> and do not form a part of its "contract".
|> 
|> --
|> Norman H. Cohen    ncohen@watson.ibm.com

I have found it very helpful to think of child packages as extensions of
the parent package and not as clients of the parent package.

If you have a package that needs access to some "private information" then
you should extend the package with a child package that specifies the
interface to this information. Then make your package a client of the
child package.

- Robb Nebbe

Re: Child packages

[Robert Dewar]

I think it is Robert Eachus who is being misleading and alarmist here. First
of all, it is perfectly possible to write packages now which break the
private type interface, by using unchecked conversion, and do all sorts
of horrible things.

Why is this not a disaster? Because you know from the package (with
unchecked conversion) that is is potentially a problem, and you know
that you DON'T have anything to worry about if the package is not
included in a program.

Exactly the same holds true for child packages. I really think all this
worrying about them is bogus. In fact you are much better off with a
child package than you are if someone simply mucks directly with the
source of a supposedly secure package. OK, you say, we have these wonderful
configuration managers that prevent that sort of thing -- fine have these
wonderful cm's also restrict what people can do with child packages.

The bottom line is that child packages add no fundamental functionality.
There is nothing that you can do with them that you cannot do without them,
including busting abstractions. What they allow is much more convenient
package of a program into components, and indeed some of these components
may be mucking with abstractions, possibly in a naughty way, but you are
still ahead.

Consider the following two possibilities:

   someone has mucked with the source of a critical package and broken the
   abstraction. All programs that with this package are bust.

   someone has added a child package to a critical package, and broken the
   abstraction. Only programs that with the child package are bust.

It seems clear that situation two is a huge improvement over the "ada 83"
way of breaking abstractions represented by situation one. 

Of course you can still illegally muck with packages you shouldn't touch
in Ada 9X, but given the possibility of child packages, it is now practical
to really "lock the door" and forbid any mucking with critical packages and
to forbid the use of unchecked conversions.

This kind of draconian action could be done in Ada 83, but then there is
no way out for an isolated special program to get its hands on the private
data. Ada 9X allows such a method, if you care to permit it.

Re: Child packages

[Matt Kennel]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

:  > One thing that should be emphasized about child packages (since some of
:  > the posts of this thread have not been clear on this point) is that
:  > child packages in no way change their parents. If you have a parent A,
:  > and a child A.B, then if A.B does horrible things to the abstractions
:  > in A, it still does not affect anyone who with's only package A. It is
:  > only if package A.B is with'ed that the effects of the child are
:  > noticable.

:      Very misleading.  If a PROGRAM doesn't include any withs of a
: child, the child is not part of that program and can't harm it.  But a
: child unit can--even during elaboration--change hidden state in the
: parent's private part. 

Question:  do you mean objects declared to be type of the parent
may be harmed due to the fact that there are subclasses of
this parent?  This sounds dumb.  This isn't true, is it?

Of course, if you create a child class which takes some implementation
from a parent sure you might screw up the implementation taken from
the parent, but this should only affect you if you use
objects of the child class, right?

: 					Robert I. Eachus

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: Child packages

[Magnus Kempe]

mbk@inls1.ucsd.edu (Matt Kennel) writes:
:
: : But a child unit can--even during elaboration--change hidden state
: : in the parent's private part.
: 
: Question:  do you mean objects declared to be type of the parent
: may be harmed due to the fact that there are subclasses of
: this parent?

No, that is NOT what was meant.

A child _unit_ is not the same thing as a derived type (a.k.a subclass,
derived class, child class, etc.).

Ada offers hierarchies of types/classes _and_ hierarchies of
packages/modules.  These hierarchies are distinct; they need not
coincide.

Since fans of Eiffel make no distinction between type/class and
package/module, this must be difficult to understand.  Maybe they
should read the Rationale of Ada 9X, available from URL
ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x (v5.0 is the latest).

-- 
Magnus Kempe		"I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry

Re: Child packages

[John Volan]

mbk@inls1.ucsd.edu (Matt Kennel) writes:

>Robert I. Eachus (eachus@spectre.mitre.org) wrote:
>: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

>:  > One thing that should be emphasized about child packages (since some of
>:  > the posts of this thread have not been clear on this point) is that
>:  > child packages in no way change their parents. If you have a parent A,
>:  > and a child A.B, then if A.B does horrible things to the abstractions
>:  > in A, it still does not affect anyone who with's only package A. It is
>:  > only if package A.B is with'ed that the effects of the child are
>:  > noticable.

>:      Very misleading.  If a PROGRAM doesn't include any withs of a
>: child, the child is not part of that program and can't harm it.  But a
>: child unit can--even during elaboration--change hidden state in the
>: parent's private part. 

>Question:  do you mean objects declared to be type of the parent
>may be harmed due to the fact that there are subclasses of
>this parent?  This sounds dumb.  This isn't true, is it?

>Of course, if you create a child class which takes some implementation
>from a parent sure you might screw up the implementation taken from
>the parent, but this should only affect you if you use
>objects of the child class, right?

Matt, you are confusing child units and package hierarchies with
inheritance and class hierarchies.  They are not the same thing.
Child units and package hierarchies are a pure "modularity" concept,
one that that is new to Ada9X.  The hierarchical library mechanism
deals with issues of scope, visibility, encapsulation, information
hiding, and separate compilation.  On the other hand, class
hierarchies and inheritance, well-known in so many object-oriented
languages, are treated as a "typing" concept in Ada9X, and are
implemented in terms of tagged types, type derivation, and type
extension.

Your background as an Eiffel programmer is showing.  Eiffel is a
language designed to adhere to the principle of 1 MODULE = 1 TYPE.
This principle is the "One and Only True Way" of today's
object-oriented orthodoxy.  But the design of Ada (83 and 9X) makes no
attempt to rigidly follow that orthodoxy.  Mind you, it doesn't
*preclude* the idea of 1 MODULE = 1 TYPE.  Indeed, as I've been trying
to show on another thread, it's possible to adhere to a style of 1
PACKAGE = 1 CLASS even under the most strenuous conditions without
resorting to grotesque workarounds.  However, Ada9X doesn't *require*
you to follow this style as the "One and Only True Way".  In fact,
Ada9X's hierarchical library allows programmers to deal with
modularity issues at levels of granularity *beyond* the class-level
(e.g., "subsystems") -- *without* having to look beyond the
programming language for support. At the same time, it supports
levels of granulatiry *smaller* than the class-level (different
aspects of a class's functionality might be dealt with in different
child units -- well, as long as that functionality doesn't have to
be "primitive").

If you haven't already done so, it might help you to download and read
the Ada 9X Rationale, which is available by anonymous FTP from the
AJPO host, in

	ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x

>--
>-Matt Kennel  		mbk@inls1.ucsd.edu
>-Institute for Nonlinear Science, University of California, San Diego
>-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
>-***     lyapunov.ucsd.edu, username "anonymous".

-- John Volan

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------

Re: Child packages

[Norman H. Cohen]

In article <3816h5$n3g@schonberg.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> One thing that should be emphasized about child packages (since some of
|> the posts of this thread have not been clear on this point) is that
|> child packages in no way change their parents. If you have a parent A,
|> and a child A.B, then if A.B does horrible things to the abstractions
|> in A, it still does not affect anyone who with's only package A. It is
|> only if package A.B is with'ed that the effects of the child are
|> noticable.

On the other hand, a part of a large program that with's A.B can do harm
that will affect parts of the program that with only A.  For example: 

   package Fractions is
      type Fraction_Type is private;
      ...
   private
      type Fraction_Type is
         record
            Numerator   : Integer;
            Denominator : Positive;
         end record;
      -- Representation invariant: 
      --    for X in Fraction_Type, X.Numerator and X.Denominator must
      --    be relatively prime.
      -- All the operations exported by this package that construct
      --    Fraction_Type values preserve this invariant, and the
      --    implementation of "=" depends on it.
   end Fractions;

   function Fractions.Invalid_Fraction
      (Numerator, Denominator: in Integer) return Fraction_Type is
   begin
      return (2*Numerator, 2*Denominator);
   end Fractions.Invalid_Fraction;

A part of the program with'ing Fractions.Invalid_Fraction could place the
value returned by that function in some global data structure.  Another
part of the program that with's only Fractions could fail upon trying to
apply the operations of package Fractions to that value.

(In practice, of course, a "problem child" would be more subtle than this
one, and would presumably do its harm unintentionally.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

My goodness, it sure is suprising for someone to ask what the difference
between correctness and reliability is.

They are only vaguely related, there are reliable incorrect programs,
and unrealiable correct programs.

Re: Is Ada the future? [was: Is C++ the future?]

[Richard Kenner]

In article <36rpp7$kjk@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>My goodness, it sure is suprising for someone to ask what the difference
>between correctness and reliability is.

Offhand, I'd say it's roughly the same as the difference between
accuracy and precision.  :-)

Re: Is Ada the future? [was: Is C++ the future?]

[Benjamin Ketcham]

In article <36h4pc$9dd@starbase.neosoft.com>,
David Weller <dweller@Starbase.NeoSoft.COM> wrote:

>Agreed.  But this is a change that requires time.  C++ has gained a
>lot of momentum, but there's room for other languages (Eiffel,
>Smalltalk, and Ada).  Nobody has to come out "on top".  The real
>winner will be the language that is the most interoperable.  Guess
>which on stands the best chance? :-)

Hmmm, could it be the one with the fastest, most transparent,
and most universally *available* bindings to essentially every
OS worth using (and several which are not!), by the simple and
arguably unfair advantage of being the language said OSes were
written in?

--ben
(Want to really make Ada use take off?  Port Linux or *BSD* to Ada.)

Re: Is Ada the future? [was: Is C++ the future?]

[Robin Rowe]

<< In the meantime, I have a responsibility to write reliable software.  
Ada 9X does that for me in ways that C++ folks are now only dreaming 
about. >>

What Ada 9X dreams am I supposed to be having? How about a 
list of ways that Ada 9X can make more reliable software 
than C++?

Thanks.

Robin
                  
 


-- 
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA 
Rowe Technology            C++ training, consulting, and users groups.

Re: Is Ada the future? [was: Is C++ the future?]

[David Weller]

In article <cppCx20IA.Anx@netcom.com>, Robin Rowe <cpp@netcom.com> wrote:
><< In the meantime, I have a responsibility to write reliable software.  
>Ada 9X does that for me in ways that C++ folks are now only dreaming 
>about. >>
>
>What Ada 9X dreams am I supposed to be having? How about a 
>list of ways that Ada 9X can make more reliable software 
>than C++?
>

Is this a serious question?

	Range checking, Type checking within generics, standardized
	concurrency, safe pointers, etc.

Looking at your .sig, I can't tell if the question is serious or if
you're trolling.  Let's try it this way, here's a couple of papers
to read that present a fairly unbiased comparison:

"A Comparison of the OO features of Ada9x and C++" in springer lecture
notes in cs: "Ada Europe93" pp.125-141 (short paper, good reading,
enlightens paradigmae)  

Also, look at the paper 9x-cplus.txt under /public/ada9x/reports/misc
on ajpo.sei.cmu.edu.


Neither paper should be treated as a complete survey.  Further,
neither paper delves into the "corners", ie, support for
distribution, information systems, numerics, real-time programming,
etc.  All of which are standardized in the Annexes.

-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Netspeak: What is "trolling"?

[Norman H. Cohen]

In article <36msgr$qq2@Starbase.NeoSoft.COM>, dweller@Starbase.NeoSoft.COM
(David Weller) writes: 

|> Looking at your .sig, I can't tell if the question is serious or if
|> you're trolling.

David, this term is new to me.  Could you explain its meaning and, if
possible, its origin?

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Netspeak: What is "trolling"?

[Kenneth Aubey 913-4481]

"trolling" usually means posting a controversial or annoying message with 
the specific purpose of attracting flames. Nothing to do with living 
under bridges.   

Wyzyrd
<:)}

--**************************************************************************^[
--"It's so hard to know                          Ken Aubey  (703) 913-4481 
-- If you're bound for a fall,                         (Wyzyrd@netcom.com)
-- But better to have slipped
-- Than never danced at all." -- Albion Band - "Dancing Under the Rose"
--****************--> All Opinions Strictly Mine <--************************

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

dweller@Starbase.NeoSoft.COM (David Weller) writes:

>In article <cppCx20IA.Anx@netcom.com>, Robin Rowe <cpp@netcom.com> wrote:
>><< In the meantime, I have a responsibility to write reliable software.  
>>Ada 9X does that for me in ways that C++ folks are now only dreaming 
>>about. >>
>>
>>What Ada 9X dreams am I supposed to be having? How about a 
>>list of ways that Ada 9X can make more reliable software 
>>than C++?
>>

>Is this a serious question?

If it wasn't I'll second it and make it one.

>	Range checking,
Trivially provided in C++ classes that need it.

>	Type checking within generics,
C++ provides this for every definition of that
phrase that I can think of.  I can only assume
that you mean something else.  Please elaborate.

>	standardized concurrency
Granted.

>	safe pointers
Can be provided, but not legislated.  In any
case, for programs of more than trivial com-
plexity, raw pointers are generally wrapped
in safe classes.  The real problem is refer-
ences to temporaries.

>	etc.
Oh, now *this* one is *definately* provided
by C++.  In spades! ;->  More seriously,
have ya got anything else?

>Let's try it this way, here's a couple of papers
>to read that present a fairly unbiased comparison:

Thank you, I will read them.

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[David Weller]

In article <milodCx47ys.HxB@netcom.com>,
John DiCamillo <milod@netcom.com> wrote:
>dweller@Starbase.NeoSoft.COM (David Weller) writes:
>>In article <cppCx20IA.Anx@netcom.com>, Robin Rowe <cpp@netcom.com> wrote:
>>><< In the meantime, I have a responsibility to write reliable software.  
>>>Ada 9X does that for me in ways that C++ folks are now only dreaming 
>>>about. >>
>>>What Ada 9X dreams am I supposed to be having? How about a 
>>>list of ways that Ada 9X can make more reliable software 
>>>than C++?
>>Is this a serious question?
>
>If it wasn't I'll second it and make it one.
>
>>	Range checking,
>Trivially provided in C++ classes that need it.
>
We must have wildly different opinions of "trivial" then.  The
problem with C++ is that it requires the programmer to write
defensively.  "Caveat hackus", if you will.  Type checking, for
instance, is provided only at the class level.  It's not possible to
create an integer of type Oranges and one of Apples without artificially
mashing them into classes and then going through an array of gyrations 
to overload all operations.  The typedef is merely a synonym, 
not a new type.  This is so fundamental to the difference 
between Ada and C++ that I dare say it's the root
of misunderstanding between the two "camps" (if one feels compelled
to segregate the two -- I write in both languages, so I guess I'm a
pariah :-).  The fundamental issue is this: Ada starts from the side
of reliability and requires the programmer to unravel the safety
where needed.  C++ starts from the side of "flexibility" (lack of
safety, depending on your perspective :-) and forces the programmer
to wrap up their nugget of data (members) with a layer of protection
(classes). 

>>	Type checking within generics,
>C++ provides this for every definition of that
>phrase that I can think of.  I can only assume
>that you mean something else.  Please elaborate.
>
Templates:   Grrrrr.   Write a class template.  Then repeat the
template parameters _everywhere_.  Repeat them in your parameter
lists, repeat them in your member functions, repeat them in your
declarations.  "Ad naseum" is an understatement.  What's that got to
do with reliability?  Not a damn thing, but it makes a BIG difference
in readability.

Again, type checking is loose, both in creation and elaboration of
templates.  I owe you a better explanation on this one, but I'm short
on time right now (should be doing my work on the Booch Component
translation).

>>	safe pointers
>Can be provided, but not legislated.  In any
>case, for programs of more than trivial com-
>plexity, raw pointers are generally wrapped
>in safe classes.  The real problem is refer-
>ences to temporaries.
>
No.  As an Ada person, I see "The Real Problem" as being that C++ is
horribly unsafe.  Wrap a pointer in a class and protect it?  Well, so
much for simplicity....

As for references to temps...well, I'm just happy I'm working with a
language that has a little better definition of "closure" :-)

>>	etc.
>Oh, now *this* one is *definately* provided
>by C++.  In spades! ;->  More seriously,
>have ya got anything else?
>
Yes, but out of time (as mentioned before).  I _do_ owe you a better
explanation (I sure wouldn't be convinced by my reply here alone).
Maybe others can chime in without letting this turn into a language
flamewar (I know, I'm probably asking too much :-)

Before you think I'm a rabid C++ hater -- I sometimes find the
"flexibility" of C++ liberating.  I don't, however, recommend it over
Ada 9X.


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

Let me start by thanking you all for taking the time
to think before you respond to this thread.  I'm
really enjoying it and I'm learning a lot.

My point in carrying this on in public is to help
you (the Ada community) hone your arguments on some-
one in the commercial/C++ community.  'Cause if you
can't come up with some good ones, dual-use is doomed.

dweller@Starbase.NeoSoft.COM (David Weller) writes:
>John DiCamillo <milod@netcom.com> wrote:
>>dweller@Starbase.NeoSoft.COM (David Weller) writes:
>>
>>>	Range checking,
>>Trivially provided in C++ classes that need it.
>>
>We must have wildly different opinions of "trivial" then.

I'm sure we do: you are writing an array
class, and I am using one.

>problem with C++ is that it requires the programmer to write
>defensively.  "Caveat hackus", if you will.  Type checking, for
>instance, is provided only at the class level.  It's not possible to
>create an integer of type Oranges and one of Apples without artificially
>mashing them into classes and then going through an array of gyrations 
>to overload all operations.  The typedef is merely a synonym, 
>not a new type.

I agree with all this, but so what?  That's
what commercial class libraries are for.
Admittedly, the market isn't quite there yet
because of standardization and support issues,
but in general, I can choose to buy one of
several different libraries that will provide
the support I need.

>This is so fundamental to the difference 
>between Ada and C++ that I dare say it's the root
>of misunderstanding between the two "camps" (if one feels compelled
>to segregate the two -- I write in both languages, so I guess I'm a
>pariah :-).  The fundamental issue is this: Ada starts from the side
>of reliability and requires the programmer to unravel the safety
>where needed.  C++ starts from the side of "flexibility" (lack of
>safety, depending on your perspective :-) and forces the programmer
>to wrap up their nugget of data (members) with a layer of protection
>(classes). 

I agree with all this too, except that it's
not a source of misunderstanding.  Most of
the C++ programmers I know simply could not
care less about whether Ada9x is an OOPL or
not.  And this includes a guy whose first
language (in college) was Ada83.

>>>	Type checking within generics,
>>C++ provides this for every definition of that
>>phrase that I can think of.  I can only assume
>>that you mean something else.  Please elaborate.
>>
>Templates:   Grrrrr.   Write a class template.  Then repeat the
>template parameters _everywhere_.  Repeat them in your parameter
>lists, repeat them in your member functions, repeat them in your
>declarations.  "Ad naseum" is an understatement.  What's that got to
>do with reliability?  Not a damn thing, but it makes a BIG difference
>in readability.

Perhaps.  Although readability in C++ can
be helped by a thoughtful selection of
template parameter names.

>Again, type checking is loose, both in creation and elaboration of
>templates.  I owe you a better explanation on this one, but I'm short
>on time right now (should be doing my work on the Booch Component
>translation).

Yeah, slacker! ;-)

>>>	safe pointers
>>Can be provided, but not legislated.  In any
>>case, for programs of more than trivial com-
>>plexity, raw pointers are generally wrapped
>>in safe classes.
>>
>Wrap a pointer in a class and protect it?  Well, so
>much for simplicity....

But we really do this, and its just not that
big a deal.  We use handle/body classes to
get pass-by-value semantics and polymorphism
at the same time.  Instance management is
handled in a base class, and I don't have to
think about it.  We don't use built in arrays
at the application level, and in general
don't use pointers in unsafe ways.

>>More seriously, have ya got anything else?
>Yes, but out of time (as mentioned before).  I _do_ owe you a better
>explanation (I sure wouldn't be convinced by my reply here alone).
>Maybe others can chime in without letting this turn into a language
>flamewar (I know, I'm probably asking too much :-)

Yes, I would appreciate that too!

Oh, and thank you for the references yesterday.
I'm preparing a rebuttal to the 9x-cplus paper,
but I need some clarification on Ada 9x first:

How does polymorphism (dynamic dispatch) work
in Ada 9x?

Is Ada Covariant, Contravariant, or Invariant?

Could someone please explain "generic derived
types and generic formal packages" and how
they are different than C++ templates?

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[Magnus Kempe]

milod@netcom.com (John DiCamillo) writes:
:
: I'm preparing a rebuttal to the 9x-cplus paper,
: but I need some clarification on Ada 9x first:

IN OTHER WORDS: you don't know Ada 9X, but you will compare it to C++.

Nice trick.


: How does polymorphism (dynamic dispatch) work in Ada 9x?
: 
: Is Ada Covariant, Contravariant, or Invariant?
: 
: Could someone please explain "generic derived types and generic formal
: packages" and how they are different than C++ templates?

In how many words are we expected to explain these things to you?

How about FIRST learning what Ada 9X offers, and THEN comparing it to C++
(assuming of course that you already have first-hand knowledge of C++).

RTFM.

-- 
Magnus Kempe		"I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry

Re: Is Ada the future? [was: Is C++ the future?]

[Tucker Taft]

In article <milodCx5t7E.56p@netcom.com>,
John DiCamillo <milod@netcom.com> wrote:

> ...
>Oh, and thank you for the references yesterday.
>I'm preparing a rebuttal to the 9x-cplus paper,
>but I need some clarification on Ada 9x first:
>
>How does polymorphism (dynamic dispatch) work
>in Ada 9x?

Here is the short form:

    If the controlling operand(s) of a call on a primitive subprogram 
    are class-wide, then the tag of the operand(s) determine which
    body of the subprogram is executed.

Here is an attempt at a translation into English:

    In Ada 9X, one distinguishes explicitly between objects
    of a "specific" type (denoted by a simple type name like "T"), 
    and objects of a class-wide type (denoted by a name like "T'Class").
    This explicit distinction helps the programmer understand
    and control where dynamic binding is occurring.

    Class-wide types essentially represent a set of types, in particular,
    the class-wide type T'Class represents T and all types derived
    from T, directly or indirectly (this set of types is also called 
    the "class of types rooted at T").  If you don't use class-wide
    types anywhere in your program, then all binding is static.
    The only time you get dynamic binding is when you have a class-wide
    object (usually a parameter of a type like T'Class, or an object 
    designated by a pointer to a type like T'Class), and you pass it to 
    one of the "primitive" operations of its corresponding specific type
    (e.g. of the type T).  The primitive operations of a type T
    are those operations defined immediately within the same package
    spec as T itself, and that have parameters or a result of the specific 
    type T.  The primitive operations of a type are inherited by
    any derivative of T; they may be overridden if desired.

    Here is an example:
        package P is
            type T is tagged private;  
                        -- T is the root of the class T'Class
            function Image(X : T; Min_Width : Natural := 0) return String;  
                        -- Image is a "primitive" op of T
            function Combine(X, Y : T) return T;  
                        -- Combine is another primitive of T
          ...
            type T2 is new T with private;  -- derive T2 from T;
			-- T2 is the root of the (sub)class T2'Class
	    function Combine(X, Y : T2) return T2; 
                        -- overrides inherited Combine function
            -- inherits as is: 
            -- function Image(X : T2; Min_Width : Natural:=0) return String;

            procedure Break_Up(A : T2; B, C : out T2);
                        -- This is an additional primitive op of type T2
                                     
        end P;

    I can now pass operands of type T to the Image and Combine
    operations of type T, and operands of type T2 to the Image,
    Combine, and Break_Up operations of type T2.  Such calls would
    all use static binding.

    I could alternatively define an operation which took a parameter 
    of any type in the class rooted at T, and then used dynamic binding
    to call the "appropriate" implementation of any primitive of T, 
    based on a run-time tag carried along with the class-wide operand.  
    For example:

        procedure Put(Q : T'Class) is
	   -- Take an object of any type in class rooted at T
        begin
	   -- Use dynamic binding to call the "appropriate" Image function
           Text_IO.Put(Image(Q));
        end Put;

>Is Ada Covariant, Contravariant, or Invariant?

When an operation is inherited by a type T2 from a type T, the
new inherited operation is covariant in all operands and 
result that are of the specific type T, meaning that all the types
of such operands and result become T2, as illustrated above for 
Combine and Image.

This works quite well for binary and n-ary operations, and illustrates
one of the advantages of treating "controlling" operands symmetrically.
In Ada 9X there is no need to pull out one of the parameters to
the "prefix" position of the call, such as "Z := X.Combine(Y);".
You simply write, as in Ada 83, "Z := Combine(X, Y);".

>Could someone please explain "generic derived
>types and generic formal packages" and how
>they are different than C++ templates?

An Ada generic unit is very similar to a C++ template.
A "generic derived type" and a "generic formal package" are
simply differnt kinds of generic formal parameters.

There are 4 basic kinds of generic formal parameters:

   Formal Types, Formal Objects, Formal Subprograms, 
   and Formal Packages.

That means you can parameterize a generic unit by any
one of these four kinds of things.  

Unlike in C++, the semantic correctness of a generic unit 
is checked when it is compiled, rather than only when 
it is instantiated.  This means that the formal parameters 
of a generic must carry more information, to indicate 
to the compiler (and to the potential user of the generic ;-)
what kinds of features the actual types, objects, subprograms,
or packages, must have.  

For example, one can declare a given formal type 
as being a "discrete" type, which means that the
actual type must be an integer or enumeration type.  Inside the
generic unit you may only use operations that are available on
all discrete types, such as 'Image, 'Pred, 'Pos, assignment,
equality, relationals, etc.

In any case, to answer your original question, for a formal type
that is declared to be a "generic formal derived type," the actual
type must be any type descended from the ancestor specified in
the formal derived type declaration.  For a "formal package,"
the actual must be any instance of the generic package identified
in the declaration of the formal package.

In any case, I highly recommend you down-load and read the intro 
to Ada 9X, available on ajpo.sei.cmu.edu in public/ada9x/reports/intro,
in several popular formats (e.g. Word, WordPerfect, RTF,
ASCII, etc.).  It is quite short, and covers the above features
in a much more organized fashion than the above.

Perhaps even better, try GNAT (the GNU-based Ada 9X compiler,
available by FTP from cs.nyu.edu and elsewhere).  
It is hopeless to evaluate a language fully without taking 
it out for a spin...

>    John DiCamillo                        Pinin' for the fjords?
>    milod@netcom.com                  What kind of talk is that?

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: Is Ada the future? [was: Is C++ the future?]

[Robin Rowe]

How about some code examples to back up your theory?

Robin

-- 
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA 
Rowe Technology            C++ training, consulting, and users groups.

Re: Is Ada the future? [was: Is C++ the future?]

[Tucker Taft]

I believe your response simply pointed out one of the fundamental
differences between C++ and Ada.  In C++, you can build
safe abstractions if you work at it, but the defaults
provided by the language are unsafe.  In Ada, the defaults
provided by the langauge are safe, and if you work at it,
you can circumvent the safety checks.

Both are valid approaches.  My experience favors having
the language be inherently safe, with an ability to suppress
or circumvent the checking when circumstances demand it.
I could easily imagine that others have other experiences
and other preferences.

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Is Ada the future? [was: Is C++ the future?]

[Andrew Lees]

Robin Rowe (cpp@netcom.com) wrote:
: << In the meantime, I have a responsibility to write reliable software.  
: Ada 9X does that for me in ways that C++ folks are now only dreaming 
: about. >>

: What Ada 9X dreams am I supposed to be having? How about a 
: list of ways that Ada 9X can make more reliable software 
: than C++?

This is an interesting point.  I _know_ personally that it is possible to
write software using Ada with an error introduction rate during
design and coding something like
an order of magnitude better than C or C++.  (I have used all the languages
extensively).  However, this improvement is not seen in general, and I cannot
achieve it myself without significantly changing the intellectual tools used
to design and think about the software, and (to a lesser extent) the process
of development.  That is, Ada offers the _potential_ to get _much_ more
reliability and productivity (much, much less time spent "integrating" 
i.e. finding and fixing errors), but this is achievable only by doing things
differently.  Having thought long and hard about getting the same sorts of
improvement with C/C++, I don't think it is practicable (for various
reasons, mainly concerned with complexity in the case of C++).  So Ada
development could show a big competitive advantage over the other
contenders, but in practice it seems the difference (if any) can only
be discovered by careful analysis.

Lets face it, C++ stands a good chance of cornering the language use
market as things stand.  Ada 9X (and gnat especially!) will help to
redress the balance somewhat, but C++ has an enormous push going -
it's going to be difficult to change that.

Are there case studies around that show significantly and consistently 
lower production costs with Ada?  Or have we yet to acheive this sort
of scaled improvement?  I'm not talking about 20%, more like big multipliers.

I understand (only too well) that language is only one of the factors
in the software cost equation, but it seems that with all of the good
properties that Ada has (and now with its serious design flaws fixed),
it offers a great jumping off point for other process improvements.

: Thanks.

: Robin
:                   
:  
Regards,

Andy Lees.


: -- 
: -----
: Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA 
: Rowe Technology            C++ training, consulting, and users groups.

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

andrewl@sydney.DIALix.oz.au (Andrew Lees) writes:
>This is an interesting point.  I _know_ personally that it is possible to
>write software using Ada with an error introduction rate during
>design and coding something like
>an order of magnitude better than C or C++.  (I have used all the languages
>extensively).  However, this improvement is not seen in general, and I cannot
>achieve it myself without significantly changing the intellectual tools used
>to design and think about the software, and (to a lesser extent) the process
>of development.

In other words, if you design it right, using a good
engineering process, and code it right, you get a
good result.

>That is, Ada offers the _potential_ to get _much_ more
>reliability and productivity (much, much less time spent "integrating" 
>i.e. finding and fixing errors), but this is achievable only by doing things
>differently.

In other words, if you design it right, using a good
engineering process, and code it right, you get a
good result.

>Having thought long and hard about getting the same sorts of
>improvement with C/C++, I don't think it is practicable (for various
>reasons, mainly concerned with complexity in the case of C++).  So Ada
>development could show a big competitive advantage over the other
>contenders, but in practice it seems the difference (if any) can only
>be discovered by careful analysis.

Get real.  (Have ya flown into Denver recently?)

>I understand (only too well) that language is only one of the factors
>in the software cost equation, but it seems that with all of the good
>properties that Ada has (and now with its serious design flaws fixed),
>it offers a great jumping off point for other process improvements.

Naah, I've seen horrible atrocities committed in Ada,
and I've seen 'em committed in C.  If the engineers
don't have it, putting them in a "rubber-room" won't
stop them from hurting themselves.  If the engineers
do have it, they'll know enough not to run with the
scissors.

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[John DiCamillo]

milod@netcom.com (John DiCamillo) writes:
> Get real.  (Have ya flown into Denver recently?)

Earlier in this thread I made a post that implicitly
linked the Denver airport "fiasco" with Ada.  Since
that time I have been alerted that I was the victim
of an urban legend.  The Denver baggage system soft-
ware was not developed in Ada, and in no way reflects
on the capabilities of the language Ada nor its pro-
grammers.  I apologize for any confusion or damage
this error may have caused.

BTW, someone from this newsgroup informed me that the
system in question was actually developed in C++,
but I have not verified my source, and refuse to make
the same mistake twice. ;-)

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Is Ada the future? [was: Is C++ the future?]

[Robin Rowe]

According to officials of the Denver airport I have spoken to, the baggage
system was written in C++ under OS/2. There has been a lot of uninformed
speculation about the Denver system, including a thread on alt.cobol that
was accusing COBOL and Windows NT of being to blame, and even an article 
in this month's Scientific American which would have the reader
believe the system's problems were due to obsolete tools. 

Robin
  


-- 
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA 
Rowe Technology            C++ training, consulting, and users groups.

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

OK, so Denver was C++, but let's avoid the mistake of assuming that the
problems were due to the language, until we know more.

Re: Is Ada the future? [was: Is C++ the future?]

[David Weller]

In article <milodCx698o.GIM@netcom.com>,
John DiCamillo <milod@netcom.com> wrote:
>milod@netcom.com (John DiCamillo) writes:
>> Get real.  (Have ya flown into Denver recently?)
>
>Earlier in this thread I made a post that implicitly
>linked the Denver airport "fiasco" with Ada.  Since
>that time I have been alerted that I was the victim
>of an urban legend.  The Denver baggage system soft-
>ware was not developed in Ada, and in no way reflects
>on the capabilities of the language Ada nor its pro-
>grammers.  I apologize for any confusion or damage
>this error may have caused.
>
Just goes to show ya that people want to blame Ada for everything,
even if it wasn't related.  Gee, I never considered Ada as a
computer-language equivalent to Bill Clinton :-)

>BTW, someone from this newsgroup informed me that the
>system in question was actually developed in C++,
>but I have not verified my source, and refuse to make
>the same mistake twice. ;-)
>

Actually (and I know Robin Rowe is pretty serious about this),
there's no indication that C++ was the problem either (and, yes, to
my knowledge, it's being developed in C++ also).  The problem, from
reports I've read, goes back to the old "Do this four year project in
two years, cut corners where you can, and by the way (one year into
the project), here's a list of significant requirements changes."

My humble opinion:  The primary difference between C++ projects and
Ada projects is that developers on C++ projects are MUCH more
proficient using debuggers. :-)  [Extrapolate any way you want to]



-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

OK Richard, you are right, it isn't LISP that likes debuggers. That for me was
a shorthand for "typical LISP programmers", or "the spirit of LISP" or
somesuch.

I think the reason that highly dynamic languages tend to like to use
debuggers (in the same general sense as para 1 above :-) is that almost
all error detection is put off till runtime, and so the normal style is
throw code together, try to run it, and then remove the bugs. Second it
is easy to change code on the fly from within the debugger in LISP, so
one gets to a point where the debugger is not merely a debugger but
essentially a programming environment.

I am not saying this is good, and I am not saying this is the only way to
program Lisp. I am just observing what from what I see and hear around me
seems to be the most typical usage patterns.

Re: Is Ada the future? [was: Is C++ the future?]

[Stephen J Bevan]

In article <36uhnl$4c1@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
   ... LISP shares this view of debuggers, I remember giving my view
   of debuggers to Gabriel, and he laughed furiously and said it was
   the funniest thing he had heard all day.

Doesn't that mean that Gabriel shares this view of debuggers, not Lisp?
I know Gabriel has written a lot of Lisp code in his time but that
doesn't mean that he speaks for all or even the majority of Lisp users.

Re: Is Ada the future? [was: Is C++ the future?]

[Robert Dewar]

Stephen, believe me, the *great* majority of Lisp programmers would feel
lost without a debugger. There may be some singular exceptions (in all the
hundreds of lisp programmers I have met, I never found one, but of course
no universal quantification is likely to be accurate when it is done over
people :-)

Re: Is Ada the future? [was: Is C++ the future?]

[Stephen J Bevan]

In article <383fa7$29i@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
   ... Stephen, believe me, the *great* majority of Lisp programmers would feel
   lost without a debugger. ...

I can believe they might be lost without a read-eval-print loop, but a
read-eval-print loop is not a debugger.

Re: Is Ada the future? [was: Is C++ the future?]

[Ted Dennison]

In article <milodCx698o.GIM@netcom.com>, milod@netcom.com (John DiCamillo) writes:
|> milod@netcom.com (John DiCamillo) writes:
|> > Get real.  (Have ya flown into Denver recently?)
|> 
|> Earlier in this thread I made a post that implicitly
|> linked the Denver airport "fiasco" with Ada.  Since
|> that time I have been alerted that I was the victim
|> of an urban legend.  The Denver baggage system soft-
|> ware was not developed in Ada, and in no way reflects
|> on the capabilities of the language Ada nor its pro-
|> grammers.  I apologize for any confusion or damage
|> this error may have caused.
|> 
|> BTW, someone from this newsgroup informed me that the
|> system in question was actually developed in C++,
|> but I have not verified my source, and refuse to make
|> the same mistake twice. ;-)
|> 

pragma Cheap_Shot;


Missed milestones, unexpectedly long test times, poor, buggy
performance... has "C" written all over it.

...but I do applaud your (newfound) caution.

T.E.D.

Ada compared to C++

[Robin Rowe]

      ==========================================================
      Response to Edmond Schonberg's "CONTRASTS: Ada 9X and C++"
      ==========================================================

by Robin Rowe
Rowe Technology
cpp@netcom.com
Posted to comp.lang.ada (10-3-94)
cc: Schonberg@cs.nyu.edu

Schonberg's paper can be retrieved as:
    9x-cplus.txt under /public/ada9x/reports/misc
    ftp ajpo.sei.cmu.edu

INTRODUCTION
------------

Before I begin, I want to make two things clear. One, that I intend 
no disrespect to the author of the original paper, and two, that I 
am an expert in C++ but not in Ada. Edmond Schonberg chose a 
challenging task in comparing the safety and reliability of Ada and 
C++. It is very difficult to be neutral when comparing two 
languages, and almost impossible to be proficient enough in both 
languages to draw valid comparisons. Few engineers can write the 
equivalent code in two dissimilar languages.

Reliability and engineering in C++ hold special interest for me. I 
have recently given talks on this topic at Object Expo in NYC and 
the Symantec Developers Conference in Monterey. It is also what I 
teach as a C++ trainer. My background includes teaching Intermediate 
C++ for a year at the University of Washington.

Schonberg says:
<< The comparison of programming languages is in part a subjective 
affair....>> 

This is true. However, I think the ES paper suffers from being too 
hypothetical in nature. It contains no realistic C++ code examples. 
Many assertions were made with so little basis that I couldn't 
imagine how the author's point would translate into an actual 
design. Anyone can prove anything in the abstract. Not having 
concrete examples was the hardest part in responding to the ES 
paper. If the topic is which software language can better support 
software safety and reliability, then I think it is incumbent upon 
the author to actually show some safe and unsafe code so the danger 
can be seen clearly.

BUILDING SYSTEMS WITH OUT-OF-DATE COMPONENTS
--------------------------------------------

<<...the first guarantee of reliability is that the Ada system 
itself will not let you build a system with out-of-date 
components.>>

In C++, proliferation of components seems to be a much greater 
problem than building with out-of-date components. It's not unusal 
to have developers deliberately using out of date libraries because 
the new ones don't work yet or aren't tested yet. ES admits that 
'make' can handle the task of keeping components up to date, and 
neglects to mention that C++ shops routinely use version control 
software to keep projects up to date. It would be nice to have these 
tools built into the compiler (and that is the way things are moving 
in C++), but the versioning problem extends well beyond the 
language, or even the tools.

PORTABILITY
-----------

ES contends that portability is difficult to achieve in C++. C is 
the most ported language around, and C++ is ported a lot. C++ 
is not just a Unix tool, as some contend. More MS-DOS C++ compilers 
have been shipped than for any other platform. Commercial DOS and 
Windows programs written in C or C++ include WordPerfect, Lotus 
1-2-3, Paradox, Word, Excel and dBase, just to name a few. Lotus 
1-2-3 was even rewritten from scratch in C to gain portability. I 
think this non-portability argument can be dismissed.

ARRAYS
------

ES doesn't seem to want to talk about array templates in C++. All 
of his array issues apply just to C-style arrays. A C++ array 
template can check indexing operations, do array assignment, use 
indices of other types, handle sparse arrays, and whatever else you 
can come up with.

<< Given that indices out of bounds are the most common type of 
run-time error, this makes the use of arrays in C++ inherently less 
safe than in Ada.>>

This is a good point. C-style arrays are often misused in C++. 
However, there is a common idiom to avoid running off the end of a 
C-style array: use asymmetrical bounds. The 'i' in this code won't 
fall off the end of the array:

    enum {SIZE=1000}; // A constant called SIZE.
    int array[SIZE];  // An array of integers.
    for(int i=0;i<SIZE;i++) // Arrays start at 0, end just before 
SIZE.
    {   array[i]=i;  // Set each element equal to its offset.
    }
    array[SIZE]=0; // Memory corrupted. Unchecked except by test.

Here it is using an array template:

    enum {SIZE=1000};
    Array<int> array(SIZE); // An array container.
    for(int i=0;i<SIZE;i++)
    {   array[i]=i;
    }
    array[SIZE]=0; // Wrong, but handled by template.

The deeper question is, what does it mean that the programmer made 
an error in accessing the array? Should the program abort, continue, 
make the array bigger, throw the problem back to the caller, log the 
error to a file, what? 

What does Ada do when an array is overrun? What does it do if 
exceptions are turned off?

<<...one cannot define an array over an enumerated type, and there 
is never any type checking on indices.>>

C++ can have an array template over an enumerated type, but it is 
inconvenient. C++ always type checks on indices. It is bounds 
checking that is not done on C-style arrays.

EXCEPTIONS
----------

<< Unfortunately, the proper implementation of the [Array] class 
requires exceptions, a feature which has only recently been 
introduced into C++ and which is not widely (nor consistently) 
implemented yet.>>

No, exceptions are not required. As in Ada, using exceptions is 
actually not a very good idea for systems demanding high 
reliability. The reason is that exceptions want to terminate the 
program. Only if the programmer manages to catch the exception is 
abort avoided. Testing exceptions is often not feasible.

With an array template, the programmer can do something like this 
(without exceptions):

    array[SIZE]=0; // Wrong, but handled by template.
    if(array.HasError())
    {   cerr<<"Tell the clumsy programmer to stay inside array";
    }   // cerr is console error message.

Exceptions are available in many C++ compilers now, and will be 
commonplace in C++ compilers within a few months. All the major C++ 
compiler vendors now have them in beta.

Isn't it true that Ada exceptions are typically turned off for 
safety-critical software designs?

<< We should also remark that compilers make a big effort to 
optimize the use of built-in arrays, because they are the basic 
structure of many compute-intensive programs. Compilers are much 
less likely to treat user-defined arrays with the same care....>>

Without examples, it's impossible to judge where this may be 
relevant.

OBJECT-ORIENTED PROGRAMMING
---------------------------

<< Object-oriented programming and design (OOP) has become the 
buzzword of the decade. Behind the obvious enthusiasm of the 
software community there lies the correct perception that OOP 
simplifies the design and construction of software systems. The 
basic reason is ease of reuse. >>

No, the important reason is encapsulation. It is through 
encapsulation that objects maintain their integrity. Reuse is good, 
too. But, you're missing the point if reuse is the primary goal of 
your design philosophy. Encapsulation makes it possible for objects 
to resist failure.

Does Ada support the concept of private, protected, and public 
class members?

<< But in fact the usefulness of OOP....lies in the combination of 
inheritance, specialization by extension, and dynamic dispatching. 
The gain is in the amount of code that one does not have to write, 
simply because one can obtain it by inheritance from the previously 
defined software component. >>

The features supported by an object-oriented programming language 
are polymorphism, inheritance, and encapsulation. (See Grady Booch 
if you don't believe me.) How does Ada implement each of these? May 
I see some compilable code examples that do something useful?

Inheritance for reuse is often an abuse, at least in C++, because 
derived classes may invalidate tested base classes through protected 
member access. Also, any inherited class is interchangable with its 
base class in C++ (through a reference or pointer). Making truly 
interchangable parts is not that easy. 

Containment is generally a much better form of reuse in C++ and 
doesn't subvert the type system. In C++ a class is a definition of 
how an object works, not the actual object. I've heard Ada doesn't 
work this way. How does Ada support objects containing other 
objects? 

METHODS AND FUNCTIONS
---------------------

<<...the notion of class in C++ derives from that of structure, and 
suggests that subprograms that apply to objects of a class are in 
some sense part of those objects (class members). >>

No, not everything in C++ is a method. You just use it where makes 
sense.

    BCD bcd=10; // Binary coded decimal object named 'bcd'.
    int x=11;   // An integer named x.
    cout<<max(bcd,x); // This way is typical, global function.
    cout<<bcd.max(x); // Legal but ugly method call.
    cout<<x.max(bcd); // Illegal. Built-in type can't have methods.
    // cout is console output, in this case '11'.

ENCAPSULATION
-------------
    
<< In our experience, it is seldom useful to think of the 
operations as being part of a value (unless they are entries in a 
task). The Ada 9X model provides the benefits of OOPS without this 
somewhat muddled notion of object. >>

This is contrary to common sense and OOP practice. Asking an object 
to perform an action on itself instead of twiddling with its 
internals yourself is the foundation of OOP. It is this 
encapsulation that makes for reliable objects. A C++ object can 
resist doing something wrong.

<< Note also that C++ classes are the only encapsulation mechanism 
in the  language (if one excludes the use of files as modules), and 
thus they also  play the role that packages play in Ada. This dual 
role is better served with two separate notions. >>

C++ has added namespaces to deal with this issue.

<< The Ada 9X model also provides a more natural description of 
binary operations....In the C++ model the member function has an 
implicit first parameter:

    class parent {
    ...
    parent merge(parent)
    ...
    }

    class child: public parent { ...
>>

This example is so sketchy that it is impossible to see what its 
usefulness could be. There are at least two errors in these four 
lines of code. (The type passed to merge should be a reference to a 
parent, not a copy, and the semi-colon is missing at the end of the 
class declaration.) Without some idea of what useful purpose this 
code could have, no further comment is possible. What's the point?

FRIENDS
-------

<< The notion of friend functions and friend classes is one of the 
more controversial aspects of C++. Its defenders correctly point out 
that the built-in privacy of class members that are not explicitly 
declared public means that it is well-nigh impossible to write 
efficient code that makes use of two distinct classes A and B....>>

No, inline accessor functions are generally just as efficient as 
direct public access. This issue is not a general problem, but a 
special case.

<< This is often unacceptable (the canonical example is 
vector-matrix multiplication, when each is defined as a separate 
class, which forces a large number of redundant index checks in the 
code). >>

C++ matrices are often made up from two classes so that the [][] 
notation can be used:

    Matrix m(10,10); // 10x10 matrix.
    m[5][5]=7; // Set a matrix element to 7.
               // 2nd hidden object manipulates 2nd [].

If you aren't attached to this notation, you can instead do this:

    Matrix m(10,10);
    m(5,5)=7; // No 2nd bracket. No need for hidden object.

In Ada, if I'm not mistaken, friendship is taken, not granted. 
Isn't this dangerous?

ITERATORS
---------

Using friends as an efficiency trick is rarely called for. A more 
typical use of friend is for iterators. The friend mechanism allows 
splitting a class into a one to many relationship. Making an 
iterator a friend instead of a member of a container makes it 
convenient to have multiple cursors into the same object. A typical 
example is smart pointers into an array. How does Ada handle 
iterators? How does Ada support containers?

REAL-TIME
---------

<< There are as yet no winning proposals for tasking facilities in 
C++, and no hint of notions of real-time and scheduling tools.  In 
this area C++ is a non-starter, even compared with Ada83. >>

Bjarne Stroustrup (the designer of C++) feels that real-time is 
better supported through libraries in C++ than by language 
extension. Rather than make this a least common denominator type of 
feature, it is up to each implementation to do the best it can. This 
approach was used successfully with i/o and seems reasonable to most 
C++ programmers.

TEMPLATES
---------

<< The designer of C++ has recognized the need for a more 
disciplined  parametrization mechanism, and the latest version of 
the language describes templates, a facility that is close in spirit 
to Ada generics. >>

Templates have been around for a while in C++, hardly one of the 
latest features. They are in the ARM (the Annotated Reference Manual, 
published in 1990). The most popular C++ compiler (Borland) has had 
them for years.

<< Ada 9X has an even richer set of parametrization mechanisms than 
Ada. In Ada 9X it is possible to specify generic derived types 
(where the actual is any member of the class of the generic type) 
and generic formal packages (where the actual is any instantiation 
of the generic formal package). This later form of parametrization 
is more powerful than what is available in C++, and is akin to the 
use of functions and signatures in ML. Both in terms of 
expressiveness and clarity Ada 9X has a clear advantage over C++ 
here. >>

You will have to show some code examples for me to buy any of this. 
Of what use is this "more powerful" parameterization?

MULTIPLE INHERITANCE
--------------------

<< It might be argued that the multiple inheritance model of the 
current version of C++ is definitely superior to what is proposed 
for Ada 9X.  This is a most minor point....>>

Granted on both counts.

READABILITY
-----------

<< Ada programs read well....In contrast, C and C++ emphasize ease 
of writing rather than ease of reading. Thus a greater use of 
operators, of terser notations (the conditional expression, for 
example) and an absence of keywords (most noticeably in 
declarations). This makes C++ programs harder to transmit and to 
maintain. >>

This is quite an amazing assertion to make without giving any code 
examples! C++ code does look a lot more mathematical than COBOL, a 
language designed to avoid this notation. Is being more like COBOL 
an advantage? Some people (engineers, for instance) find a 
mathematical notation much more readible and precise than the 
equivalent English sentences. 

The ternary operator '?' is rarely used except in return 
statements. It's no big deal.

<< In fact, those [Ada] keywords act as natural punctuation marks, 
and make program reading more natural: a begin-end bracketing is 
more natural-sounding than {..}. >>

Here's how I read a piece of C++ code:

    if(!object)                  // "If not object [then]"
    {   cerr<<object.ErrorMsg(); // "output object's error 
    }                            //  message,"
    else                         // "else"
    {   object++;                // "increment object."
    }

So what's unnatural about this? Sounds like English to me.

OBFUSCATED CODE
---------------

<<...it is clear that C and C++ programmers enjoy enormously the 
game of "guess what this computes?". The question would not be fun 
if the answer were not in same way unexpected! ....In contrast, this 
form of entertainment is completely missing from the Ada culture. 
Ada code does what it says, plainly. >>

This is like saying demolition derbies prove all cars to be unsafe. 
There are a large number of hackers in C, and now C++. I'm sure 
these individuals could write code just as perverse in Ada if it was 
popular enough that others would get the joke. Almost every 
indictment of C or C++ that I've seen includes some reference to the 
Obfuscated Code Contest, which is sort of a Rube Goldberg contest 
for C. It doesn't prove anything except that people can write bad 
code if they try. Like Freud said, "Sometimes a cigar is just a 
cigar."

Along similar lines, I think most programmers are familiar with the 
pc-lint ads in the programming magazines. The ads present, for 
instance, "C/C++ Bug #525" where the reader is challenged to 
discover why some piece of horrendously bad C code doesn't work. 
Students are particularly intrigued by this sort of thing, mainly 
because they can't see the answer. For 99% of the time the correct 
response is, "Who cares?". The code is so poorly designed there is no 
point in correcting its defects. Real code like this is sure to have 
logic errors, too.

STANDARDIZATION
---------------

<< To compare Ada 9X and C++ is not easy, if for no other reason 
than C++ is a language in flux for which no stable definition 
exists, no approved standard reference, and no translator validation 
suite.  A glance at the list of additions to the language since 
version 2.0 (see [S91]) is sufficient to realize that active 
language design is still going on. >>

The ANSI committee recently completed the feature set of C++ and is 
now preparing the draft standard proposal. It's no longer in flux.

I'd like to know more about the Ada translator validation suite. 
Exactly what does it validate?

CONCLUSION
----------

Rather than being black-and-white, it's more likely that Ada is 
better in some areas of software engineering and C++ is superior in 
others. The Schonberg paper doesn't present enough information to 
draw informed conclusions about which those areas are. 

For those who chose to follow up, I hope we can stick to software 
engineering issues and somehow avoid the unfortunate tendency on the 
net of language evangelism. Surely Ada and C++ can each stand on 
their own merit. Perhaps together we can discover something new 
about how Ada and C++ can best be used, and about software 
engineering in general.

Robin
  
-- 
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA 
Rowe Technology            C++ training, consulting, and users groups.

Re: Ada compared to C++

[Bob Kitzberger]

Robin Rowe (cpp@netcom.com) wrote:

> BUILDING SYSTEMS WITH OUT-OF-DATE COMPONENTS
> --------------------------------------------
> 
> ES: <<...the first guarantee of reliability is that the Ada system 
> itself will not let you build a system with out-of-date 
> components.>>
> 
> In C++, proliferation of components seems to be a much greater 
> problem than building with out-of-date components. It's not unusal 
> to have developers deliberately using out of date libraries because 
> the new ones don't work yet or aren't tested yet. ES admits that 
> 'make' can handle the task of keeping components up to date, and 
> neglects to mention that C++ shops routinely use version control 
> software to keep projects up to date. 

ES was being a bit extreme about this.  In all of the Ada environments
I've used, you can indeed use prior versions of units to build an
executable (but not out-of-date components).  The key point here is
that when you build an Ada program, the transitive closure of the
main program is examined for out of date components, and those
components (or parts of components -- statements, etc.) are recompiled
before linking the executable.  The _domain_ that defines the
transitive closure may specify to use personal libraries, e.g., in 
computing parts of that closure.  

Typically, you must go out of your way, with Ada environments, to 
build an inconsistent application (i.e. one using unintended versions
of components).    I would hope this is the same case in C++ 
development, though I personally find the "make" family of tools
to be an incredible drag (and yes, I know them reasonably well).
"an incredible drag" isn't much of a technical argument, I know ;-)


> PORTABILITY
> -----------
> 
> ES contends that portability is difficult to achieve in C++. C is 
> the most ported language around, and C++ is ported a lot. C++ 
> is not just a Unix tool, as some contend. More MS-DOS C++ compilers 
> have been shipped than for any other platform. Commercial DOS and 
> Windows programs written in C or C++ include WordPerfect, Lotus 
> 1-2-3, Paradox, Word, Excel and dBase, just to name a few. Lotus 
> 1-2-3 was even rewritten from scratch in C to gain portability. I 
> think this non-portability argument can be dismissed.

Availability of C and C++ development environments on a multitude
of environments is not the same thing as portability of applications
written in C or C++ (as an aside, there are many Ada development
environments available, from lowly PCs to Crays and everywhere in 
between).  

The problem with portability in C and C++ is that there is a plethora
of implementation inconsistencies (K&R vs. ANSI C, C++ with templates,
C++ without templates, C++ with namespace, C++ without namespace etc.)
To remain truly portable implies adhering to the least common
demoniator, K&R (yes, an extreme conclusion not to be taken seriously).
With C++ standardization, this will become much less of a problem.

My suspicion, though, is that the real problem for C++ or Ada viz-a-viz
portability is the use of external frameworks -- class libraries, GUI
libraries, OS services, thread libraries, etc. that are not necessarily
portable from one platform to another.  Ada has a _slight_ advantage
here, in that concurrency is provided in the language, and so at least a
subset of concurrent applications are portable from one platform to
another (I have developed concurrent embedded systems components
entirely on the host, with minimal tuning on the target -- an everyday
occurence in Ada).  On the other hand, C++ has a big advantage insofar
as most APIs are defined in C, and thus trivially called from C++. 
Ada requires either the existence of a binding to the service
(e.g. POSIX/Ada) or writing "pragma Interface" skins over the API.
I believe there are tools to automate this process (gadzooks!  I work
for a tool vendor; need to get cracking on it!)

> This is a good point. C-style arrays are often misused in C++. 
> However, there is a common idiom to avoid running off the end of a 
> C-style array: use asymmetrical bounds. The 'i' in this code won't 
> fall off the end of the array:
> 
>     enum {SIZE=1000}; // A constant called SIZE.
>     int array[SIZE];  // An array of integers.
>     for(int i=0;i<SIZE;i++) // Arrays start at 0, end just before 
> SIZE.
>     {   array[i]=i;  // Set each element equal to its offset.
>     }
>     array[SIZE]=0; // Memory corrupted. Unchecked except by test.

How can this be applied outside of iterators?  I agree, though, that
the real answer is to use array templates.

> The deeper question is, what does it mean that the programmer made 
> an error in accessing the array? Should the program abort, continue, 
> make the array bigger, throw the problem back to the caller, log the 
> error to a file, what? 
>
> What does Ada do when an array is overrun? 

It's very difficult to overrun an array (I have yet to write code that
did this, in years of Ada work) but if this happens, then a
predefined exception is raised.

> What does it do if exceptions are turned off?

Undefined (caveat exceptor ;-)

> <<...one cannot define an array over an enumerated type, and there 
> is never any type checking on indices.>>
> 
> C++ can have an array template over an enumerated type, but it is 
> inconvenient. C++ always type checks on indices. It is bounds 
                ---------------------------------
> checking that is not done on C-style arrays.

r.e. C++ checks types on indices -- a question.  I thought that array
indices can only be integers (if my quick scan of the C++ RM is
correct).  So what does it mean to check types of array indices in C++?
An example?

In any event, the more pervasive problem is the lack of range
checking on indices (or any scalars, for that matter) in C++.  In Ada:

    type Array_Range is range 1..MAX_ELEMENTS;
    type Elements is array(Array_Range) of Element;

You cannot use anything except an object of Array_Range to index
into Elements, without going through gyrations.  The compiler will
check types on the index, and complain loudly of violations.  To 
perform the equivalent in C++ requires creation of a new class (or
subclass, if you have an appropriate base class handy).  

The more mundate situation is simple range constraints on scalars:

    Precision: constant := 0.1;
    type Degree_Measure is delta Precision range 0.0 .. 360.0;
    type Lattitude is new Degree_Measure;
    type Longitude is new Degree_Measure;

Of course, type and range checking are performed.  Again, to perform the
same thing in C++ requires creation of a new class (probably not a bad
idea, that, but do all (most?) C++ developers honestly create a new
class to handle range constraints on simple scalars? 

> EXCEPTIONS
> ----------
>
> Testing exceptions is often not feasible.

Can you expand on that?    This is more than a rhetorical
request: I develop testing tools, and we do support testing (or plan
on it ;-) of exceptions in most ways that I can conceive of.

> FRIENDS
> -------
> 
> << The notion of friend functions and friend classes is one of the 
> more controversial aspects of C++. Its defenders correctly point out 
> that the built-in privacy of class members that are not explicitly 
> declared public means that it is well-nigh impossible to write 
> efficient code that makes use of two distinct classes A and B....>>
> 
> No, inline accessor functions are generally just as efficient as 
> direct public access. This issue is not a general problem, but a 
> special case.

The more general problem, IMHO, is that inline accessors break 
encapsulation and violate information hiding, by exposing
class internals at the interface level.  The need to declare
all private members in the class definition is a bit distasteful
as well (yes, the compiler still enforces the encapsulation, but
the internals are still visible; perhaps this is just a pet peeve
of mine).   Anyone can see your privates, but only your friends
can access them ;-)

> REAL-TIME
> ---------
> 
> << There are as yet no winning proposals for tasking facilities in 
> C++, and no hint of notions of real-time and scheduling tools.  In 
> this area C++ is a non-starter, even compared with Ada83. >>
> 
> Bjarne Stroustrup (the designer of C++) feels that real-time is 
> better supported through libraries in C++ than by language 
> extension. Rather than make this a least common denominator type of 
> feature, it is up to each implementation to do the best it can. This 
> approach was used successfully with i/o and seems reasonable to most 
> C++ programmers.

Yes, both languages took opposite choices in the tradeoff: portability 
vs. flexibility.  As more applications in C++ start using thread
libraries, and running into portability issues, re-entrant code issues,
etc. it may be that concurrency is the next feature to be added to
C++ ;-)  

> TEMPLATES
> ---------
> 
> << The designer of C++ has recognized the need for a more 
> disciplined  parametrization mechanism, and the latest version of 
> the language describes templates, a facility that is close in spirit 
> to Ada generics. >>
> 
> Templates have been around for a while in C++, hardly one of the 
> latest features. They are in the ARM (the Annotated Reference Manual, 
> published in 1990). The most popular C++ compiler (Borland) has had 
> them for years.

The ES paper was written several years ago, when templates were hot
off the press.  You've got to give ES a break on these points ;-)

> READABILITY
> -----------
> 
> << Ada programs read well....In contrast, C and C++ emphasize ease 
> of writing rather than ease of reading. Thus a greater use of 
> operators, of terser notations (the conditional expression, for 
> example) and an absence of keywords (most noticeably in 
> declarations). This makes C++ programs harder to transmit and to 
> maintain. >>
> 
> This is quite an amazing assertion to make without giving any code 
> examples! C++ code does look a lot more mathematical than COBOL, a 
> language designed to avoid this notation.

Not sure that I agree that C++ is more mathematical.  e.g.:

    X := X + 1;     -- Ada  
    if ( x = x+1)   -- "

    x++;            // C++
    x = x + 1;      // "
    ++x;            // "
    if (x == x+1)   // "
    x += 1          // "
    
Since Ada uses ":=" for assignment, it is clearly not the same as the
mathematical equation "x = x + 1".  But the C++ version use the same
notation as the mathematical equation, but is bogus: obviously x cannot
equal x + 1.  Hence the ever-present "=" vs. "==" mistakes (albeit
catchable by lint, if you choose to run it and ignore those cases
where it whines about non-problem areas).

The pre-increment and post-increment operators aren't very
'mathematical', either.  As for "op=" operators, I'm a bit fond of them ;-)

But perhaps you were thinking about some other examples, not 
necessarily the trivial examples I've shown that shed a positive
light on Ada ;-)  Seriously, post an example, and I'll write
an Ada equivalent.  Try for an example that C++ is particularly good
at expressing in its syntax.

One nice thing about Ada's syntax is the ability to self-document
code, by being verbose when needed, and (somewhat) terse when 
needed.  For example, consider the following:

    procedure Append(Source : in Object; Target : in out Object);

To call this function, I could write:

    Append( X, Y);

...but if Append's definition isn't close at hand, it isn't at all
obvious what this means... is X appended to Y, or visa versa?  To
self-document, I would write:

   Append( Source => X, Target => Y );

With a decent LSE, it's not much typing, either.

> Here's how I read a piece of C++ code:

...yes, as do I.  The simple examples are a bit misleading, though.
What is more confusing are if statements containing assignments, e.g.
and other side effects of not having a predefined boolean type.

    if(object= new_object())
        Frobozz;

This example bring up another danger: using conditionals without 
brackets.  Further maintenance of the code could easily produce the
following error:

    if(object= new_object())
        Frobozz;
        Blat;

...where Blat is executed regardless of the conditional.  Yes, coding
conventions could "solve" this problem -- but there are so many cases
where coding conventions are relied on to mitigate danger zones in the
syntax ("=" vs. "==", etc.) that a book has been written on the topic
("Writing Solid Code" or somesuch, by MicroSoft press).

Is this a readability problem?  Certainly... since during maintenance
the code was obviously misread.  And yes, these are C issues, but they
are inherited by C++.

> OBFUSCATED CODE
> ---------------
>
> Along similar lines, I think most programmers are familiar with the 
> pc-lint ads in the programming magazines. The ads present, for 
> instance, "C/C++ Bug #525" where the reader is challenged to 
> discover why some piece of horrendously bad C code doesn't work. 
> Students are particularly intrigued by this sort of thing, mainly 
> because they can't see the answer. For 99% of the time the correct 
> response is, "Who cares?". 

Agreed (modulo the need for lint in the first place ;-)

> For those who chose to follow up, I hope we can stick to software 
> engineering issues and somehow avoid the unfortunate tendency on the 
> net of language evangelism. 

The tendency isn't limited to the net -- merely to those that take
these things seriously ;-)   Re-reading my response, I see obvious
tinges of evangelism (and in ES' paper, and in your response).
Ah well.

    .Bob.





--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945

Re: Ada compared to C++

[Robert Dewar]

Of course the key here is not out-of-date, but inconsistent, and indeed
Ed's arguments would be clearer with this modification.

Make is, as I have found out, having used it for GNAT for some time now,
totally inadequate. The fundamental problem is that the comparison of
greater than on time stamps just doesn't work. If you go back to a previous
version of the source with an old time stamp, then make thinks it's up to
date. Of course in the GNAT case, the binder complains, so you can't actually
build the inconsistent application that make thinks is just fine (but of
course you could in C or C++).

Now of course I realize that there are much more sophisticated tools than
make for ensuring consistency (e.g. clearcase from SGI, recently mentioned
in this newsgroup). If someone will promise me that all C++ applications
are built with such tools, and no one uses make or worse still, nothing at
all, then all would be well, but you know perfectly well this is not the
case (or perhaps I should say not the clearcase :-)

With Ada on the other hand, I know that everyone is using tools to ensure
consistency because you can't get around them (without doing something
very deliberate).

Note that there is nothing to stop the Ada approach from being grafted into
C++. An interesting project in the GCC world would be to make g++ share the
same consistency mechanisms that are used by GNAT. However, it is clear that
there is a real advantage in having these mechanisms clear at the language
level.

Going back to GNAT, we will continue to use make files indefinitely (unless
someone follows the GCC thoughts in the previous paragraph), since GNAT is
a mixed C/Ada application, and we need the make for the C part (and in any
case we use make for higher level control like building distributions and
running bootstraps).

However, the explicit list of dependencies in the GNAT makefile for the
compiler Ada sources is very irritating. For one thing, it is always one
step out of date, it is yesterdays dependencies, not todays. The solution
of course is a decent make program, and we are now working on one (its
actually quite simple to do) called gnatmake, and then the make file will
simply call gnatmake.

Re: Ada compared to C++

[Bob Kitzberger]

Bob Kitzberger (rlk@rational.com) flubbed:

: My suspicion, though, is that the real problem for C++ or Ada viz-a-viz
                                                                ^^^^^^^^^
: portability is the use of external frameworks -- class libraries, GUI

Gack.  Misspelled, and an innapropriate usage as well.  Please substitute
"with regard to".

	.B.

Re: Ada compared to C++

[Magnus Kempe]

cpp@netcom.com (Robin Rowe) writes:
:      ==========================================================
:      Response to Edmond Schonberg's "CONTRASTS: Ada 9X and C++"
:      ==========================================================
: ...
:
: What does Ada do when an array is overrun? What does it do if 
: exceptions are turned off?

Well, if you don't know, how can you claim to answer a comparison
of Ada and C++ ?


: Does Ada support the concept of private, protected, and public 
: class members?

Again, if you don't know...


: The features supported by an object-oriented programming language 
: are polymorphism, inheritance, and encapsulation. (See Grady Booch 
: if you don't believe me.) How does Ada implement each of these?

If you don't know...


: Containment is generally a much better form of reuse in C++ and 
: doesn't subvert the type system. In C++ a class is a definition of 
: how an object works, not the actual object. I've heard Ada doesn't 
: work this way. How does Ada support objects containing other 
: objects?

If you don't know...


: How does Ada handle iterators?  How does Ada support containers?

If you don't know...


To understand and answer a comparison of two languages, one is expected
to at least know both.  I recommend that C++-fans learn about Ada, in
order to support their judgment, and also that Ada-fans learn about C++.
The best way to learn about a programming language is to read some books
about it, as well as to write some code.  For Ada, the Ada WWW Server
contains a list of references put together by Mike Feldman (URL
http://lglwww.epfl.ch/Ada/ see the section on Books and Articles).
The worst way is to read Usenet news and believe everything one sees
there, or to go by hearsay.

Comparison is a form of judgment.  Judgment requires evidence.  So
before one publishes or answers a comparison, one must have gathered
the evidence.  Thank you.

-- 
Magnus Kempe		"I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry

Re: Ada compared to C++

[David Weller]

In article <1994Oct5.091826@di.epfl.ch>,
Magnus Kempe <Magnus.Kempe@di.epfl.ch> wrote:
>To understand and answer a comparison of two languages, one is expected
>to at least know both.  I recommend that C++-fans learn about Ada, in
>order to support their judgment, and also that Ada-fans learn about C++.
>The best way to learn about a programming language is to read some books
>about it, as well as to write some code.  For Ada, the Ada WWW Server
>contains a list of references put together by Mike Feldman (URL
>http://lglwww.epfl.ch/Ada/ see the section on Books and Articles).

Just to maintain balance, I recommend Bjarne Stroustrup's "The Design
and Evolution of C++" and either the C++ Annotated Reference Manual
or Bjarne's "The C++ Programming Language, second edition".  These
are all good books for C++ people.  Most folks will find the GNU C++
compiler (g++) will be more than sufficient to learn about it.

In any case, our goal is to behave with reason and to freely talk
about the differences.  It's certainly incumbent upon everybody
engaging in this thread to have a reasonable amount of experience
with both languages.  



-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Ada compared to C++

[Mark S. Hathaway]

> In article <1994Oct6.133002.1@rapnet.sanders.lockheed.com>,
> gamache@rapnet.sanders.lockheed.com writes:

>> In article <cppCx50GD.G0y@netcom.com>, cpp@netcom.com (Robin Rowe) writes:
 
>>> Schonberg says:

>>> The comparison of programming languages is in part a subjective 
>>> affair.... 
 
>> This is true. However, I think the ES paper suffers from being too 
>> hypothetical in nature. It contains no realistic C++ code examples. 
>> Many assertions were made with so little basis that I couldn't 
>> imagine how the author's point would translate into an actual 
>> design. Anyone can prove anything in the abstract. Not having 
>> concrete examples was the hardest part in responding to the ES 
>> paper. If the topic is which software language can better support 
>> software safety and reliability, then I think it is incumbent upon 
>> the author to actually show some safe and unsafe code so the danger 
>> can be seen clearly.
 
> I don't know ES nor have I read the referenced paper.  However, I choose to
> disagree here anyway.  While there is a chance that the readability and
> understandability of his paper could be improved via use of appropriate
> examples, was it truely "incumbent" upon the author to show such?  I think
> not. In all likelyhood for ANY such example, some clever C/C++ programmer
> could readily find a way in which the "unsafe" code could be coded "safely".

Why should any modern high-level language allow a programmer to code
something that will be "unsafe" or "dangerous".  Weren't the terse
grammar and compiler designed (in part) to prevent that?

Which of the more modern languages WILL allow "unsafe" or "dangerous"
code to be written, compiled and run?  Why is it allowed?  If there's
no way to prevent certain kinds of dangers, how can they be limited?

  Ada?
  C++?
  Modula-3?
  Eiffel?
  Smalltalk?
  (other)_____________?

Why is it allowed?

> Then the arguement quickly degrades into one over the example, not the
> point.  The point, which I infer you may have entirely missed (no disrespect
> intended), is whether or not the software industry in masse uses the safe or
> unsafe approach. Ada promotes many more safe constructs by disallowing as
> many unsafe constructs as possible.  (Comments continued after one of your
> examples).

Are you suggesting that if "safe" techniques are promoted (though not
enforced) then slang will never be spoken?

<snipped talk about bounds checking on arrays>
 
> One final comment.  I am an Ada advocate (Team Ada!).  However, no retract
> that "however", I am an advocate, period.  I have no illusions about Ada's 
> percentage of the market as compared/contrasted to C/C++ huge share.  
> Many individuals seem compelled to feel that technical considerations alone 
> should drive market share.  I find this thinking nonsensical.  Too many
> examples throughout history provide counterexamples (consider: how can a PC
> be a market leader when it's OS is all kludged around a 640Kbyte upper
> limit!). Thus, my comments are intended solely in the interest of generating
> worthwhile (hopefully) discussion.

Never OVER-estimate the American public.  They thought IBM meant "I'll Never
Be Fired if I buy it" and things went downhill from there.

"Why is it so hot in here and why am I in this handbasket?"  -- ?
"There's a sucker born every minute."  -- P. T. Barnum 


Mark S. Hathaway      <hathawa2@muvms6.mu.wvnet.edu>

An observation of Ada (may offend)

[R.A.L Williams]

In article <VLADIMIR.95Mar13204932> Vladimir Vukicevic wrote:

[well-deserved dismissal of student gripe deleted]

: Speaking of why people think Ada is not a good language... it'd be nice
: if someone collected the many myths about Ada, and collected them all
: together for distribution to the unbelievers. :-)  This would simplify
: telling people about Ada, especially if all they've heard was that it's
: a "big ugly ancient language used by the government", or that it's too
: 'huge' to be worth doing anything with.

Not 'myths' but 'gripes' - its a matter of perspective!

Some years ago I spent some time writing applications in Ada 83 (of
course, it was just 'Ada' then). I wrote both workstation and embedded
applications and I formulated a number of gripes about the language at
the time. I'm now (re-)learning Ada in its Ada95 form and I'm glad to
see that many of the gripes have been addressed.

Anyway, FWIW, here's a list (in no particular order). I'd be interested 
to see how many strike a chord with other people:

a. No unsigned integers (fixed in Ada95) HCTBAEL.

b. No bit level manipulation (fixed in Ada95 but only for unsigned
ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

c. Inflexible I/O - no unformatted binary files - this may
have been fixed in Ada95 but GNAT doesn't support STREAMs yet so
I haven't been able to play with it.

d. No pointers to functions - except for the 'ADDRESS attribute which,
being a chapter 13 item is at the whim of the compiler vendor (not very
portable). This is fixed in Ada95.

e. No short cut operators (+= etc.) -- sorry, we've had this debate
already in another thread, I've heard the objections, I still like the
operators.

f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
with a language like Ada, it makes me nervous with Eiffel and C++ as
well, but, so far, I haven't tried to use those languages in embedded
systems (got a C++ one coming up soon). Its not so much needing a
run-time system, its not knowing what's in it. This is largely a compiler
vendor issue, not a language issue. HCTBAEL

g. Task overhead for serialized data access. Fixed in Ada95 with
protected types I believe, that's one of the next things to play with.

h. And a special one for Ada95: poor encapsulation of objects. I can
define a 'member function' for a class by including the class in the
parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
other features of Ada go out of their way to force the programmer to
follow 'good practice' (sometimes a matter of opinion), this seems
very lax.

HCTBAEL = "How can this be an embedded language?" 

My experience with Ada, confirmed by many people that I spoke to at the
time was that, for embedded systems at least, Ada was used as cosmetic
window dressng to a vast quantity of assembler. This was made necessary
by the shortcomings of the language for addressing low level machine
interactions. To some extent, the same was also true of X11 software
on workstations. I see from responses in other threads that this may
have changed in recent years. All I can say is about time!

: 	-- Vladimir Vukicevicn
: 	-- vladimir@intrepid.com

Bill Williams
bill.williams@gec-mrc.co.uk

Re: An observation of Ada (may offend)

[Norman H. Cohen]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
(R.A.L Williams) writes: 

|> b. No bit level manipulation (fixed in Ada95 but only for unsigned
|> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

   function Sign_Bit (N: Integer) return Boolean is
   begin
      return N < 0;
   end Sign_Bit;

|> f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
|> with a language like Ada, it makes me nervous with Eiffel and C++ as
|> well, but, so far, I haven't tried to use those languages in embedded
|> systems (got a C++ one coming up soon). Its not so much needing a
|> run-time system, its not knowing what's in it. This is largely a compiler
|> vendor issue, not a language issue. HCTBAEL
...
|> HCTBAEL = "How can this be an embedded language?"

Pragma Restrictions, which must be supported (in different ways) to
conform to the real-time or safety-critical annexes, addresses this
concern in Ada 95.

|> h. And a special one for Ada95: poor encapsulation of objects. I can
|> define a 'member function' for a class by including the class in the
|> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
|> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
|> other features of Ada go out of their way to force the programmer to
|> follow 'good practice' (sometimes a matter of opinion), this seems
|> very lax.

You can do this in C++ and Eiffel too.  The only difference is
notational.  In C++, an operation Op invoked as Obj1.Op(Obj2) can only be
written inside Obj1's class, but an operation Op invoked as Op(Obj1,Obj2)
or Obj2.Op(Obj1) can be written elsewhere.  In Ada, the call would be
written as Op(Obj1,Obj2) in each case.  Whatis important is that in Ada,
C++, and Eiffel, an operation manipulating a private component/member/
feature of a type/class can only occur logically within the defining
unit.

The purpose of encapsulation is not to restrict who can be a client of a
class, but to restrict who can manipulate its internal representation.
For example, given a private type for queues, the internal representation
of a queue can only be manipulated by calling abstract operations such as
Enqueue and Dequeue.  Nonetheless, it is possible outside of the defining
package to write an Append operation, moving all the contents of one
queue to the end of the other, by calling Dequeue with the first queue as
a parameter and Enqueue with the second queue as a parameter.  This is
not a violation of encapsulation.

If there is a weakness in Ada encapsulation, it has nothing to do with
parameter lists, but with the definition of "logically within the
defining unit".  Anyone can write a child package that is "logically
within the defining unit".  (Do-While Jones once called this the "Howard
Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
access analogous to that permitted for C++ protected members in a
subclass of a definining class.  Thus the strongest degree of hiding that
Ada can provide is that of C++ "protected", not C++ "private".

One way to justify this is by thinking of the program library--er,
compilation environment--as a hypertext document with implicit links from
parent units to child units, reflecting the logical nesting of the child
units within the parent units.  Then writing a child unit is, in effect,
modifying the parent unit.  It is always possible in any language to
"break encapsulation" by modifying the defining unit!  Some development
environments may have access-control tools to restrict the ability to
modify certain units.  The proper extension of such tools to Ada 95 is
also to restrict the creation of children for such units.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kr20s$gqq@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

  > Regarding the suggestion:  pragma Restrictions(No_Unspecified_Child_Units)

  > Presumably the right form of this pragma is

  >   Pragma Child_UNits (unit, unit, unit);

  > with the meaning that only the named units would be allowed as children.
  > This is a perfectly legitimate pragma, and one that could be implemented.

    This actually is an improvement to my suggestion, and one I
recommend to all Ada implementors.  (In fact, if Robert Dewar doesn't
get around to adding it to GNAT, I may send it to him.)

    Of course, and the reason for posting this, is that one needed
form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
I perfer the second form, what do the rest of you think?

    I guess there is a third form--to deal with the special case of a
child unit named None, you might want to use a reserved keyword here.
How about "pragma Child_Units(NOT);"?

  > But I wonder about this whole concern. After all you can always go and
  > edit out the "abs" of Norm's abs private, or add to the list of child
  > units in the above pragma.

   The point is that the software maintainer can look at the source
file and know what child units exist, not that implementers are
forbidden to add them.  If most people agree with the suggested
syntax, I will start using pragma Child_Units without any compiler
support.  (And probably quickly add the support...)

  > The language can't do everything here!

   Right, this is and should be a voluntary annotation in most
environments.  But I expect that if support is forthcoming, the
safety critical people will not only use it, their coding standards
will insist on it.

--

					Robert I. Eachus

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

Re: An observation of Ada (may offend)

[Peter Hermann]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3kr20s$gqq@gnat.cs.nyu.edu> dewar@cs.nyu.edu writes:
: > Presumably the right form of this pragma is
: >   Pragma Child_UNits (unit, unit, unit);
: > with the meaning that only the named units would be allowed as children.
: > This is a perfectly legitimate pragma, and one that could be implemented.

:     This actually is an improvement to my suggestion, and one I
: recommend to all Ada implementors.  (In fact, if Robert Dewar doesn't
: get around to adding it to GNAT, I may send it to him.)

:     Of course, and the reason for posting this, is that one needed
: form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
: I perfer the second form, what do the rest of you think?

I would not recommend that whole direction because
one of the strengths of the child feature is exactly the fact,
that the parent need not be touched further on.
For Ada200X, the abs private part may be more convenient (if any)
but, imho, this overburdening of the language is superfluous.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Child packages

[Robb Nebbe]

In article <3ku7us$117l@info4.rus.uni-stuttgart.de>, ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
|> Robert I. Eachus (eachus@spectre.mitre.org) wrote:
...
|> :     Of course, and the reason for posting this, is that one needed
|> : form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
|> : I perfer the second form, what do the rest of you think?
|> 
|> I would not recommend that whole direction because
|> one of the strengths of the child feature is exactly the fact,
|> that the parent need not be touched further on.
|> For Ada200X, the abs private part may be more convenient (if any)
|> but, imho, this overburdening of the language is superfluous.

If you think of child packages as module extension then the logical place
to deal with issues like this is with other version control questions.

I don't see how something like who can add a child package is fundamentally
any different that who can modify a package. In my opinion a pragma
to deal with this situation would do more harm than good.

Robb Nebbe

Re: Child packages

[Keith Thompson]

In <1995Mar27.115304@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
> I don't see how something like who can add a child package is fundamentally
> any different that who can modify a package. In my opinion a pragma
> to deal with this situation would do more harm than good.

For a set of compilation units provided by a commercial vendor, the full
specification and body sources may not be available, making modification
difficult or impossible.  Adding a child unit is relatively easy.
(Some would argue that all the sources should always be made available,
but I don't think that assumption should be built into the language;
realistically, sources *won't* always be available.)

One advantage of such a pragma is that it gives users an ability that
currently only implementations have.  I think this has always been a
design goal of Ada.  (For example, unlike their equivalents in many
other languages, Character is an ordinary enumeration type and Text_IO
is an ordinary library package; users can write their own replacements
for them if desired.)

RM95-A(4) says

    The implementation may restrict the replacement of language-defined
    compilation units.  The implementation may restrict children of
    language-defined library units (other than Standard).

In a small way, this gives the language-defined units a special status.
An implementer of a set of non-language-defined units can have the
same reasons to impose such restrictions that an implementer of the
language-defined units might have.

On the other hand, the only real extra power a child unit gives you
is visibility to the parent's private part.  You can restrict this by
hiding implementation details within a *nested* private part (this is
based on something Tucker Taft briefly mentioned a while ago).

	package Black_Box is
	   type Hidden is private;
	private
	   package Inner_Black_Box is
	      type Inner_Hidden is private;
	   private
	      type Inner_Hidden is (Why_Are_You_Looking_At_Me);
	   end Inner_Black_Box;
	   type Hidden is new Inner_Black_Box.Inner_Hidden;
	end Black_Box;

Now even a private child of package Black_Box can't access the full
declaration of type Hidden.  Since child units can only be declared at
the library level, you can't declare a child of Inner_Black_Box, so its
private part is truly private.

Admittedly, this doesn't let you selectively export private types to
some units but not to others.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: Child packages

[Keith Thompson]

In <D64Lyo.ML9@thomsoft.com> I foolishly wrote:
[...]
> On the other hand, the only real extra power a child unit gives you
> is visibility to the parent's private part.
[...]

Of course, this isn't the only thing child units are good for.  If it
weren't so late at night, I'd come up with a better way to phrase that.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.