An observation of Ada (may offend)

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)

[Robb Nebbe]

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

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

...

|> 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.

It is trivial to write a generic package providing bit manipulation on
arbitrary integer types in Ada 83.

I would expect that it would usually be more appropriate to check if
a value was < 0 rather than checking the sign bit but I'll assume you
had a good reason.


|> 
|> 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.

If you declare a private type then the only place you can see the
implementation is from inside the package where the type is declared
(or a child package). You can declare subprograms that have parameters
of this type elsewhere but that certainly doesn't qualify as a 'member
function'.

The idea you are looking for is 'primitive operations' which a
explained in the LRM.

Robb Nebbe

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)

[S. Tucker Taft]

ncohen@watson.ibm.com (Norman H. Cohen) wrote:
>
> In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
> (R.A.L Williams) writes: 
>... 
> |> 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.
> ...
> 
> 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".

By putting a declaration in a nested package private part, or in
the package body, you achieve hiding as effective as C++ "private."  
When introducing Ada 95 to C++ programmers, I generally explain that
Ada has three levels of visibility control, analagous to the three in
C++ -- the visible part of a package (visible to all), the private
part of the package (visible to children), and the package body
(visible to the package body itself only).  Most C++ programmers
are a bit jealous of the ability to define in Ada 95 additional
local subprograms in a package body without having to disturb the
spec.  In C++, you have to edit the class spec to add private
member functions (or play games with "friends").
 
> Norman H. Cohen    ncohen@watson.ibm.com

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

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <3kcflv$164a@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes:


|> 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".

Hiding is an all or nothing proposition; either something is hidden or
it isn't there is no "sort of hidden".

Now you can differentiate the information hiding facilities of different
langauges based in granularity, flexability, simplicity etc. IMHO "Protected"
is a quirk of C++ stemming from the lack of orthogonality between modules
and types. In other words you wind up compensating for the simplicity of the
type=module approach by increasing the levels of visibility or adding
features like nested classes and friend functions.

It isn't at all clear that "protected" is desirable in a language.

In Ada you can use whatever amount of information hiding you want through
the various uses of packages and types. In general this can be accomplished
by using child packages to provide specialized interfaces and allowing the
client to choose what they need to see. In other languages the progammer
is often required to forsee all possible uses of the abstraction or resort
to complicated schemes using multiple inheritance to increase the
flexibility of the solution.

Robb Nebbe

Re: An observation of Ada (may offend)

[Robert Dewar]

Robb Nebbe says that hiding is all or nothing. That seems quite wrong. 
That's like saying a fence in real life is either not there or is 
impregnable.

A hidden interface in a language environment is exactly analogous to the
fence. But any fence can be knocked down if you have a bulldozer.

One bull-dozer in Ada is unchecked conversion, which definitely allows
you to blow away the hiding of anything, including private parts if you
know enough! In C++ it is even easier, because you can play with pointers
so easily.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kcflv$164a@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > 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.)...

    I prefer to call such a package a bastard child, and reserve the
more polite illegitimate child for cases where the parent package
specification acknowledges the possibility of unknown children.

    We debated this to great extent in Portsmouth, and I can
understand the consensus position.  But I wish that the ability to
acknowledge child units had been built into the language so that, for
example a pragma Restrictions(No_Unspecified_Child_Units); would make
sense.

--

					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)

[Norman H. Cohen]

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

|>                                     But I wish that the ability to
|> acknowledge child units had been built into the language so that, for
|> example a pragma Restrictions(No_Unspecified_Child_Units); would make
|> sense.

(-:  (-:  (-: 

At one point I suggested that a package be allowed to have an "absolutely
private" part, hidden even from children: 

   package P is
      ...
   abs private
      ...
   end P;

(I took the liberty of abbreviating "absolutely" to avoid the need for a
new reserved word.)  Somebody (sorry, can't remember who) did me one
better, suggesting the following syntax: 

   package P is
      ...
   private for all with out exception
      ...
   end P;

:-) :-) :-)

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

Re: An observation of Ada (may offend)

[David Weller]

In article <3knah2$p4m@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>In article <EACHUS.95Mar20111527@spectre.mitre.org>, eachus@spectre.mitre.org
>(Robert I. Eachus) writes: 
>|>                                     But I wish that the ability to
>|> acknowledge child units had been built into the language so that, for
>|> example a pragma Restrictions(No_Unspecified_Child_Units); would make
>|> sense.
>(-:  (-:  (-: 
>
>At one point I suggested that a package be allowed to have an "absolutely
>private" part, hidden even from children: 
>
>   package P is
>      ...
>   abs private
>      ...
>   end P;
>
>(I took the liberty of abbreviating "absolutely" to avoid the need for a
>new reserved word.)  Somebody (sorry, can't remember who) did me one
>better, suggesting the following syntax: 
>
>   package P is
>      ...
>   private for all with out exception
>      ...
>   end P;
>

Clever, but inelegant.  I always favored:

	package P is
	   ...
	private private
	   ...
	end P;

Of course, I've suggested MUCH worse things to the MRT :-)

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: An observation of Ada (may offend)

[Robert Dewar]

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.

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.

No no, you say, your configuration management tool prevents this kind
of improper editing of the source. OK, if this is the case, then how
about this wonderful tool also restrict what child units can be supplied.

THe language can't do everything here!

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)

Re: An observation of Ada (may offend)

[David Weller]

In article <3ku7us$117l@info4.rus.uni-stuttgart.de>,
Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>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.
>

Ah, but that's what pragmas are for, eh? :-)

The way I see it is you have three options:
1.  Anybody can extend your package
2.  Nobody can extend your package
3.  Specific "children" are permitted to extend your package

Option 1 is definitely supported in Ada95
Option 2 and 3 can be supported with Eachus' suggestion (giving a
"friend"-like pragma)

The fundamental issue is, however, can you thwart options 2 or 3?
Given the pragma Robert Eachus suggestied, the answser is "No" for
pragma Child_Units(None) and "yes" for Pragma Child_Units(..list..).
All I have to do for option 3 is create a child unit that has a
matching name.

It kinda leads me to conclude that perhaps just having a "pragma
No_Child_Units;" is the best thing to have.

Maybe this discussion should migrate to the MRT list?


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: An observation of Ada (may offend)

[Robert Dewar]

"Maybe this discussion [about pragma No_Child_Units] should migrate to the
MRT list"

I think definitely NOT, I would hate to see the MRT list cluttered up with
discussions of possible extensions etc. It should be reserved strictly for
discussing Ada 95 as it is.

It is incidentally quite easy to thwart pragma No_Child_Units; just edit
the line out of the source. As I noted in my original response, your
CM may prevent this, but if it is clever enough to do that, why can't
it be a little more clever and control fhild units.

Re: An observation of Ada (may offend)

[Tucker Taft]

Peter Hermann (ucaa2385@alpha1.csv.ica.uni-stuttgart.de) wrote:

[Various proposals relating to limiting the use of child units.]

: 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.

Here, here.

Child units are a namespace structuring mechanism.  A fundamental 
characteristic of this structuring mechanism is that the spec of the 
parent does not depend on the children.  Furthermore, if a child unit 
is not mentioned in some "with" clause, it is as though it doesn't 
exist at all, and will not be included in the program.  Hence, adding 
an "unwanted" child has no effect on any program that does not 
explicitly mention that child in some with clause.

Adding a child is simply extending the interface of the abstraction
represented by the tree of library units.  Without child units,
this is done by entering a new version of a package into a library
after adding more subprograms to the package.  With child units, you 
can accomplish the same thing by entering the new child into 
the library.  In both cases, if you want to control access
or update to the library, then you need to use the O/S or the Ada compiler
to do it.  

Access control is not a language issue, it is a tool or O/S issue.

Note that using child units is actually *safer* than the "old" approach
where one simply edited the package that represented the entire abstraction,
since as mentioned above, the only clients that can possibly be affected
are those that explicitly add a "with" clause for the new child.
With the "old" approach where someone goes in and adds or changes stuff
in the original package, it is much less obvious which clients might
be affected.

So a pragma that lists the names of child units is the moral equivalent
to a comment at the top of a package that lists the names of all of 
the subprograms in the package.  It proves nothing, and simply creates 
busy work during maintenance, since it must be updated every time
you want to add a new child (and don't tell me somehow that your tools can
prevent me from entering a new version for the parent package, but
they can't prevent me from adding a new child).  Some kinds of redundancy
are useful, but these kinds of redundant lists are a waste of energy.

If you want a list of the children, get a list from the program library
manager (a.k.a "list directory" on GNAT).  Similarly, if you want
a list of the subprograms in a package, use "grep."  If you want to
lock out unauthorized additions or changes to *your* program library, 
use "chmod" (or whatever).

This whole thing reminds me of attempts to add silly amendments
to the US constitution ;-).

: --
: 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)

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

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'.

Re: An observation of Ada (may offend)

[Mark A Biggar]

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:
>: 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.

I don't see any reason for any of the above stuff.  A Child Package
is pretty innocuous in that unless your code does a with of the 
Child somewhere it has zippo effect on your program.  It would seem
that inspections and a little CM disipline should take care of any
problems.  And if that's not good enough your program/project already
has worse problems than added Child Packages.

--
Mark Biggar
mab@wdl.lroal.com

Re: An observation of Ada (may offend)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:    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...
:    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.

As a safety-critical person, I don't have a problem with someone wanting this
pragma, but I wouldn't see us scrambling to add this to our coding standards,
either. My compiler, design tool, and CM tool all provide concise descriptions
of the structure of my application; I expect that the compiler, at least, will
continue to do so for Ada 95 and include package hierarchies in that
description.

I would be more concerned with the issue of having to modify the parent
package every time I add a child. Usually, our coding standards prohibit
references of this type, since (a) it adds cost and (b) the more items you
have to change, the greater the likelihood of inadvertantly inserting an
error.

Personally, I'm looking forward to being able to reuse more packages without
modifications. I think this will significantly improve safety (if we don't
break the compiler along the way! :)

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kv7g7$o7d@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

  > I would be more concerned with the issue of having to modify the
  > parent package every time I add a child. Usually, our coding
  > standards prohibit references of this type, since (a) it adds cost
  > and (b) the more items you have to change, the greater the
  > likelihood of inadvertantly inserting an error.

    As I said, what I like about this approach is that it allows you
to delay adding the pragmas until the appropriate point--sometime
between integration and FQT.  Before then, adding a child is a
detailed design decision, and the only major issue should be the need
to update the documentation.  After that point, you are in a
maintenance mode where the consequences of adding an "unanticipated"
child could be severe, and I certainly wouldn't permit it without a
through review.  Under most circumstances I can forsee, such an add-on
would walk like a kludge, and quack like a kludge.

    The major advantage of the pragma is to the maintainer.  Without
the pragma, a global search, or some documentation, he has no idea
what children are part of the unit he is maintaining.  This can save
days of maintenance time with little or no cost.


--

					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)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:     As I said, what I like about this approach is that it allows you
: to delay adding the pragmas until the appropriate point--sometime
: between integration and FQT.  Before then, adding a child is a
: detailed design decision, and the only major issue should be the need
: to update the documentation.  After that point, you are in a
: maintenance mode where the consequences of adding an "unanticipated"
: child could be severe, and I certainly wouldn't permit it without a
: through review.  Under most circumstances I can forsee, such an add-on
: would walk like a kludge, and quack like a kludge.

I actually have this wacky idea that we might be able to start reusing
packages from project to project without modification, in which case I may
want to add new child
packages well after FQT. I wouldn't call it a "kludge" -- just an ability
to add new features without having to rewrite half of the package every
time I want to change the available features!

:     The major advantage of the pragma is to the maintainer.  Without
: the pragma, a global search, or some documentation, he has no idea
: what children are part of the unit he is maintaining.  This can save
: days of maintenance time with little or no cost.

If the maintainer has no tools or documentation (in our case, he has both),
this issue is the least of his problems.

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

   I said (discussing source code changes during and after integration):

 > Under most circumstances I can forsee, such an add-on would walk
 > like a kludge, and quack like a kludge.

In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

 > I actually have this wacky idea that we might be able to start
 > reusing packages from project to project without modification, in
 > which case I may want to add new child packages well after FQT. I
 > wouldn't call it a "kludge" -- just an ability to add new features
 > without having to rewrite half of the package every time I want to
 > change the available features!

   First read what I wrote.  I can imagine cases where such a change
would be appropriate, especially during development and I said that.
I can also imagine adding a chiild unit in exactly those
circumstances.  (I can even imagine a "corporate programming standard"
which required all instantiations of generics nested in packages to be
child units of that package.--I don't encourage such a practice, but I
can imagine it. ;-) But I still believe that adding a child unit
during integration is likely to be a kludge.

   Now you just voluteered for the maintenance job, and it is hard to
get good maintainers, wonderful.  When you go to add your new child
unit, how do you know that it is not replacing another child of the
same name, which you were unaware of?  I, and many others, like the
documentation you need to be in the logical place--in the source.

 > If the maintainer has no tools or documentation (in our case, he has both),
 > this issue is the least of his problems.

    As anyone who has done software maintenance in the "real world"
can tell you, no tools and no (trustworthy) documenation is standard
practice outside the safety critical fields.  If they had good
documentation, they wouldn't have had to call you.

--

					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)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

:  > I actually have this wacky idea that we might be able to start
:  > reusing packages from project to project without modification, in
:  > which case I may want to add new child packages well after FQT. I
:  > wouldn't call it a "kludge" -- just an ability to add new features
:  > without having to rewrite half of the package every time I want to
:  > change the available features!

:    First read what I wrote.  I can imagine cases where such a change
: would be appropriate, especially during development and I said that.

I did. You said, "after integration, there's no purpose in adding this."
What if there is a follow-on project after integration? This would be
"after integration."

: But I still believe that adding a child unit
: during integration is likely to be a kludge.

Unless, of course, new requirements were received during integration, such
as a contract change proposal with a quick turnaround. Or a quick-turn
change requested by the flight test team.

:    Now you just voluteered for the maintenance job, and it is hard to
: get good maintainers, wonderful.

I didn't volunteer for the maintenance job -- quite the opposite (see below).
I volunteered to build our software in such a way that we can leverage off
of it for future programs. Isn't that what programming by extension is
supposed to do for us?

:  When you go to add your new child
: unit, how do you know that it is not replacing another child of the
: same name, which you were unaware of?

The same way I know that I am not adding a package body for a spec which
already has a package body, or should not have a package body -- I have a CM
system.

Again, if you want to use this pragma, be my guest. I wouldn't say that
it would be widely used in the safety-critical field, as was originally
stated, because safety-critical software (like other kinds of software)
has tools and processes to control changes to our software.

  I, and many others, like the
: documentation you need to be in the logical place--in the source.

We, on the other hand, work with the eventual maintainers, who tell us that
they want program structure to be documented in a clean, summary form a la
ADARTS -- not by crunching through the source.

:  > If the maintainer has no tools or documentation (in our case, he has both),
:  > this issue is the least of his problems.

:     As anyone who has done software maintenance in the "real world"
: can tell you, no tools and no (trustworthy) documenation is standard
: practice outside the safety critical fields.  If they had good
: documentation, they wouldn't have had to call you.

The maintainers for F-22 software get the same tools we use (safety critical
and otherwise) along with the data. It's required by our contract.

And no, we don't expect them to call us. We plan for organic support. We
do, however, expect to bid (and hopefully win) new programs. We would like
to use the software from the last program on these new programs. Maybe even
without modifying it.

For that matter, in another life, I did software maintenance of COBOL (eeek!)
for a chemical company. We had tools and documentation. This may not be
true everywhere, but I at least _thought_ I was in the real world. I got
paid real money, at least :)

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <EACHUS.95Mar28143036@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
|> 
|>    Now you just voluteered for the maintenance job, and it is hard to
|> get good maintainers, wonderful.  When you go to add your new child
|> unit, how do you know that it is not replacing another child of the
|> same name, which you were unaware of?  I, and many others, like the
|> documentation you need to be in the logical place--in the source.

This still sounds like a version control problem rather than a language
problem. I would hope that version control systems for Ada will be able
to enforce things like requiring child packages to be in the same
library as the parent.

Robb Nebbe

Re: An observation of Ada (may offend)

[Robert Dewar]

Robert, pragma Child_Units (not) indeed!

where did your syntax rules for Ada go? this really won't do at all :-)

what do others think of the pragma Child_Units, I think I would actually
have:

  pragma No_Child_Units;

for the completely restrictive case, since pragma Child_Units; with no 
argument is not very communicative, and pragma Child_Units (not) is, as
pointed out above, unacceptable.

For those who did not see the original post, the exact proposal is now
as follows:

   Any package spec may contain one occurrence of either of the following
   pragmas (but not both!)

   pragma No_Child_Units;
   --  Any attempt to compile a child unit is rejected

   pragma Child_Units (name, name, name ...)

   --  Only the given child units can be compiled

Re: An observation of Ada (may offend)

[R_Tim_Coslet]

>For those who did not see the original post, the exact proposal is now
>as follows:
>
>   Any package spec may contain one occurrence of either of the following
>   pragmas (but not both!)
>
>   pragma No_Child_Units;
>   --  Any attempt to compile a child unit is rejected
>
>   pragma Child_Units (name, name, name ...)
>
>   --  Only the given child units can be compiled

Why not:

    pragma No_Children;
    pragma Children(name, name, name ...)

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena 

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <135736@cup.portal.com> R_Tim_Coslet@cup.portal.com writes:

 > Why not:

 >      pragma No_Children;
 >      pragma Children(name, name, name ...)

   I hereby second the motion!

   (Although I have to wonder if maybe pragma Celibate; and pragma
Offspring(name, name, name...); should be considered. ;-)

   
--

					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)

[celier]

>   pragma No_Child_Units;
>  --  Any attempt to compile a child unit is rejected

Why not simply use pragma Restrictions:

   pragma Resptictions (No_Child_Units);
   --  Any attempt to compile a child unit is rejected

Vincent Celier
celier@infomatch.com

Re: An observation of Ada (may offend)

[Robert Dewar]

I don't much like pragma Restrictions (No_Child_Units), since this is a
configuration pragma, and the idea of restricting child units completely
is not what this is about, yes, I know that such a pragma can be applied
to one unit, but I still don't like it!

Re: An observation of Ada (may offend)

[John DiCamillo]

ncohen@watson.ibm.com (Norman H. Cohen) writes:
>(-:  (-:  (-: 

>At one point I suggested that a package be allowed to have an "absolutely
>private" part, hidden even from children: 

>   package P is
>      ...
>   abs private
>      ...
>   end P;

>(I took the liberty of abbreviating "absolutely" to avoid the need for a
>new reserved word.)

If you really wanted to confuse the parser, how about:

   package P is
      ...
   real private
      ...
   end P;

Too bad "real" isn't a reserved word...

>:-) :-) :-)

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

Re: An observation of Ada (may offend)

[Larry Kilgallen, LJK Software]

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.

Well some of us don't have Ada95 scheduled for our platforms...
...but I find that when I need to manipulate bits it is specific bit
fields rather than generic bit-algebras :-).  Representation clauses
in Ada are marvelous (although I have used similar capabilities from
other languages which don't happen to be codified in their standards).

> 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.

I disagree, perhaps for a reason which has not been stated.  The 26 letters
and the space bar are about all that I can touch-type.  Entering any
punctuation requires looking at the keyboard, so I prefer long-cut
operators.

Larry Kilgallen

Re: An observation of Ada (may offend)

[Tucker Taft]

R.A.L Williams (bill@valiant.gmrc.gecm.com) wrote:

: 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.

What are called "methods" in some OOPs are called "primitive 
operations" or "dispatching operations" in Ada 95.  These 
may be defined *only* immediately within the same package
spec as the type.  (If a type extension is declared in a package body or
declarative part, you can override inherited primtive ops there -- and
only there -- for that typ extension, but you can't define any new ones.)

So I don't think Ada 95 suffers from the above problem.  Perhaps
you were referring to something else, but I can't quite imagine what
problem it would be.  An example might help.  We certainly never meant
for Ada 95 to be "lax" ;-).

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

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

Re: An observation of Ada (may offend)

[Renaud HEBERT]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:
|> 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!
|> 
[things cut]

|> 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.

Could someone summarize the objections against short cut operators, because
I think that they are great and I 'm quite surprise that they don't exist in
Ada. No need to start a flamewar, I suppose that as with many construct there
are pros and cons. It's just that I can't see why those operators could be bad.


-- 
Renaud HEBERT		e-mail: Renaud.Hebert@prism.uvsq.fr

Re: An observation of Ada (may offend)

[John Volan]

hebert@prism.uvsq.fr (Renaud HEBERT) writes:

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

>Could someone summarize the objections against short cut operators, because
>I think that they are great and I 'm quite surprise that they don't exist in
>Ada. No need to start a flamewar, I suppose that as with many construct there
>are pros and cons. It's just that I can't see why those operators could be bad.

There's nothing wrong with the notion of short-cut arithmetic
*procedures*.  It's the idea of short-cut arithmetic *operators* that's
the problem.  

I think it would be quite nice if Ada included some built-in
procedures that provided short-cut arithmetic.  Perhaps these could be
in the form of attributes: For every numeric type T, we'd have
attribute procedures such as:

  procedure T'Increment (What : in out T);            -- analogous to ++ in C
  procedure T'Decrement (What : in out T);            -- analogous to -- in C
  procedure T'Increment (What : in out T; By : in T); -- analogous to += in C
  procedure T'Decrement (What : in out T; By : in T); -- analogous to -= in C
  procedure T'Multiply  (What : in out T; By : in T); -- analogous to *= in C
  procedure T'Divide    (What : in out T; By : in T); -- analogous to /= in C

Barring that, it wouldn't be too hard to "roll your own" solution by
writing reusable generic templates for these subprograms.

But to make these into *operators* would entail some difficulties for Ada:

(1) Operators (at least in Ada terms) are functions; they are
subprograms that return a result.  But the point to these short-cut
arithmetic routines is to cause a side-effect on one of their
parameters.  Having a function that causes a side-effect is somewhat
against Ada's design "philosophy".

(2) IMHO, the whole notion of a return value from this kind of
subprogram is totally extraneous anyway.  The whole point of such a
subprogram is, after all, to cause that side-effect, so the idea of an
incidental return value just adds an unnecessary complication.
Witness the contortions C++ gets into due to the subtle difference
between pre-increment ( ++x ), which returns the value of x *after*
incrementing it, versus post-increment ( x++ ), which returns the value of
x *before* incrementing it.

(In fact, this leads me to pose a question: What is the value of C++?
Does it really provide an *improvement* on C, or does it just yield the
*same* *result*?  Maybe they should have called it ++C instead!!!)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

(3) Operators are special symbols, with special syntax (infix, prefix,
postfix), and special semantics (precedence levels).  The syntax and
semantics of the operators we all learned in grade school ( + - * / )
were hard enough to master.  Why gratuitously invent new ones, when you
can do the same job using ordinary subprogram syntax and semantics?
(See my proposed attribute procedures above.)  The only benefit of
short-hand operator symbols is that they make it more convenient for
someone to *write* code -- at the cost of *readability*.  The
philosophy behind the design of Ada was to optimize for readability,
even at the expense of writability, on the assumption that more time
will be spent trying to read and understand Ada code than to write it.

				-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: An observation of Ada (may offend)

[Robert Dewar]

Regarding +:= operators etc, the best thing is to find an archive of CLA
and read the long thread on this subject from earlier this year.

An observation of Ada (may offend)

[R.A.L Williams]

In article <1995Mar28.120720.9512@eisner> Larry Kilgallen wrote:
  [deleted up to where I wrote...]
: > I agree that the representation clauses defined in the LRM are splendid,
: > the problem is that they are *optional*. I don't know what the situation
: > is now, but when I last did a lot of work in Ada many compilers had only
: > a fragmentary coverage. 

: Well, since the compiler _I_ use has them, who cares about the rest of
: you :-) :-) :-).

: Actually, if implementation of representation clauses was specified as
: optional (I cannot find that statement), the Ada83 author(s) presumably

LRM section 13.1 para 10:
"... An implementation may limit its acceptance of representation clauses
to those that can be handled simply by the underlying hardware. ..."

Now, in the old days, many compiler vendors treated this as a general cop-out.
I haven't bought an Ada compiler recently, so I don't know if this is still
the situation.

: felt they were hard to accomplishment and would require market pressure
: to cause implementation.  At least (unlike Pascal) the syntax for adding
: them is _standardized_, so once you have convinced your vendor, the
: implementation they provide will be compatible.

Yes, Pascal doesn't even have a *usable* standard. Every compiler I've come
across has vast numbers of incompatible extensions, little things like
separate compilation etc. (!)

ANSI C is standardized, but the standard is not explicit on the order
of bit fields within a structure.

The only ambiguity I know of in the Ada83 LRM is section 13.4, para 5, where
it says "...The first bit of a storage unit is numbered zero...." without
saying whether this is the MSB or the LSB (the same also goes for storage
units in a word of course).

: > Most of the time, as you say, bit fields are adequate, but how would you
: > implement ECC algorithms or maximal length sequence generators for instance?

: Larry Kilgallen

Bill Williams

Re: An observation of Ada (may offend)

[Norman H. Cohen]

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

|> LRM section 13.1 para 10: 
|> "... An implementation may limit its acceptance of representation clauses
|> to those that can be handled simply by the underlying hardware. ..."
|>
|> Now, in the old days, many compiler vendors treated this as a general cop-out.
|> I haven't bought an Ada compiler recently, so I don't know if this is still
|> the situation.

No, market pressure greatly improved the situation with Ada-83 compilers
several years ago.

The language you quoted is gone from the Ada-95 RM.  Instead, we have
RM95 13.1(20): 

   A _recommended_level_of_support_ is specified for representation items
   and related features in each subclause.  These recommendations are
   changed to requirements for implementations that support the Systems
   Programming Annex....

The Systems Programming Annex states (RM95 C.2(2)): 

   The implementation shall support at least the functionality defined by
   the recommended levels of support in Section 13.

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

An observation of Ada (may offend)

[R.A.L Williams]

In article <1995Mar17.144930@lglsun.epfl.ch> Robb Nebbe wrote:
: 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.

: It is trivial to write a generic package providing bit manipulation on
: arbitrary integer types in Ada 83.

What do you mean? 

One approach is to hack something together, ie. shift implemented as 
multiply/divide, and implemented as something very complex involving 
subtraction etc. (unpleasant)

The other approach is to define BIT a derived type of INTEGER, WORD
as an array of BIT's and use a representation clause to try to force 
this down to one bit per 'bit'.  The trouble with this is that there 
is no natural coversion to/from integer. Another problem may be that 
not all compilers (at least the last time I used Ada 83) actually 
*implement* representation clauses. They're all meant to check them
syntactically, but this is an implementation dependent feature.

Have I forgotten something? Is there another approach?

: I would expect that it would usually be more appropriate to check if
: a value was < 0 rather than checking the sign bit but I'll assume you
: had a good reason.

No, that was just an example - I don't dee many situations where I'd do that.

: |> 
: |> 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.

: If you declare a private type then the only place you can see the
: implementation is from inside the package where the type is declared
: (or a child package). You can declare subprograms that have parameters
: of this type elsewhere but that certainly doesn't qualify as a 'member
: function'.

: The idea you are looking for is 'primitive operations' which a
: explained in the LRM.

Yes, mea culpa. I got this entirely wrong. I must RTFM before activating
fingers in the future!

: Robb Nebbe


Bill Williams

An observation of Ada (may offend)

[R.A.L Williams]

In article <D5Mz8J.AHB@inmet.camb.inmet.com> Tucker Taft wrote:
: R.A.L Williams (bill@valiant.gmrc.gecm.com) wrote:

: : 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.

: What are called "methods" in some OOPs are called "primitive 
: operations" or "dispatching operations" in Ada 95.  These 
: may be defined *only* immediately within the same package
: spec as the type.  (If a type extension is declared in a package body or
: declarative part, you can override inherited primtive ops there -- and
: only there -- for that typ extension, but you can't define any new ones.)

: So I don't think Ada 95 suffers from the above problem.  Perhaps
: you were referring to something else, but I can't quite imagine what
: problem it would be.  An example might help.  We certainly never meant
: for Ada 95 to be "lax" ;-).

No, that's what I was referring to. All I can do is apologise for activating
fingers without previously engaging brain. I hadn't spotted that in the LRM
and I never tried to do anything differently because, well, its not nice!

The sooner someone comes out with a really good text book for Ada 95 so
I can stop making boo-boos like this the better!

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

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

Re: An observation of Ada (may offend)

[Michael D. Griffin]

In article <3l64jr$308@miranda.gmrc.gecm.com> R.A.L Williams,
bill@valiant.gmrc.gecm.com writes:
>The sooner someone comes out with a really good text book for Ada 95 so
>I can stop making boo-boos like this the better!

Shall we all gang up and beg JPG Barnes for a fifth edition?

Griff

Re: An observation of Ada (may offend)

[David Weller]

In article <3ld7mh$kce@calvino.alaska.net>,
Michael D. Griffin  <griffin@acm.org> wrote:
>In article <3l64jr$308@miranda.gmrc.gecm.com> R.A.L Williams,
>bill@valiant.gmrc.gecm.com writes:
>>The sooner someone comes out with a really good text book for Ada 95 so
>>I can stop making boo-boos like this the better!
>
>Shall we all gang up and beg JPG Barnes for a fifth edition?
>

Too late!  It's on the way already! :-)


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: An observation of Ada (may offend)

[Jack Beidler]

In article <3ld7mh$kce@calvino.alaska.net>, Michael D. Griffin <griffin@acm.org> writes:
|> In article <3l64jr$308@miranda.gmrc.gecm.com> R.A.L Williams,
|> bill@valiant.gmrc.gecm.com writes:
|> >The sooner someone comes out with a really good text book for Ada 95 so
|> >I can stop making boo-boos like this the better!
|> 
|> Shall we all gang up and beg JPG Barnes for a fifth edition?
|> 
|> Griff

If I read the flier at ANCOST Correctly, Cohen's Ada95 version of
"Ada as a Second Language" is not due until SPRING 1996!!!!
Too Late?

Re: An observation of Ada (may offend)

[Brian Rogoff]

beidler@guinness.cs.uofs.edu (Jack Beidler) writes:
   Michael D. Griffin <griffin@acm.org> writes:
   |> In article <3l64jr$308@miranda.gmrc.gecm.com> R.A.L Williams,
   |> bill@valiant.gmrc.gecm.com writes:
   |> >The sooner someone comes out with a really good text book for Ada 95 so
   |> >I can stop making boo-boos like this the better!
   |> 
   |> Shall we all gang up and beg JPG Barnes for a fifth edition?
   |> 
   |> Griff

   If I read the flier at ANCOST Correctly, Cohen's Ada95 version of
   "Ada as a Second Language" is not due until SPRING 1996!!!!
   Too Late?

I've seen a book called "Rendezvous with Ada 95" at a few bookstores 
around the area. A quick check of the Stanford bookstore yields

Stanford Bookstore / Search: Find TITLE ADA and TITLE 95
Result: 1 citation

1) Naiditch, RENDEZVOUS WITH ADA 95 2/ED. Wiley, John & Sons, Inc., 1994.
   LOCATION: Campus, General Books (Ada Programming Language) - May be in 
             stock.
             Technical-Professional Branch, 135 University Ave. (Ada 
             Programming Language) - May be in stock.

Anybody care to comment on this one?

-- Brian

An observation of Ada (may offend)

[R.A.L Williams]

In article <1995Mar17.180137.9394@eisner> Larry Kilgallen wrote:
: 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.

: Well some of us don't have Ada95 scheduled for our platforms...
: ...but I find that when I need to manipulate bits it is specific bit
: fields rather than generic bit-algebras :-).  Representation clauses
: in Ada are marvelous (although I have used similar capabilities from
: other languages which don't happen to be codified in their standards).

I agree that the representation clauses defined in the LRM are splendid,
the problem is that they are *optional*. I don't know what the situation
is now, but when I last did a lot of work in Ada many compilers had only
a fragmentary coverage. 

Most of the time, as you say, bit fields are adequate, but how would you
implement ECC alogorithms or maximal length sequence generators for instance?
So far as standards are concerned, I believe that bit fields are codified
in the ANSI C standard, and every ANSI C compiler I've used actually does
implement them.

: > 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.

: I disagree, perhaps for a reason which has not been stated.  The 26 letters
: and the space bar are about all that I can touch-type.  Entering any
: punctuation requires looking at the keyboard, so I prefer long-cut
: operators.

Well, OK, but

  variable := variable + offset;

is 9 characters (not counting spaces for readability) longer than

  variable += offset;

I would also submit that, at least when the l-value gets more complex,
ie. array/structure dereference etc., that the short cut version is more
readable. For a simple statement like the example above there's no real
difference in readability. For my money, readability is the prime
criterion. I work on jobs where code inspection is often the most
cost-effective method of reducing test and integration costs. There is
also a benefit in long term maintenance.

: Larry Kilgallen

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

Re: An observation of Ada (may offend)

[Norman H. Cohen]

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

|> I agree that the representation clauses defined in the LRM are splendid,
|> the problem is that they are *optional*. I don't know what the situation
|> is now, but when I last did a lot of work in Ada many compilers had only
|> a fragmentary coverage.

That is no longer the case.  In response to market forces, Ada compilers
have provided genuine support for record-representation clauses for many
years now.

In Ada 95, a compiler cannot claim conformance to the Systems Programming
Annex (and thus not to the Real-Time Systems annex) unless it supports
record-representation clauses.

|> Most of the time, as you say, bit fields are adequate, but how would you
|> implement ECC alogorithms or maximal length sequence generators for instance?
|> So far as standards are concerned, I believe that bit fields are codified
|> in the ANSI C standard, and every ANSI C compiler I've used actually does
|> implement them.

Yes, ANSI compilers must recognize bit-field declarations, but the ANSI C
standard imposes very few constraints on what the compiler is to do with
them.  In contrast, the Ada-83 rules (at least as interpreted by early
implementors) provided some leeway to reject a record-representation
clause, but an accepted record-representation clause provides an
unambiguous bit-by-bit specification of the intended layout.

It is easy to write Ada-83 record-representation clauses that produce
exactly the same layout for all compilers for, say, 32-bit big-endian
machines.  The Ada-95 pragma Bit_Order even makes it possible to write
clauses that are guaranteed to produce the same bit layout of a record on
all 32-bit machines (big-endian or little-endian).  (Of course you have
to decide what you mean by "the same" on big-endian and little-endian
machines, but whatever you decide, a record-representation clause can be
written to achieve it.)

ANSI C simply says that bit fields are packed as tightly as possible, in
order of declaration, into successive "units" with increasing addresses.
The ANSI C standard explicitly leaves all of the following unspecified: 

   - the size of the unit
   - the direction in which members packed into a single unit are laid
     out in that unit
   - whether a member that does not fit entirely in the current unit
     spans units or begins a new unit.  (A bit field of length zero
     forces a new unit to start, but there is no way to enforce spanning
     of units.)

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

Re: An observation of Ada (may offend)

[Robert Dewar]

Norm writes:

this [record representation clauses being optional] is no longer the case

that's misleading, record representation clauses were always required in
Ada 83. It is true that for a long time the ACVC suite did not enforce
this, but the standard required them. It permitted their omission only
for cases where there was no simple mapping to the macihine, since this
was never true for simple record rep clauses, this did not apply, and
they were 100% required.

In a sense, Ada 95 relaxes this, since the core does not require that
they be implemented.

Re: An observation of Ada (may offend)

[Larry Kilgallen, LJK Software]

In article <3l640c$308@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:
> In article <1995Mar17.180137.9394@eisner> Larry Kilgallen wrote:
> : 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.
>
> : Well some of us don't have Ada95 scheduled for our platforms...
> : ...but I find that when I need to manipulate bits it is specific bit
> : fields rather than generic bit-algebras :-).  Representation clauses
> : in Ada are marvelous (although I have used similar capabilities from
> : other languages which don't happen to be codified in their standards).
>
> I agree that the representation clauses defined in the LRM are splendid,
> the problem is that they are *optional*. I don't know what the situation
> is now, but when I last did a lot of work in Ada many compilers had only
> a fragmentary coverage.

Well, since the compiler _I_ use has them, who cares about the rest of
you :-) :-) :-).

Actually, if implementation of representation clauses was specified as
optional (I cannot find that statement), the Ada83 author(s) presumably
felt they were hard to accomplishment and would require market pressure
to cause implementation.  At least (unlike Pascal) the syntax for adding
them is _standardized_, so once you have convinced your vendor, the
implementation they provide will be compatible.

> Most of the time, as you say, bit fields are adequate, but how would you
> implement ECC alogorithms or maximal length sequence generators for instance?

Ah, that's just it.  I don't know enough to work on such problems :-).

Larry Kilgallen

An observation of Ada (may offend)

[Matt Bruce]

Hi,

Is it my imagination, or is Ada the demonic lovechild of C and Pascal?

I've had to study Ada this semester for a unit at my Uni called Advanced
Programming Techniques. What fun. Not. :) Learning techniques AND a new
language - what an experience - considering I'm learning COBOL and SQL
this semester.

Enough of my griping. Back to the assignments...

-----------------------------------------------------------
Matt Bruce     st952adf@pilot.stu.cowan.edu.au  (preferred)
"Even with an IQ of 6,000, it's still brown trousers time."

--------
For information about this Usenet posting service, send mail to
remailer@soda.berkeley.edu, with Subject: remailer-info.
Please, don't throw knives.

Re: An observation of Ada (may offend)

[David Weller]

In article <3k00no$8qv@agate.berkeley.edu>,
Matt Bruce  <st952adf@pilot.stu.cowan.edu.au> wrote:
>
>Is it my imagination, or is Ada the demonic lovechild of C and Pascal?
>
That's the first time I've headr _that_ suggestion! :-)

Well, I'd rather liken it to an _angelic_ lovechild of C++ and
Pascal, with it's own (real-time) personality thrown in. :-)

>Programming Techniques. What fun. Not. :) Learning techniques AND a new
>language - what an experience - considering I'm learning COBOL and SQL
							  ^^^^^^^^^^^^^
>this semester.
>

I think I've located the source of your frustration :-)


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: An observation of Ada (may offend)

[Vladimir Vukicevic]

In article <3k00no$8qv@agate.berkeley.edu> Matt Bruce <st952adf@pilot.stu.cowan.edu.au> writes:

> Is it my imagination, or is Ada the demonic lovechild of C and Pascal?

Most likely your imagination. You need more sleep.

> I've had to study Ada this semester for a unit at my Uni called Advanced
> Programming Techniques. What fun. Not. :) Learning techniques AND a new
> language - what an experience - considering I'm learning COBOL and SQL
> this semester.
> 
> Enough of my griping. Back to the assignments...

Interesting. When I saw the subject, I was prepared for an in-depth
summary of why someone thinks Ada is not a 'good' (however you define
'good') language.  Unfortunately, it is nothing of the sort.  I'm
waiting for one of those. :-)  Also, having to learn COBOL and SQL
in the same semester with Ada might give Ada a sour taste, especially
if your prof can't make it appealing. (Not saying that you have
a bad prof, just generalizing. :-)

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.

	-- Vladimir Vukicevicn
	-- vladimir@intrepid.com

Re: An observation of Ada (may offend)

[Michael Feldman]

In article <VLADIMIR.95Mar13204932@speedy.intrepid.com>,
Vladimir Vukicevic <vladimir@speedy.intrepid.com> wrote:

>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.

Here's a contribution:

MYTH: "Ada is used only by the U.S. Department of Defense"

RESPONSE: Here's a list I'm just getting started with, of application
  domains and lists of projects in which Ada is present in at least
  substantial amounts of code, if not exclusively. That a project is
  not _all_ Ada is a commentary on our increasingly mature view of
  reuse and mixed-language programming. Feel free to add to or correct
  my enumeration. I want the data to be up to date and verified.
  At some point I will put this in better format, including html.

Air Traffic Control Systems, by country

Australia
Belgium
Brazil
Canada
China
Czech Republic
Denmark
Finland
France
Germany
Greece
Hong Kong
Hungary
India
Ireland
Kenya
Netherlands
New Zealand
Pakistan
Scotland
South Africa
Spain
Sweden
United Kingdom
United States
Vietnam


Banking and Financial Networks

Reuters
Swiss Postbank Electronic Funds Transfer system

Commercial Aircraft

Airbus 330
Airbus 340
Beechjet 400A (US business jet)
Beech Starship I (US business jet)
Beriev BE-200 (Russian forest fire patrol)
Boeing 737-200, -400, -500, -600, -700, -800
Boeing 747-400
Boeing 757
Boeing 767
Boeing 777
Canadair Regional Jet
Embraer CBA-123 and CBA-145 (Brazilian-made regional airliners)
Fokker F-100 (Dutch DC-9-size airliner)
Ilyushin 96M (Russian jetliner)
McDonnell Douglas MD-11 (new model DC10)
Saab 2000
Tupolev TU-204 (Russian jetliner)


Communication and Navigational Satellites

Cassini
EOS - NASA's Earth Observing System
Goes
INMARSAT - voice and data communications to ships and mobile communications
Intelsat VII
NSTAR (Nippon Telephone and Telegraph)
PanAmSat (South American Intelsat-like consortium)
RadarSat (Canada)
United States Coast Guard Differential Global Positioning System

Railway Transportation

Cairo Metro
Calcutta Metro
Caracas Metro
Channel Tunnel
Conrail (major U.S. railway company)
French High-Speed Rail (TGV)
French National Railways
Hong Kong Suburban Rail
London Underground
Paris Metro
Paris Suburban Rail

Television Industry

Canal+ (French pay-per-view TV, remote cable box control software)

Re: An observation of Ada (may offend)

[Fred J. McCall]

In article <3kcf82$ln3@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>In article <VLADIMIR.95Mar13204932@speedy.intrepid.com>,
>Vladimir Vukicevic <vladimir@speedy.intrepid.com> wrote:

>>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.

>Here's a contribution:

>MYTH: "Ada is used only by the U.S. Department of Defense"

>RESPONSE: Here's a list I'm just getting started with, of application
>  domains and lists of projects in which Ada is present in at least
>  substantial amounts of code, if not exclusively. 

I'm curious; how many of the things on the list are not government related or 
regulated?  Is it significantly easier, for example, to get the government to 
sign off on aircraft software in part because it happens to be written in Ada 
(irrespective of the actual implementation or of the merits of the language)?  
That and the few banking applications would seem to me to be the only ones on 
your list not run by governments.

Non-myth -- virtually all Ada software is produced for governmetn agencies?

> That a project is
>  not _all_ Ada is a commentary on our increasingly mature view of
>  reuse and mixed-language programming. 

Now if only we could convince the United States Congress of that.

>Air Traffic Control Systems, by country

Pretty much government, no?

>Communication and Navigational Satellites

Again, pretty much government, no?

>Railway Transportation

Again?

>Television Industry

>Canal+ (French pay-per-view TV, remote cable box control software)

I have no idea of the status of the French television industry.  Government 
run or no?

Re: An observation of Ada (may offend)

[Michael Feldman]

In article <fjm.63.000D29AE@ti.com>, Fred J. McCall <fjm@ti.com> wrote:
>In article <3kcf82$ln3@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

>I'm curious; how many of the things on the list are not government related or 
>regulated?  Is it significantly easier, for example, to get the government to 
>sign off on aircraft software in part because it happens to be written in Ada 
>(irrespective of the actual implementation or of the merits of the language)?  
>That and the few banking applications would seem to me to be the only ones on 
>your list not run by governments.

It is true for many, if not most, of these domains that the government of
one country or another is involved. Railways and transit systems, for
example, are - outside the US - government-owned or -related. From all
I can tell from the various articles and tips I've read ofer the years,
in no case was Ada _mandated_. 

Thomson CSF, for example, which builds a large number of the ATC systems, 
is on the record as saying that the governments did not mandate Ada, and 
also that Thomson, and their competitors (Hughes, Loral, Siemens) pretty
much agree that Ada is the only way to go. 

I have never seen any indication in writing that Ada, _per se_ has won 
a contract for any of the projects in this list, and I don't think I've
ever heard anything to that effect "off the record" either.
>
>Non-myth -- virtually all Ada software is produced for governmetn agencies?

Oversimplification. It is true for many of the projects listed here, except 
for the airliners and the French cable TV project, which is a private (I 
think), pay-per-view cable network. Also, Nippon Telephone and Telegraph, which
appears under "satellites" is (said to be) one of the largest Ada users 
in the world, and I don't think they are a Japanese government company.

I have heard a number of rumors of large Ada projects in the baking industry
of a number of companies; I don't put anything down in these lists unless
I can verify the information reasonably well.  Government-sponsored
projects are, world-wide apparently, more "open" than commercial ones.
>
>> That a project is
>>  not _all_ Ada is a commentary on our increasingly mature view of
>>  reuse and mixed-language programming. 
>
>Now if only we could convince the United States Congress of that.

You and I both know that the so-called "mandate" has some very large 
loopholes in it. Let's save that discussion for another discussion.:-)
>
>>Air Traffic Control Systems, by country
>
>Pretty much government, no?

Yep.
>
>>Communication and Navigational Satellites
>
>Again, pretty much government, no?

Not sure. NT&T is not government, AFAIK.
>
>>Railway Transportation
>
>Again?

If the Texas financiers had succeeded in putting the TGV project together
for the Dallas/Austin/San Antonio/Houston network, it would have been in
private hands, using TGV technology, which (probably) means Ada software.
>
>>Television Industry
>
>>Canal+ (French pay-per-view TV, remote cable box control software)
>
>I have no idea of the status of the French television industry.  Government 
>run or no?

As is often the case in Europe, the government is both into and not into
nearly everything. I think Canal+ is private though, like HBO.

Bottom line: if your point is that only governments care about Ada,
I think (but have no way to prove) that you are really reaching. All
those European projects are built by (mostly) private-sector companies;
as far as I know, the coding language never entered into the contract
process.

I would dearly love to have verifiable information on more of the
banking-industry stuff. There are also rumors of auto industry projects.
These industries are very competitive and therefore secretive. They are
also quite paranoid about security.:-) 

The defense industry has tended to be more open than the private sector.
n discussing stuff like this.

Mike Feldman

Re: An observation of Ada (may offend)

[Robert Dewar]

Isn't the channel tunnel signalling system in Ada? That certainly is not
a government project (the government holds an equity stake, but so do lots
of other people, in the private company that is digging and running the
thing!)

Actually it is not so surprising that many (but certainly not all) of the
Ada projects are govt related. First, high integrity large systems are
likely to be govt related (not too many companies are in the space
business for instance!!) Second, you are of course more likely to know
about the govt related projects.

There are certainly many examples of non-govt related Ada projects (Boeing
commercial is an obvious example). Earlier this week, I was at a meeting
at Praxis, who makes a tool, SPARC Examiner, used in the creation of
high integrity Ada code. They reported that more than half their customers
are commercial customers.

Re: An observation of Ada (may offend)

[Michael Feldman]

In article <3kiani$i49@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Isn't the channel tunnel signalling system in Ada? That certainly is not
>a government project (the government holds an equity stake, but so do lots
>of other people, in the private company that is digging and running the
>thing!)

Well put, Robert. Sometimes it's hard for U.S. folks to understand that 
the relationships between government and industry are much different in
Europe than here. The Chunnel project is a good example of the interweaving
of governments, private concerns, and sometimes multilateral government
groups, such as the Safety Commission for the Chunnel, whose mission
is _just_ to oversee safety concerns. If I recall correctly, that 
commission is a creature of the British and French governments.

It's hard for Americans to follow that many companies in Europe have
mixed government/private stockholders. In some cases, the government
is the dominant (or only) stockholder, in others there is lots of
private participation as well.

In my experience, Europeans seem more resigned to the idea that
government is involved in their businesses and their lives; I
observe that they tend to deride government, _per se_, much less 
than we do. 

I've often thought that part of the resistance in the U.S. to Ada,
because of its DoD connections, has less to do with political
correctness ("I won't touch anything the bomb-builders use") than
with traditional American disdain for government, and especially the
Feds ("If the government did it, it couldn't possibly be any good.").

How do European readers of CLA react to this? 

[snip]

>There are certainly many examples of non-govt related Ada projects (Boeing
>commercial is an obvious example). Earlier this week, I was at a meeting
>at Praxis, who makes a tool, SPARC Examiner, used in the creation of
>high integrity Ada code. They reported that more than half their customers
>are commercial customers.

Naturally it would be nice to know who these customers are.:-)

People (perhaps Fred is one) who will seek out _any_ reason to argue that
Ada is unsuccessful, will usually find lots of reasons, if they engage
in the kind of speculation Fred did ("only governments use Ada").

I persist in my foggy-headed notion that market share is not the only
measure of success. Ada is succeeding in the areas in which it was
designed to succeed. Sure, I'd love it if all the PC developers were
using Ada, but that is an unrealistic expectation (at last for now),
and is, in an important way, irrelevant.

Mike Feldman

Re: An observation of Ada (may offend)

[Robert Dewar]

It would be nice to know who those customers are

says Mike, speaking of Praxis SPARK-Examiner, commercial users.

Actually we discussed at the meeting last week, that this would make
an interesting Ada use/success story, and they thought that several of
their customers would be happy to share in such a project.

Re: An observation of Ada (may offend)

[Kevin F. Quinn]

In article <3kkdfo$763@felix.seas.gwu.edu>,
          mfeldman@seas.gwu.edu (Michael Feldman) wrote:

> [...]
> In my experience, Europeans seem more resigned to the idea that
> government is involved in their businesses and their lives; I
> observe that they tend to deride government, _per se_, much less 
> than we do. 
> 
> I've often thought that part of the resistance in the U.S. to Ada,
> because of its DoD connections, has less to do with political
> correctness ("I won't touch anything the bomb-builders use") than
> with traditional American disdain for government, and especially the
> Feds ("If the government did it, it couldn't possibly be any good.").
> 
> How do European readers of CLA react to this? 

Fairly well, I guess.  Certainly in the current climate in the UK,
as far as possible everything is farmed out to the private sector.
We have a situation where if something needs doing, the gov. will
do their level best to make sure they do (and spend!) as little
as possible.

I don't know about the US, but in Europe, and especially in the UK,
Ada is booming.  There is far more Ada work about than there are
people to do it.  If I walked out of my current job I would be able to
walk straight into another one by the end of the week, no problem. 
Much as I might like to think that's 'coz I'm very good, it's actually
'coz there's tons and tons of work out there.

> I persist in my foggy-headed notion that market share is not the only
> measure of success. Ada is succeeding in the areas in which it was
> designed to succeed.

Well, some of them :)  I haven't seen much code re-use for example...
Although I think that is due to the relative agd of Ada - since it
tends to be used in "big" projects; i.e. ones that run for several
years, there hasn't been a lot of chance to build up suitable libraries.
And in 'big' projects the re-use tends to be much higher up, at the
requirements level.  In my experience, anyway.

However packaging is used with a vengeance.  Us grunts know a good
thing when we see it :)

> Sure, I'd love it if all the PC developers were
> using Ada, but that is an unrealistic expectation (at last for now),
> and is, in an important way, irrelevant.

Of course, most PC software is still developed in the old
hack-and-slash method.  You won't see them using Ada.  They'll use
C++, but only because they can write C with it :->

One of Ada's main strengths as I see it is the inherent legibility
of code written in Ada.  More than half of the projects I've worked
on in the last few years have been able to avoid generating any
"design" documentation as such; the Ada practically IS the design.
Luckily it's a compilable design :-)  The cost savings are very
significant, obviously.

Anyway, I drift somewhat from the thread...

-- 
Kevin F. Quinn           * "That's not what you said when you sent him your
kevq@banana.demon.co.uk  * Navel."   "Novel, Baldrick, not navel."
kevq@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525  * to me..."                        BlackAdder III
... This is your head..THiS iS yoUR HeAD On WindOwS.

Re: An observation of Ada (may offend)

[Mike Meier]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: In article <3kiani$i49@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
: >There are certainly many examples of non-govt related Ada projects (Boeing
: >commercial is an obvious example). Earlier this week, I was at a meeting
: >at Praxis, who makes a tool, SPARC Examiner, used in the creation of
: >high integrity Ada code. They reported that more than half their customers
: >are commercial customers.

: Naturally it would be nice to know who these customers are.:-)

I can certainly sympathize with those companies who keep their use of Ada a
secret.  My company, even though most of its work is government contracts,
takes the same approach with some proprietary projects.  But, I wonder if we
could get companies to provide this information on an anonymous basis.
We'd have to ask them to mail to one "trusted" place (which could even strip
identifiers automatically) with a count of the number of projects of each
type and/or size (or something like that).  Could we make something like this
work?

Mike Meier
Magnavox Electronic Systems Company

Re: An observation of Ada (may offend)

[Kevin F. Quinn]

In article <3kiani$i49@gnat.cs.nyu.edu>,
          dewar@cs.nyu.edu (Robert Dewar) wrote:

> Isn't the channel tunnel signalling system in Ada?

I believe so.

Another one: Rolls-Royce now use Ada for much of the control software
on their aircraft engines.

There's a lot of Ada in air traffic control systems, as well (certainly
in Europe, anyway).  I guess you probably knew that, anyway.

> [...] Second, you are of course more likely to know
> about the govt related projects.

Hit the nail on the head there, I think.

> Earlier this week, I was at a meeting
> at Praxis, who makes a tool, SPARC Examiner, used in the creation of
> high integrity Ada code.

For information, Praxis have just bought PVL (Program Validation
Limited) who developed the spark (not sparc) examiner et. al.  PVL
were a very small company, attached in some ways to a University (I
forget which one).

--
Kevin F. Quinn           * "That's not what you said when you sent him your
kevq@banana.demon.co.uk  * Navel."   "Novel, Baldrick, not navel."
kevq@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525  * to me..."                        BlackAdder III

Re: An observation of Ada (may offend)

[Michael M. Bishop]

Speaking of non-governmental Ada projects, what is the status of the Ada
flight software on the Boeing 777? Haven't they already test flown the
777? If so, have there been any remarks concerning the run-time
performance of the Ada software?
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <fjm.63.000D29AE@ti.com>, fjm@ti.com (Fred J. McCall) writes:
|> 
|> I'm curious; how many of the things on the list are not government related or 
|> regulated?  Is it significantly easier, for example, to get the government to 
|> sign off on aircraft software in part because it happens to be written in Ada 
|> (irrespective of the actual implementation or of the merits of the language)?  
|> That and the few banking applications would seem to me to be the only ones on 
|> your list not run by governments.
|> 
|> Non-myth -- virtually all Ada software is produced for government agencies?

I would guess that a lot of the projects listed are very large and involve
large groups of developers. Many have real-time constraints, are distributed
and involve concurrency. They are not all saftey-critical but many require
a very high level of reliability.

Now, where is the correlation? Governments seem to be naturally involved
in almost all large safety-critical projects. Furthermore it isn't clear
how much government involvement affects the choice of a language. In
the US the government seems to be keen on saying "use Ada" but I don't
think that is always the case outside of the US.

Here in Switzerland they are replacing the signaling software in many
of the train stations (this is more of a station by station approach based
on necessity rather than anything big like replacing all the signaling
software in all the stations). My understanding is that Swiss Federal
Railway doesn't give a hoot in which language the software is written. The
software is in Ada but the choice of a language had nothing to do with
government involvement. Interestingly enough the parent company of the
company doing the project had applied some presure to use C rather than
Ada but this was rejected as being technically unfounded.

Robb Nebbe

Re: An observation of Ada (may offend)

[Mats Weber]

In article <fjm.63.000D29AE@ti.com>, fjm@ti.com (Fred J. McCall) wrote:

> >Canal+ (French pay-per-view TV, remote cable box control software)
> 
> I have no idea of the status of the French television industry.  Government 
> run or no?

Canal+ is private. It is a channel you have to pay for (it is encrypted
and you must rent a decoder). They participate in the production of almost
every french movie, and many american movies too.

Re: An observation of Ada (may offend)

[Stephen McNeill]

In article <fjm.63.000D29AE@ti.com> fjm@ti.com (Fred J. McCall) writes:

>>Air Traffic Control Systems, by country
>
>Pretty much government, no?

Speak for yourself...  So far as most countries outside the USA are concerned
(excuse the prejudice, it is not intended to offend) I suspect that it makes
no odds whether the whole thing is written in Ada, C++, FORTRAN or Visual
Basic (shudder) so long as the client who is responsible for the
transportation of the hundreds of thousands of (non-government) citizens is
confident that the contractor can do the job safely and efficiently.

As far as the New Zealand ATC is concerned I understand that this was the same
as that sold to a number of other agencies.  So, was it successful because it
was a government contractor enamoured of Ada (in New Zealand ! haw haw...), or
was it successful because it was a good product ?  I think we can chase out
tails on this argument.

>>Television Industry
>
>>Canal+ (French pay-per-view TV, remote cable box control software)
>
>I have no idea of the status of the French television industry.  Government
>run or no?

I think you miss the point.  Ada *is* conspicuous in its use in complex
systems, quite contrary to the ad hoc model of the uptake of other languages.
Is this good or bad ?  Well, since the software industry is so young, history
is being created as we speak (I mean, type...).  Come back in 20 years time
and we'll discuss it on comp.lang.ancient.ada.

Stephen McNeill
Landcare Research New Zealand Ltd

Re: An observation of Ada (may offend)

[Wes Groleau]

In a previous article, kevq@banana.demon.co.uk (Kevin F. Quinn) says:
>I don't know about the US, but in Europe, and especially in the UK,
>Ada is booming.  There is far more Ada work about than there are
>people to do it.  

Tell them to fax their job ads to me - my company is laying off about
a hundred a month

>Of course, most PC software is still developed in the old
>hack-and-slash method.  You won't see them using Ada.  They'll use
>C++, but only because they can write C with it :->

I recently read a book on Object-Oriented Programming, thinking I was
going to learn some really hot techniques.  Instead, page after page I
kept thinking "I've always done it this way!"  Too many programmers still
think implementation rather than abstraction--just because Ada folks don't
use the same jargon as the OOP folks doesn't mean they don't get the same
benefits.  C++ strikes me as an attempt to get some of the benefits of
Ada-83 without giving up your dearly prized ability to ensure that
your manager won't have a clue what your code means.

Re: An observation of Ada (may offend)

[Richard G. Hash]

Vladimir Vukicevic <vladimir@speedy.intrepid.com> wrote:
> >Speaking of why people think Ada is not a good language... it'd be nice
> >if someone collected the many myths about Ada

- Nobody uses Ada unless they were MANDATED (tm) to use it.

Oh wait, that's been repeated at least 100 times in this group,
which means it's a verified net.fact.

Sorry.

--
Richard G. Hash       phone: (713) 245-731           email: rgh@shell.com
Geophysics Research, Shell Exploration and Production Company
Member Team Ada                Free Ada95 compilers: cs.nyu.edu:/pub/gnat
Distributed, Full-OO, Multithreading, all built in. And it's free.