Once again, Ada absent from DoD SBIR solicitation

[Gregory Aharonian]

Attached is a list of titles to 79 solicitations in the DoD FY 1997.1
SBIR solicitation. As I pointed out many years ago, there is little to no
mention of Ada anywhere in these solicitations. Given that all SBIR is new
activities, any programming software related projects MUST be done in Ada,
thanks to the Ada Mandate still in force.

Given that it would cost the DoD absolutely nothing to include with each
such software abstract one additional line such as "Any proposals submitted
for this project must use the Ada programming language", one has to ask why
the DoD is so apathetic to promoting Ada that it doesn't take advantage of
the SBIR process. Here is a chance to foster Ada use in new initiatives,
by smaller entrepreneurial companies, and the DoD does absolutely nothing.

Indeed the most honest admission of DoD attitudes towards programming
languages comes from one of the DARPA projects:

DARPA SB971-008
Tools for safe, efficient mobile code in heterogenous network
environments
"LANGUAGES OF INTEREST ARE NOT LIMITED TO JAVA, BUT MAY
INCLUDE OTHER FAMILIAR LANGUAGES SUCH AS C, C++ AND ML."

Anything but Ada. Now the last director AJPO lied to my face when he
promised to get AJPO to work with the DoD SBIR Program Office to promote
Ada in DoD SBIR solicitations, after which AJPO did absolutely nothing,
a policy apparently being continued by the current AJPO director (assuming
AJPO is even paying attention to such details). It is such an easy thing
to do - why isn't it being done?

Outside the Mandated world where people are free to choose and spend their
own money on programming languages, if AJPO/DISA/DOD was honest enough to
honestly measure, Ada use is less than 2 percent of all activities, fifteen
years and billions of dollars of DoD Ada monies having been spent. And
inside the Mandated world, it isn't too much better, because of the apathy
to details as reflected in the ongoing absence of Ada promotion in the DoD
SBIR program.

Greg Aharonian
Source Translation & Optimization

TITLES TO DOD FY 1997 SBIR SOLITICATION PROJECTS
Projects that are mostly software dependent

N97-001 Systems and technologies for future amphibious warface
N97-010 Sensor fusion engine
N97-038 Registration of forward looking imagery [C/C++] NavAirSysCom
N97-040 Design and coupling analysis for conformal antennas
N97-041 Next generation real time threat simulator for weapon and EW systems
N97-042 Integrated multispectral modeling for surveillance, EW and planning
N97-043 Automatic battle damage assessment in remotely sensed imagery
N97-046 Multiscale wavelet feature extraction [Mathlab/S-plus] NavAirSysCom
N97-050 Use of virtual LANs for multiple level security
N97-051 Spherical angular function analysis models for antennas
N97-053 Distributed integrated data interface and management
N97-057 Advanced display techniques for sonar data presentations
N97-062 Mid-frequency statistical energy analysis modeling
N97-066 Engineering models of reactive munitions and damage effects
N97-070 Distributed EMCON and frequency plan performance monitor
N97-077 Atmospheric data assimilation system
N97-080 Multi-resolution feature imager
N97-087 Covert underwater communications
N97-094 SC 21 Ship information system virtual prototyping
N97-095 Software for automated electronic classroom implementation

AF97-005 Computation tools for design of distributed parameter systems
AF97-015 Multi-modal user interface for remote system operation
AF79-016 Virtual reality control centers for unmanned aerial vehicles
AF97-017 Multi-operator performance aiding by information sharing
AF97-018 Decision support system for decision making teams
AF97-020 Universal operator state classifier
AF97-032 Electromagnetic dosimetric evaluation software
AF97-034 Automated player control system
AF97-035 Development of authoring tools for internet multimedia training
AF97-037 Electronic ground based learning environments
AF97-038 Intelligent agents for education and training applications
AF97-039 Virtual reality for embedded assessment of personnel characteristics
AF97-044 Large scale knowledge base technology
AF97-045 Code generation for real time parallel [Jovial,C,Fortran,Ada]
AF97-046 Multi-source collaborative distributed information systems
AF97-047 Futuristic C5I (collaborative C4) technologies
AF97-048 Active intelligent information environments
AF97-050 CAD conversion tools for VHDL-MS library generation
AF97-060 Information exploitation for identification
AF97-061 Advanced data fusion technology
AF97-063 Intelligent desktop assistant
AF97-064 Single channel spectral characteristics [Matlab]
AF97-065 Advanced information extraction tools
AF97-066 Exploitation of GPS controlled imagery
AF97-077 Anomaly resolution using case-based and/or model-based reasoning
AF97-098 Flight track clear air turbulence model
AF97-099 Automatic target recognition technology [Khoros]
AF97-134 Chaff dispenser location computer model
AF97-135 Global positioning system P(Y) code acquisition
AF97-136 Avionics modeling and simulation technology
AF97-137 Electronic design automation
AF97-143 Flight control technology
AF97-152 Engineering research flight simulation technologies
AF97-201 Tactical kinematic GPS/IMU algorithms
AF97-208 Data fusion using the wavelet transform, fractal theory, statistics
AF97-237 Automatic telemetry stream data format generation
AF97-244 Advanced test software technologies
AF97-254 Application of genetic algorithm to optimization problems
AF97-256 Advanced distributed C4I simulation capabilities
AF97-257 Improved satellite data communication

DARPA 971-006 System and security management tools
DARPA 971-007 Tools for software system understanding and transformation
DARPA 971-008 Tools for safe, efficient, mobile code in networks [Java,C++]
DARPA 971-009 Adaptive network security management
DARPA 971-010 Tools and environments for high performance systems
DARPA 971-029 Rapid ATR model development
DARPA 971-033 Dynamic database technology for battlefield awareness
DARPA 971-034 Architectural components for semantic interoperability
DARPA 971-036 Mixed-initiative information exchange in collective activities

[Gandalf]

Gregory Aharonian wrote:
>

Good information! What have you done to promote Ada recently?

[Bill Nielsen]

Gregory Aharonian <src...@world.std.com> wrote in article
<DyxtA...@world.std.com>...
<snip>

> Indeed the most honest admission of DoD attitudes towards programming
> languages comes from one of the DARPA projects:
>
> DARPA SB971-008
> Tools for safe, efficient mobile code in heterogenous network
> environments
> "LANGUAGES OF INTEREST ARE NOT LIMITED TO JAVA, BUT MAY
> INCLUDE OTHER FAMILIAR LANGUAGES SUCH AS C, C++ AND ML."
>

<snip>

> Greg Aharonian
> Source Translation & Optimization
>

After following up on a post I made last week ("Future of the Ada mandate")
talking to program managers involved DoD procurements, one thing is clear:
The Ada mandate (which is written into law) is being widely ignored. In
most cases, waivers are not even sought. This includes not just R&D
software, but fieldable operational software that supports military
missions for which Ada is expressly designed.

Whenever I have heard a justification, it is that extensive COTS software
will be employed in a system and COTS products are not designed to support
Ada.

Questions:
Are the conditions that led to the creation of Ada no longer valid or are
they just as valid today with new languages and variants popping up every
few months?
Is it time to overhaul the Ada mandate and face reality?
Does the Ada mandate conflict with the desire of DoD to use best commercial
practice?

Bill Nielsen
bnie...@logicon.com
The above represents my own and not my company's opinion.

[Stanley R. Allen]

Bill Nielsen wrote:
>
> After following up on a post I made last week ("Future of the Ada mandate")
> talking to program managers involved DoD procurements, one thing is clear:
> The Ada mandate (which is written into law) is being widely ignored. In
> most cases, waivers are not even sought. This includes not just R&D
> software, but fieldable operational software that supports military
> missions for which Ada is expressly designed.
>

From where I sit, it looks like Bill & Gregory are
right about the DoD.

My company's job is building big simulators, and the
new DoD *mandate* (sound familiar?) for simulations is
called HLA (High Level Architecture), which is being
developed by the Defense Modeling and Simulation
Office (DMSO) See http://www.dmso.mil/projects/hla/
for some interesting overview and mandate stuff.

It's a good idea. It's time has come. But the first
cut of the HLA API is given in .... C++ ! No mention
of Ada anywhere. No justification is given for
avoiding the Ada madate. And HLA is a *big* *deal*.
All the major DoD simulator contractors are hankering
after this work.

So, two DoD mandates mitigate against one another.
(Homework: ask yourself seriously which one will win.)
Note that HLA-compliance for simulators must be
considered new development; there is no such thing
as a COTS HLA-based system. It's too new. So, the
COTS excuse is no reason.

C++ is still not ISO standardized, but many in the C++
community expect that it will be either this year or
early next. When this happens, the DoD Ada mandate
will lose one of its most important contentions --
that Ada is the best choice because of its inter-
national standardization, which no other OO language
currently has.

C++ still seems like a hoax. Every other article or
book I read about C++ (written by members of the C++
community!) decries the complexity of the language,
how hard it is to maintain, how many "gotcha's" there
are, how difficult it is to build large systems which
don't have pathological dependency and fragility
problems, etc.

If you are a DoD Ada programmer, this could be your
future. And don't kid yourself into thinking that Java
will be much better. Java was designed for small
"applets" (the diminutive of "applications"); the Java
code I have seen so far isn't much of an advance in
readability over C++. And the mindset of the two
language cultures is the same. I shudder to think
of what a large system in Java will look like.

Imagine the Boeing 777 in C++ or Java. I wouldn't
want to ride in it.

If you believe in the promise of Ada (as I do), you
could do yourself a favor by listening to Gregory
Aharonian. And then doing something about it.

--
Stanley Allen
s_a...@hso.link.com
(713) 280-4445
-- my opinions only

[David Shochat]

Stanley R. Allen wrote:
>
> C++ is still not ISO standardized, but many in the C++
> community expect that it will be either this year or
> early next.

According to the FAQ list for comp.std.c++ at
http://reality.sgi.com/employees/austern_mti/std-c++/faq.html#B8

ISO standardization will happen 12/98, assuming all remaining votes
succeed.

In this context, I never cease to be amazed at the way people question
the use of GNAT on the grounds that it isn't formally validated for the
Sun ...

And then suggest C++!

People who seem perfectly sane otherwise.
-- David

[Mitch Gart]

Stanley R. Allen (s_a...@hso.link.com) wrote:

: If you are a DoD Ada programmer, this could be your

: future. And don't kid yourself into thinking that Java
: will be much better. Java was designed for small
: "applets" (the diminutive of "applications"); the Java
: code I have seen so far isn't much of an advance in
: readability over C++. And the mindset of the two
: language cultures is the same. I shudder to think
: of what a large system in Java will look like.

I don't think you're right in dismissing Java. It looks
superficially like C++ but is much better in many ways.
To me the choice between Ada 95 and C++ is obvious, Ada
is way better, but the choice between Ada and Java is
very close, each language has some advantages over the other.

- Mitch "speaking for myself" Gart

[Robert Dewar]

"In this context, I never cease to be amazed at the way people question
the use of GNAT on the grounds that it isn't formally validated for the
Sun ..."

Well you have to remember that some people are working in environments which
require a validated compiler and sometimes this requirement takes precedence
over capability. There are no full-language validated compilers for the Sun
yet of course, although there are two subset compilers that have been
validated. If you don't need all the annexes, and you do need a validated
compiler for Ada 95, then that certainly affects your choice.

Our decision at ACT is not to do any validations of subset implementations,
but instead to wait till we can validate the full language with all annexes.
We expect to validate the Sun/Solaris implementation in the near future,
as well as several other versions.

For those interested here is our current validatation status. We are
essentially at 100% on all B tests (core and annexes). We pass 100% of the
C tests in the basic tests, and currently fail about 30 of the Ada 95
C tests, mostly in the annexes, but there are a few core tests still to go.

Note that you can reproduce these results for yourself if you like. The

test suite is publically available.

Robert Dewar
Ada Core Technologies

[Mike Stark]

Stanley R. Allen wrote:
>

>
[snip]

>
> C++ still seems like a hoax. Every other article or
> book I read about C++ (written by members of the C++
> community!) decries the complexity of the language,
> how hard it is to maintain, how many "gotcha's" there
> are, how difficult it is to build large systems which
> don't have pathological dependency and fragility
> problems, etc.
>

> If you are a DoD Ada programmer, this could be your
> future. And don't kid yourself into thinking that Java
> will be much better. Java was designed for small
> "applets" (the diminutive of "applications"); the Java
> code I have seen so far isn't much of an advance in
> readability over C++. And the mindset of the two
> language cultures is the same. I shudder to think
> of what a large system in Java will look like.
>

> Imagine the Boeing 777 in C++ or Java. I wouldn't
> want to ride in it.

Actually, while Java superficially looks like C++, it is semantically
more like Smalltalk or Ada 95. Most of the truly nasty features of C
are removed (such as pointers -- the only pointers in Java are
references to objects, and pointer address arithmetic is not allowed).

I too haven't seen any large applications in Java yet. However, it
is a good programming language independent of the applet concept, and
it certainly doesn't deserve to be grouped with C++. I have also used
the Intermetrics AppletMagic tool to compile Ada code into Java classes,
which might be the way to develop large applications for the Web,
rather than writing everything in Java.

>
> If you believe in the promise of Ada (as I do), you
> could do yourself a favor by listening to Gregory
> Aharonian. And then doing something about it.
>

I'm not a fan of mandates in general. Ultimately Ada is going to have
to compete in the marketplace. For mission-critical software such as
missile guidance and flight control, a DOD mandate makes sense. For
business applications, the use of other languages is not a big issue
with me.

[Brian Rogoff]

m...@harp.camb.inmet.com (Mitch Gart) writes:
I don't think you're right in dismissing Java. It looks
superficially like C++ but is much better in many ways.
To me the choice between Ada 95 and C++ is obvious, Ada
is way better, but the choice between Ada and Java is
very close, each language has some advantages over the other.

While I agree with you that Java is mostly an improvement over C++, and
I rather like it as a language, I don't see too many advantages that
Java has over Ada. Garbage collection is a big one, but some would disagree.
Simplicity of the threading model might be another. The standard libraries
are not part of the language, so they don't count. Simplicity? It certainly is
easier to learn, but I sure wouldn't want to write numerics or image
processing libraries in it (among other things) since it is missing so much.

I'm curious, what are the advantages that the Java language has over Ada 95,
in your opinion?

-- Brian

[David Shochat]

Robert Dewar wrote:
>
> Well you have to remember that some people are working in environments which
> require a validated compiler and sometimes this requirement takes precedence
> over capability.

Yes, I understand that. My point concerned those who make that argument
about Ada 95, and then conclude that we should use C++. It's an
incredible double standard given C++'s standardization status.
-- David

[Jon S Anthony]

In article <325BED...@itg-sepg.logicon.com> David Shochat <sho...@itg-sepg.logicon.com> writes:

> > C++ is still not ISO standardized, but many in the C++
> > community expect that it will be either this year or
> > early next.
>
> According to the FAQ list for comp.std.c++ at
> http://reality.sgi.com/employees/austern_mti/std-c++/faq.html#B8
>
> ISO standardization will happen 12/98, assuming all remaining votes
> succeed.
>

> In this context, I never cease to be amazed at the way people question
> the use of GNAT on the grounds that it isn't formally validated for the
> Sun ...
>

> And then suggest C++!
>
> People who seem perfectly sane otherwise.

Indeed. But sanity is orthogonal to stupidity, and as the saying
goes, "Always count on stupidity"...

/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
j...@organon.com

[Dave]

Brian Rogoff wrote:
>
> m...@harp.camb.inmet.com (Mitch Gart) writes:
> I don't think you're right in dismissing Java. It looks
> superficially like C++ but is much better in many ways.
> To me the choice between Ada 95 and C++ is obvious, Ada
> is way better, but the choice between Ada and Java is
> very close, each language has some advantages over the other.
>
> While I agree with you that Java is mostly an improvement over C++, and
> I rather like it as a language, I don't see too many advantages that
> Java has over Ada. Garbage collection is a big one, but some would disagree.

<snip>

> I'm curious, what are the advantages that the Java language has over Ada 95,
> in your opinion?
>

Garbage collection, by itself, is significant enough for one to
seriously consider choosing Java over Ada for projects which do not
require low-level timing control.

Garbage collection greatly increases developer productivity and greatly
reduces error counts. Except for hard real-time systems, it is, IMHO,
very unwise to choose a language without a garbage collector when a
language with a garbage collector is available.

Personally, however, Java would not be my first choice among languages
with garbage collectors. According to the data that I have seen, Eiffel
is an inherently more productive language than Java, and, like Ada, it
has a wide variety of features to promote "error-free" programming. (Of
course, Java does have an advantage in that it has better third party
support than Eiffel.)

-- Dave Jones

[Stanley R. Allen]

Mike Stark wrote:

>
> Actually, while Java superficially looks like C++, it is semantically
> more like Smalltalk or Ada 95. Most of the truly nasty features of C
> are removed (such as pointers -- the only pointers in Java are
> references to objects, and pointer address arithmetic is not allowed).

Concerning semantics, you are certainly correct.
But readability is very much a syntactic issue, and
this is a big minus for Java. Its "superficial"
similarity to C++ is the problem, especially for
large long-lived systems.

>
> I too haven't seen any large applications in Java yet. However, it
> is a good programming language independent of the applet concept, and
> it certainly doesn't deserve to be grouped with C++.

Well, Java does have the "import" clause analogous to
the Ada "with". But I don't believe that it has "dot"
notation to let you trace entities back to the point
of declaration (at least I haven't seen it in the
examples I've looked at, in Gosling's book). Which
means it's like the Ada "use" clause is implied
everywhere -- and you know what that means for the
long term.

> I have also used
> the Intermetrics AppletMagic tool to compile Ada code into Java classes,
> which might be the way to develop large applications for the Web,
> rather than writing everything in Java.

This is fine by me -- really it means that you are
compiling Ada to another kind of object code -- the
Java Virtual Machine. This is the real "revolution"
(folks want think it's a new idea) about Java.
The language itself is unnecessary. Most of the
rah-rah about "Java" in the press is really about the
JVM concept; people just get confused (God bless 'em).

> I'm not a fan of mandates in general. Ultimately Ada is going to have
> to compete in the marketplace. For mission-critical software such as
> missile guidance and flight control, a DOD mandate makes sense. For
> business applications, the use of other languages is not a big issue
> with me.

Yes, the DoD Ada mandate makes sense. But enforcing it may
be the only way that the Ada market survives until the
commercial tech-transfer really takes place. Remember the
Ada universe circa 1986? Few compliers, only a few early
adopters in the DoD, lots of criticisms in the Air Force,
etc. But the Ada mandate was taken more seriously back
then; the Ada market grew, more compilers came on line,
more commercial projects started to happen, etc.

DoD enforcement of its own Ada policy would have far
reach, and Ada can penetrate into the marketplace
based on it. Don't forget that the DoD is still one
of the very largest procurement agencies for new SW.
And DoD standards don't have to be marketplace rejects.
Remember where TCP/IP came from? It's not too late for
Ada to be the next big DoD tech-transfer success story.

--
Stanley Allen
s_a...@hso.link.com
(281) 280-4445
-- my opinions only

[Tucker Taft]

Dave (da...@gte.net) wrote:

: Garbage collection, by itself, is significant enough for one to

: seriously consider choosing Java over Ada for projects which do not
: require low-level timing control.

: Garbage collection greatly increases developer productivity and greatly
: reduces error counts. Except for hard real-time systems, it is, IMHO,
: very unwise to choose a language without a garbage collector when a
: language with a garbage collector is available.

For what it's worth, our AppletMagic(tm) Ada95 => Java byte-code
compiler gives you Java's garbage collection, along with Ada's many
compile-time advantages, such as enumeration types, strongly distinguished
numeric and array types, generic templates, separate spec and body,
in/out/in-out parameter modes, named parameters in calls, etc.

See www.inmet.com/javadir/download/ for a beta version.

: ...
: -- Dave Jones

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

[Mitch Gart]

Stanley R. Allen (s_a...@hso.link.com) wrote:

: Mike Stark wrote:
: > Actually, while Java superficially looks like C++, it is semantically
: > more like Smalltalk or Ada 95. Most of the truly nasty features of C
: > are removed (such as pointers -- the only pointers in Java are
: > references to objects, and pointer address arithmetic is not allowed).

: Concerning semantics, you are certainly correct.
: But readability is very much a syntactic issue, and
: this is a big minus for Java. Its "superficial"
: similarity to C++ is the problem, especially for
: large long-lived systems.

There are things about Java which are more readable than Ada. I know
this is an old argument but in Java you have

obj.func(param);

and in Ada it's

func(obj, param);

To me the Ada is less readable, you have to look up the function's declaration
and the parameter's type declaration and think a little bit to know whether the
call is dispatching or not. Also the Java notation is more indicative of what
is really going on in the program: the function is attached to the object and
the function that will be called depends on the object.

Ada package notation makes it worse:

pkg1.func(obj, param);

can really call the code in the body of pkg2, instead of pkg1, if there is
dispatching. To me in this case the Ada syntax is lying to the person who
is reading the program. It makes the code hard to read correctly in my opinion.
This says "use" clauses should be used wherever there is dispatching, but as
we know a lot of Ada coding standards frown on "use" clauses.

- Mitch "just my opinion" Gart

[Stephen Leake]

Dave wrote:
>
> Garbage collection, by itself, is significant enough for one to
> seriously consider choosing Java over Ada for projects which do not
> require low-level timing control.

The Ada _language_ supports garbage collection, just as the Java
_language_ does. The Java Virtual Machine implements it, while most Ada
runtimes do not. Intermetrics AppletMagic uses the JVM garbage
collection with Ada95.

People do get confused :-)

> -- Dave Jones

--
- Stephe

[Mitch Gart]

Brian Rogoff (rog...@sccm.Stanford.EDU) wrote:
: The standard libraries

: are not part of the language, so they don't count.

Sure they count, if you want them to :-) Seriously, I think they should count
because just about every program in any language uses a standard library that
comes with the language.

In Java
- there are more standard libraries, for example for windowing and networking
and simple graphics
- all the standard libraries are designed from the start to be object-oriented

This is a significant advantage over the Ada standard libraries.

Like Tucker says, if you use AppletMagic and use the Ada bindings to the standard
Java libraries you inherit these advantages.

- Mitch Gart

[Dave]

As I understand it (I might be wrong.), the Ada95 standard does not
include true garbage collection, but, instead, it has something called
garbage reduction. Garbage reduction, apparently, is not as efficient
as garbage collection, and, I am told, you risk filling up memory if you
rely on it for a large, complex application.

I am very pleased to see that Intermetrics has developed a true garbage
collector for Ada95. Can this be used as a third-party product to add
garbage collection to any Ada95 system. If so, then quite a few
companies would be wise to reconsider Ada95 before starting their next
project.

-- Dave Jones

[Ken Garlington]

Mitch Gart wrote:
>
> Stanley R. Allen (s_a...@hso.link.com) wrote:
> : Mike Stark wrote:
> : > Actually, while Java superficially looks like C++, it is semantically
> : > more like Smalltalk or Ada 95. Most of the truly nasty features of C
> : > are removed (such as pointers -- the only pointers in Java are
> : > references to objects, and pointer address arithmetic is not allowed).
>
> : Concerning semantics, you are certainly correct.
> : But readability is very much a syntactic issue, and
> : this is a big minus for Java. Its "superficial"
> : similarity to C++ is the problem, especially for
> : large long-lived systems.
>
> There are things about Java which are more readable than Ada. I know
> this is an old argument but in Java you have
>
> obj.func(param);
>
> and in Ada it's
>
> func(obj, param);
>
> To me the Ada is less readable, you have to look up the function's declaration
> and the parameter's type declaration and think a little bit to know whether the
> call is dispatching or not.

Why not

Func (Dispatching_On => Obj, With_Parameter => Param);

which says explicitly what you want it to say, without having to look at _any_
declarations? I don't see why "obj dot func" is more readable!

> Ada package notation makes it worse:
>
> pkg1.func(obj, param);
>
> can really call the code in the body of pkg2, instead of pkg1, if there is
> dispatching. To me in this case the Ada syntax is lying to the person who
> is reading the program. It makes the code hard to read correctly in my opinion.
> This says "use" clauses should be used wherever there is dispatching, but as
> we know a lot of Ada coding standards frown on "use" clauses.

However, the _language_ doesn't frown on it. If you think the use clause makes
your code more readable, then use it! That's what it's for!

That's one of the wonderful things about Ada, in my opinion. If you want to make
the dispatching explicit, you can do it. If you want to hide it as an unnecessary
implementation detail, Ada lets you do that too (at least to some extent).

>
> - Mitch "just my opinion" Gart

--
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

[Jon S Anthony]

In article <ROGOFF.96O...@sccm.Stanford.EDU> rog...@sccm.Stanford.EDU (Brian Rogoff) writes:

> I rather like it as a language, I don't see too many advantages that
> Java has over Ada. Garbage collection is a big one, but some would
> disagree.

I don't disagree that GC is great in most circumstances. I disagree that
Java has it and Ada does not in any current environment where Java "the
language" is implemented. So, Java having GC in this context is just
plain irrelevant.

> Simplicity of the threading model might be another.

It's way too primitive and low level. Some seem to think of this as
simply "simpicity"...

> I'm curious, what are the advantages that the Java language has over Ada 95,
> in your opinion?

Hype and buzz and the fact that "sheep look up". Technically?
Nothing.

/Jon
--
Jon Anthony
Organon Motives, Inc.

[Ed Falis]

Robert Dewar wrote:
>
> Well you have to remember that some people are working in environments which
> require a validated compiler and sometimes this requirement takes precedence

> over capability. There are no full-language validated compilers for the Sun
> yet of course, although there are two subset compilers that have been
> validated. If you don't need all the annexes, and you do need a validated
> compiler for Ada 95, then that certainly affects your choice.
>
> Our decision at ACT is not to do any validations of subset implementations,
> but instead to wait till we can validate the full language with all annexes.
> We expect to validate the Sun/Solaris implementation in the near future,
> as well as several other versions.
>

Gee, I thought the Annexes were OPTIONAL components of validated compilers, not that compilers without the
annexes were SUBSET(!!!) (implied "NOT REALLY FULL Ada 95") compilers.

Don't you think you ought to be a little more careful about what you're writing between the lines? Or should we
start slinging mud about the IDE capabilities of GNAT on various platforms as somehow making it not a "real"
Ada 95 compiler? Seems of simiar relevance and bogosity. How about lowering the BS level?

Speaking for me. - Ed

--
Ed Falis
Thomson Software Products
(617) 221-7341

[Dave Wood]

David Shochat wrote:

>
> Stanley R. Allen wrote:
> >
> > C++ is still not ISO standardized, but many in the C++
> > community expect that it will be either this year or
> > early next.
>
> According to the FAQ list for comp.std.c++ at
> http://reality.sgi.com/employees/austern_mti/std-c++/faq.html#B8
>
> ISO standardization will happen 12/98, assuming all remaining votes
> succeed.
>
> In this context, I never cease to be amazed at the way people question
> the use of GNAT on the grounds that it isn't formally validated for the
> Sun ...

Not true. ObjectAda passed full core language validation some time ago
on Sun SPARC/Solaris.

> And then suggest C++!
>
> People who seem perfectly sane otherwise.

> -- David

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Thomson Software Products
-- http://www.thomsoft.com

[Jon S Anthony]

In article <325D7F...@gte.net> Dave <da...@gte.net> writes:

> Brian Rogoff wrote:
> >
> > m...@harp.camb.inmet.com (Mitch Gart) writes:
> > I don't think you're right in dismissing Java. It looks
> > superficially like C++ but is much better in many ways.
> > To me the choice between Ada 95 and C++ is obvious, Ada
> > is way better, but the choice between Ada and Java is
> > very close, each language has some advantages over the other.
> >
> > While I agree with you that Java is mostly an improvement over C++, and

> > I rather like it as a language, I don't see too many advantages that
> > Java has over Ada. Garbage collection is a big one, but some would disagree.

> <snip>

> > I'm curious, what are the advantages that the Java language has over Ada 95,
> > in your opinion?
> >
>

> Garbage collection, by itself, is significant enough for one to
> seriously consider choosing Java over Ada for projects which do not
> require low-level timing control.

Do any Java "the language" implementations exsit which do not target
the JVM? I don't know of any, but maybe there are? If not, this GC
argument is just irrelevant. If Java means JVM, and you want that
(for whatever reason) then using Ada in this context will also give
you GC simply because the Ada->J implementations have GC (by using the
JVM GC - just like the JTL impl does)

> Garbage collection greatly increases developer productivity and greatly
> reduces error counts. Except for hard real-time systems, it is, IMHO,
> very unwise to choose a language without a garbage collector when a
> language with a garbage collector is available.

But *languages* don't have GC. Implementations of them do. Even
Meyer says little about GC in ETL - just that all *implementations*
are *expected* to have it.

[Robert Dewar]

Mitch says

"To me the Ada is less readable, you have to look up the function's declaration
and the parameter's type declaration and think a little bit to know whether the

call is dispatching or not. Also the Java notation is more indicative of what
is really going on in the program: the function is attached to the object and
the function that will be called depends on the object."

I really don't know why Mitch is cycling out this old argument, he does
not seem to have anything new to say. We have gone around this argument
many times, and people feel strongly on both sides. I personally think
that the prefix notation is a mess, it is non-uniform, and not surprisingly
results in a much more limited semantic capability, since it is too oriented
to the idea of single objects and messages, while the Ada model is much
more general (note that this is not a matter of opinion, it is a statement
of fact, there are things easily done using the Ada notatoin that cannot
be done using the prefix notation, and vice-versa is not true!)

Which you prefer to look at is certainly a matter of opinion, and you
really can't go much further on that than stating your opinion. Indeed
previous boring threads on this topic have been little more than statements
of opinion.

As I say, I am not sure why Mitch is trying to restart this thread ...

[Robert Dewar]

"Gee, I thought the Annexes were OPTIONAL components of validated compilers, not
that compilers without the
annexes were SUBSET(!!!) (implied "NOT REALLY FULL Ada 95") compilers."

Of course it is definitely the case that the annexes are optional, in the
same sense that the optional modules of COBOL, e.g. the Report Generator,
are optional. So a compiler that does not implement all the features
of the language is still meeting the conformance requirements, just as
would be the case with COBOL. No one is saying that such an implementation
is not a valid Ada 95 implementation.

By subset, I simply meant a subset of the full language capabilities in the
RM. There is nothing wrong with subsetting the language by leaving out the
annexes if the application does not need the full language! I would
certainly think that most people would think that "full language" meant
everything in the RM, but you can use any term any way you want! Certainly
for us, full language *does* mean all the capabilities in the RM.

Don't you think you ought to be a little more careful about what you're
writing between the lines? Or should we start slinging mud about the IDE

capabilities of GNAT on various platforms as so mehow making it not a "real"

Ada 95 compiler? Seems of simiar relevance and bogosity. How about lowering
the BS level?

Well since the idea of optional sections is new in Ada 95, I think it is
important that everyone understand the issues here. TO me it is obfuscatory
to claim you implement the full language and leave out important
capabilities. Yes, these capabilities are optional from a formal
point of view, e.g. for validation, but if you need the capabilities,
then they are definitely not optional.

As for "mud" slinging, the TSP salesfolks definitely emphasize what they
feel is their superior IDE capabilities, and I don't think of it as mud
at all. It's perfectly natural that different companies stress different
aspects, and emphasize them. That's what competition is all about! In
fact we regard the open GNAT environment as having advantages over IDE's
for many people, since it is much easier to put together the tool set
you want from standard tools. But that's something users have to decide
for themselves!

Robert Dewar
Ada Core Technologies.

[Jon S Anthony]

In article <325D29...@itg-sepg.logicon.com> David Shochat <sho...@itg-sepg.logicon.com> writes:

> Robert Dewar wrote:
> >
> > Well you have to remember that some people are working in environments which
> > require a validated compiler and sometimes this requirement takes precedence
> > over capability.
>

> Yes, I understand that. My point concerned those who make that argument
> about Ada 95, and then conclude that we should use C++. It's an
> incredible double standard given C++'s standardization status.

Well, that's a rather charitable reading. I'd say (and have) it is just
plain stupid.

[John Cosby]

Stanley R. Allen wrote:
> My company's job is building big simulators, and the
> new DoD *mandate* (sound familiar?) for simulations is
> called HLA (High Level Architecture), which is being
> developed by the Defense Modeling and Simulation
> Office (DMSO) See http://www.dmso.mil/projects/hla/
> for some interesting overview and mandate stuff.

This is a mandate with teeth - HLA compliance is specified
in the contracts being proposed and awarded now, and has been
back-filled into existing developments. Unlike the Ada mandate,
which isn't often specified in the contract, or lets folks weasle out.

> It's a good idea. It's time has come. But the first
> cut of the HLA API is given in .... C++ ! No mention
> of Ada anywhere. No justification is given for
> avoiding the Ada madate. And HLA is a *big* *deal*.
> All the major DoD simulator contractors are hankering
> after this work.

First, it's not the HLA API - it's the first implementation
of the HLA Runtime Infrastructure that's being written in
C++. The original design was to use CORBA IDL to specify
the interfaces, allowing any language for which an emitter
exists to be used. The prototype versions of the RTI,
up to and including RTI 1.0, are being developed by the
gov't (MITRE and MIT Lincoln Labs) in C++. The gov't is
supposed to solicit commercial development of one or more
RTIs Real Soon Now - the prototype should be all grown up
around February.

You want mention of Ada? DMSO funded several efforts to use
the prototype RTI and get feedback from different groups of
simulation users. Originally (and this is buried in the
AMG minutes on the web site), there was to have been an
Ada front-end, but the RTI developers had so much trouble
with the initial prototype releases they couldn't support
a parallel effort. We (I worked one of the "proto-federation"
efforts) had to interface our Ada simulation system to the
C++ interfaces generated from the IDL interface specification.
Why didn't we just use the Ada95 CORBA IDL emitter for
our ORB? It didn't exist yet; it came along about the
time the protofederation effort ended. Believe me, there's
been talk about Ada - not too productive, but the issue's
never been killed.

> So, two DoD mandates mitigate against one another.
> (Homework: ask yourself seriously which one will win.)
> Note that HLA-compliance for simulators must be
> considered new development; there is no such thing
> as a COTS HLA-based system. It's too new. So, the
> COTS excuse is no reason.

Um... actually, the "commercial RTI" may be considered COTS
eventually, or GOTS. DMSO _really_ doesn't want every
simulation effort writing their own RTI - that would make
interoperability a problem - they want everyone using a "standard"
RTI. (Unlike the old DIS and ALSP standards, HLA specifies object
models
and leaves it to the RTI to sweat the bit-formats going out over the
network - there's no way to guarantee interoperability of two "HLA
compliant" simulations using different RTIs). If the RTI's in C++, this
could indeed be a problem - I learned a lot of hard lessons about making
C++ callable from Ada over the last six months.

And yes, I'm very nervous about using an RTI written in C++.
Can't you tell?

<snippage>

> If you believe in the promise of Ada (as I do), you
> could do yourself a favor by listening to Gregory
> Aharonian. And then doing something about it.

I am. Sometime in November, I get to start giving feedback
to the Ada interface specification that should be published with
the RTI 1.0 release; I also get to go to work in Nov./Dec. porting
the RTI to the IBM RS/6000 platform, hopefully with an Ada95 front-end.
Anyway, that's the plan. Check with me in December and I'll let
you know how it's going.

John
--
John Cosby | Opinions expressed are those of the
individual
SAIC Orlando | and in no way represent any official
position
John.D...@cpmx.saic.com | or opinion of SAIC unless specifically
noted.
(407) 282-6700 x216 | Live long and perspire....

[Matthew M. Lih]

Bill Nielsen wrote:

> Questions:
> Are the conditions that led to the creation of Ada no longer valid or are
> they just as valid today with new languages and variants popping up every
> few months?
> Is it time to overhaul the Ada mandate and face reality?
> Does the Ada mandate conflict with the desire of DoD to use best commercial
> practice?

Depends. I hear different people use the buzzwords "best commercial
practice", but "best" is a relative term, "good" is an absolute.
Does anyone have any examples of a *good* commercial practice they'd
like to share?

Matthew M. Lih
TRW Enterprise Solutions

[Robert Dewar]

"Garbage collection, by itself, is significant enough for one to
seriously consider choosing Java over Ada for projects which do not
require low-level timing control.
"

Nope, that does not make any sense. Any project for which Java is currently
suitable could equally well be done in Ada using the Intermetrics compiler
to JBC, which has identical garbage collection capability.

[Robert Dewar]

Dave says

"As I understand it (I might be wrong.), the Ada95 standard does not
include true garbage collection, but, instead, it has something called
garbage reduction. Garbage reduction, apparently, is not as efficient
as garbage collection, and, I am told, you risk filling up memory if you
rely on it for a large, complex application.

I am very pleased to see that Intermetrics has developed a true garbage
collector for Ada95. Can this be used as a third-party product to add
garbage collection to any Ada95 system. If so, then quite a few
companies would be wise to reconsider Ada95 before starting their next
project."

First, you are wrong, completely! I have no idea what garbage reduction
might be, but in any case, the Ada language is neutral wrt garbage collection,
as, for that matter, is Java from a formal point of view. The whole point
of gc is that it has no semantics, it is transparent!

Any language that translates into JBC will naturally inherit the garbage
collection capability used when Java compiles to JBC. Remember, garbage
collection is NOT part of a language, it is part of an implementation.
This means that thre is no question of using the intermetrics garbage
collection in other contexts, since Intermetrics has not "developed a
true garbage collector", they are merely, quite reasonably, borrowing
the JBC collector. Any other Ada compiler that generated JBC would
inherit the same capability.

It is of course possible to add garbage collection to other Ada
compilers. Whether this is indeed desirable remains to be seen. Garbage
collection has never made it into a mainstream language before for all
sorts of reasons, but it seems quite possible that java will change this.
Of ccourse we won't really know till Java compilers appear, which should
be pretty soon now.

[Dave Wood]

Dave Wood wrote:
>
> David Shochat wrote:
> >
> > Stanley R. Allen wrote:
> > >
> > > C++ is still not ISO standardized, but many in the C++
> > > community expect that it will be either this year or
> > > early next.
> >
> > According to the FAQ list for comp.std.c++ at
> > http://reality.sgi.com/employees/austern_mti/std-c++/faq.html#B8
> >
> > ISO standardization will happen 12/98, assuming all remaining votes
> > succeed.
> >
> > In this context, I never cease to be amazed at the way people question
> > the use of GNAT on the grounds that it isn't formally validated for the
> > Sun ...
>
> Not true. ObjectAda passed full core language validation some time ago
> on Sun SPARC/Solaris.
>

In fact, to be complete, here's the AdaIC reference:

http://sw-eng.falls-church.va.us/AdaIC/compilers/95val/95vcl.htm#thomson

[Kevin D. Heatwole]

In article <dewar.845091423@merv>, de...@merv.cs.nyu.edu (Robert Dewar) wrote:

>"Gee, I thought the Annexes were OPTIONAL components of validated
compilers, not
>that compilers without the
>annexes were SUBSET(!!!) (implied "NOT REALLY FULL Ada 95") compilers."
>
> Of course it is definitely the case that the annexes are optional, in the
> same sense that the optional modules of COBOL, e.g. the Report Generator,
> are optional. So a compiler that does not implement all the features
> of the language is still meeting the conformance requirements, just as
> would be the case with COBOL. No one is saying that such an implementation
> is not a valid Ada 95 implementation.
>
> By subset, I simply meant a subset of the full language capabilities in the
> RM. There is nothing wrong with subsetting the language by leaving out the
> annexes if the application does not need the full language! I would
> certainly think that most people would think that "full language" meant
> everything in the RM, but you can use any term any way you want! Certainly
> for us, full language *does* mean all the capabilities in the RM.
>

Well, I have used all the Ada95 compilers (or have talked to people who have)
and I got to say that this whole discussion is a bit irrelevant at this point.
There simply is no Ada95 compiler that implements all the core requirements
of the language, let alone worrying about whether the optional annexes are
optional. GNAT certainly fails to compile many legal Ada95 programs and
allows many other illegal programs (I run into this just about every day now
since people are porting code written with GNAT to our PowerAda compiler).
I don't mean to pick on GNAT here since all of the compilers are in the same
boat here.

I would expect this situation to continue for a year or so until the current
compilers mature and get the bugs shaken out. The question for end users
to decide now is not whether they require the "full language" (because if
this is the requirement, they are left with no options), but whether the
compiler is mature enough and implements enough of the language to meet
their needs.

During this period of transition to Ada95 from Ada83, I would expect that
it is, by far, more important to have a close working relationship with your
vendor than whether the vendor claims to have implemented the "full language".

By the way, for those not familar with the current validation process, the
US government requires that compiler vendors demonstrate compliance to
a set of minimum requirements for compilers sold to the government. This
compliance is demonstrated for Ada95 by running a suite of tests called the
ACVC tests. Just like the Ada compilers it tests, this test suite is currently
in the process of evolving/maturing. The first version of this test suite for
Ada95 compilers was called ACVC 2.0 and compiler vendors
started validating their compilers under this test suite late last year
(OC Systems validated our PowerAda compiler in December). This test
suite did not require a compiler to pass all the tests in the suite. In
fact, any validate-able Ada83 compiler could be validated with ACVC 2.0
without having to implement a single Ada95 feature. Most vendors chose
to validate by passing all the applicable core language tests, but one vendor
chose not to run any of the tests that use Ada95 features. Also, the ACVC 2.0
test suite isn't a very complete test suite for testing Ada95 features.

Early this year, an incremental version of ACVC 2.0 went into place for
vendors validating new Ada95 compilers on new platforms. This version is
called ACVC 2.0.1. ACVC 2.0.1 didn't add any new tests to the test suite but
did fix the bugs in the existing ACVC 2.0 test suite for tests that had been
withdrawn from ACVC 2.0. One important policy change for this test suite
is that Ada95 compilers validating under this test suite now have to pass
a few Ada95 tests to be validated (an Ada95 compiler must now pass either
the OOP tests or the Real-Time tests).

The "real" Ada95 validation suite will go into place for the 2nd quarter of
1997 with the arrival of ACVC 2.1. This test suite is still being developed,
but it should contain tests for almost all testable features of Ada95 (of
any consequence). Vendors will have to demonstrate compliance to all core
requirements of the Ada95 language in order to get a validation certificate.
Compliance to the optional Ada95 annexes will also be optionally tested.
Passing this test suite will be a real accomplishment for Ada95 compilers.
Users can be assured that Ada95 compilers that have been validated under
ACVC 2.1 are reasonably complete.

So, during this transition period, I would be very careful about relying on
claims of "validated Ada95" or "full language support". These claims are
largely "marketing hype". Users will have to do their own research or
evaluation testing to determine whether a particular compiler is mature
enough and implements enough of the Ada95 language for their own
particular needs. Fortunately, many of the current Ada95 compilers are
quite useable now, even if they don't support the "full language".

Speaking for myself,

Kevin Heatwole
OC Systems, Inc.

[dave...@io.com]

Jon S Anthony wrote:
>
> But *languages* don't have GC. Implementations of them do. Even
> Meyer says little about GC in ETL - just that all *implementations*
> are *expected* to have it.
>

Yes, that is correct: Languages do not have garbage collectors --
implementations do. (In fact, according to the copy of ETL which I
have, garbage collection is merely recommended -- not required -- for
Eiffel implementations.) So, strictly speaking, I was wrong when I said
that Java is a language with garbage collection and Ada is not.

However, suppose you were in the position of a software engineer who
needed to choose between Java and Ada. Suppose also that garbage
collection was high on your list of "must haves". Well, you could wait
until Intermetric's Applet Magic gets out of beta (and becomes available
on your platform). Or you could pay someone to write an add-on garbage
collector for your compiler and hope that they finish on-time. Or you
could get a Java (or Eiffel or Smalltalk or Lisp) system and start
working now.

If you were in this situation, then from your viewpoint, it might make
sense to say that Java has garbage collection and Ada does not.
Nevertheless, you are correct: Strictly speaking, neither language has
garbage collection. *** The world would be a much better place if we
would all express ourselves with greater clarity and precision, so
thanks to Jon -- and everyone else -- for pointing out my error. ***

BTW: I have heard that, for C++, someone has written a garbage
collector which can be added to almost any C++ program. Would it be any
more difficult to do the same thing for Ada95? I would certainly look
forward to such a product. IMHO, memory management is something that a
machine should do (whenever possible) -- freeing up humans to do things
which require more skill and creativity.

Thanks again for pointing out my error.

-- Dave Jones

[Robert Dewar]

Jon asks

"Do any Java "the language" implementations exsit which do not target
the JVM? I don't know of any, but maybe there are? If not, this GC
argument is just irrelevant. If Java means JVM, and you want that
(for whatever reason) then using Ada in this context will also give
you GC simply because the Ada->J implementations have GC (by using the
JVM GC - just like the JTL impl does)"

Someone has done a front end for gcc, I don't know how usable it is. But
more importantly several big companies are producting real Java compilers
as oppposed to interpretive systems using JVM. Clearly this is an expected
development. JVM is fine for a limited set of applications, but real
compilers for Java will greatly increase the possible range of applications.

[dave...@io.com]

An excellent idea Robert -- except for one big problem: Engineers who are
trying to build reliable, commercial products don't generally like to use
proucts which are still in beta.

-- Dave Jones

[Robert Dewar]

Kevin from OC Systems sayds

"Well, I have used all the Ada95 compilers (or have talked to people who have)
and I got to say that this whole discussion is a bit irrelevant at this point.
There simply is no Ada95 compiler that implements all the core requirements
of the language, let alone worrying about whether the optional annexes are
optional. GNAT certainly fails to compile many legal Ada95 programs and
allows many other illegal programs (I run into this just about every day now
since people are porting code written with GNAT to our PowerAda compiler).
I don't mean to pick on GNAT here since all of the compilers are in the same
boat here."

Some clarifications. When we say GANT implements the full language, we
are certainly not claiming that we process all possible programs correctly.
I doubt that such a statement can ever be made about any compiler for a
language of this complexity. What we mean is that if you use any part of
the language and it does not work, we will consider it as a bug, rather
than telling you that we don't implement that feature.

Actually that is not quite absolute, since there are features that do not
make sense in all environments, but our goal is that there should be no
significant omissions. GNAT 3.07 will come much closer to this by closing
one of the most significant current gaps -- package Machine_Code and
machine code instrinsic routines are fully supported in this version.

Whether this is relevant or not depends on your requirements. If you want
to build a distributed application using the facilities of Annex E, then
it might be critical. But, as I have often said, if your application does
not need a partiular Annex, and you are sure of this for the future, then
it makes perfectly good sense to use a compiler that does not implement
this annex.

I would personally like to see all the Ada 95 compilers implement all the
annexes, except in cases where it makes no sense (I don't think the Patriot
compiler needs to compute payrolls using the information systems annex :-).
That's because I think the semantics in the distribution annex and the other
special needs annexes greatly increase the semantic power of the language.

Robert Dewar
Ada Core Technologies

[Dave]

Robert Dewar wrote:
>
> First, you are wrong, completely! I have no idea what garbage reduction
> might be, but in any case, the Ada language is neutral wrt garbage collection,
> as, for that matter, is Java from a formal point of view.

You are correct: See my reply to Jon Anthony's post.

Garbage reduction works like this: When a type goes out of scope, all instances
of that type are deleted.

> The whole point
> of gc is that it has no semantics, it is transparent!
>

Actually, Ada95 provides a pragma (pragma Controlled) to turn off garbage
collection. If the programmer can turn garbage collection on or off it is
transparent only if the programmer wants it to be.

> Garbage
> collection has never made it into a mainstream language before for all
> sorts of reasons, but it seems quite possible that java will change this.

Perhaps you wouldn't, but I would consider Lisp and Smalltalk to be mainstream
languages. In fact, I would guess that Smalltalk is at least as popular as Ada
-- perhaps more so.

-- Dave Jones

[Robert Dewar]

Dave Jones said

"BTW: I have heard that, for C++, someone has written a garbage
collector which can be added to almost any C++ program. Would it be any
more difficult to do the same thing for Ada95? I would certainly look
forward to such a product. IMHO, memory management is something that a
machine should do (whenever possible) -- freeing up humans to do things
which require more skill and creativity."

Well sentences that start "I have heard that" most often end with something
wrong at worst and misleading at best :-)

In fact it is impossible to provide a general garbage collector for typical
implementations of C++ (there simply is not enough runtime information around).
What you have heard about is conservative garbage collectors that make
the basic assumption that a block is dead if there is no word in memory that
*could* be a pointer to or into the block.

This assumption is (a) inadequate, as someone pointed out here recently,
the use of virtual origins can upset this assumption and result in blocks
being collected which are in use and (b) too strong, blocks that are not
in use can be held by integers that accidentally mimic pointers.

That being said, this kind of conservative garbage collection can work
quite well in some applications, and is of course equally applicable to
Ada 95 as it is to C++.

By the way, a little history. Ada was originally designed with the expectation
that garbage collection would be available in typical implementations. Look at
the description of pragma Controlled to get a feel for this. However, almost
no implementations provided GC. During the Ada 95 development effort I made
the suggestion that we at least "require" GC for the information systems
annex, but other people found this laughably unrealistic, and there was zero
support inside and outside the Ada 9X design group, DR's and ISO for such a
step. Note of course that Ada 95 certainly *permits* garbage collection, and
the design was carefully carried out to ensure that this is the case, but
there was no sympathy for trying to require it (the requirement of course
would be a somewhat wooly one, since GC is not something you can specify
formally, but there are plenty of other wooly requirements like this already.

It is possible that Java will reorient people's thinking regarding garbage
collection. However, there are some things to bear in mind.

1. There are significant efficiency issues that have to be faced. Of course
in an interpretive environment like JVM, these are completely swalled up by
the interpretive overhead in any case.

2. The mixture of GC with low level features like pointer mucking is a very
worrisome one, because anything that upsets the integrity of the pointer
structures can cause unimaginable chaos in a garbage collected environment.
(bitter experience debugging SPITBOL compilers remembered here :-)

3. The mixture of GC with real time continues to worry a lot of people. This
statement will of course bring a certain advocate of real time GC out of his
silence, but the fact is that Henry Baker has not managed to convince the
world on this point yet, despite a lot of effort on his part.

4. There are some worrisome interactions between garbage collection and
finalization that have to be sorted out, and between garbage collection
and other features, such as ATC.

[Robert Dewar]

Dave Jones says

"Garbage reduction works like this: When a type goes out of scope, all
instances of that type are deleted."

That of course is familiar, but I never heard the term garbage reduction
applied specifically to this technique. Obviously this technique does
reduce garbage in the informal sense, but do you have a reference for
the specific application of this as a technical term?

"Actually, Ada95 provides a pragma (pragma Controlled) to turn off garbage
collection. If the programmer can turn garbage collection on or off it is
transparent only if the programmer wants it to be."

You misunderstand the meaning of transparent here. What I mean is that GC has
no effect on the formal semantics. It is not possible to write a program whose
semantics is entirely described by the Ada 95 RM which determines whether or
not garbage collection is in effect

> Garbage
> collection has never made it into a mainstream language before for all
> sorts of reasons, but it seems quite possible
that java will change this.

Perhaps you wouldn't, but I would consider Lisp and Smalltalk to be
mainstream languages. In fact, I would guess that Smalltalk is at least
as popular as Ada

I was using mainstream to mean languages that have achieved very widespread
use such as Fortran, C and COBOL. I would consider none of the languages you
mention as mainstream in this sense, but Java has a good shot at qualifying!

[Robert Dewar]

Dave Jones says

"An excellent idea Robert -- except for one big problem: Engineers who are
trying to build reliable, commercial products don't generally like to use
proucts which are still in beta."

Then they surely will stay away from Java. Even the language design must
be considered to be still under test, let alone the implementation!

I'll tell you a little secret: whether something is in beta status has
very little to do with its quality. Microsoft has sometimes released
products as initial releases so full of bugs that they could not
even be reasonably considered to be ready for beta testing. On the other
hand, some products, such as the final beta versions of NT 4.0, were in
excellent shape in beta stage.

A lot of the reason that the Intermetrics product is still in beta status
is that it is incomplete, but even in its incomplete status, it still has
a lot more capability than a native Java compiler.

[Hannes Haug]

dave...@io.com writes:

> BTW: I have heard that, for C++, someone has written a garbage
> collector which can be added to almost any C++ program. Would it be any
> more difficult to do the same thing for Ada95? I would certainly look
> forward to such a product. IMHO, memory management is something that a
> machine should do (whenever possible) -- freeing up humans to do things
> which require more skill and creativity.

There are the free Boehm-Weiser Conservative Collector
http://reality.sgi.com/employees/boehm_mti/gc.html
and the commercial Great Circle collector
http://www.geodesic.com.

Some other pointers:
http://www.centerline.com/people/chase/GC/GC-faq.html
http://stork.ukc.ac.uk/computer_science/Html/Jones/gc.html
http://www.cs.utexas.edu/users/oops/papers.html
ftp://ftp.netcom.com/pub/hb/hbaker/home.html

-hannes

[Ed Falis]

Robert Dewar wrote:
>
>
> By subset, I simply meant a subset of the full language capabilities in the
> RM. There is nothing wrong with subsetting the language by leaving out the
> annexes if the application does not need the full language! I would
> certainly think that most people would think that "full language" meant
> everything in the RM, but you can use any term any way you want! Certainly
> for us, full language *does* mean all the capabilities in the RM.

Ed said:
>
> Don't you think you ought to be a little more careful about what you're
> writing between the lines? Or should we start slinging mud about the IDE
> capabilities of GNAT on various platforms as so mehow making it not a "real"
> Ada 95 compiler? Seems of simiar relevance and bogosity. How about lowering
> the BS level?
>
> Well since the idea of optional sections is new in Ada 95, I think it is
> important that everyone understand the issues here. TO me it is obfuscatory
> to claim you implement the full language and leave out important
> capabilities. Yes, these capabilities are optional from a formal
> point of view, e.g. for validation, but if you need the capabilities,
> then they are definitely not optional.
>
> As for "mud" slinging, the TSP salesfolks definitely emphasize what they
> feel is their superior IDE capabilities, and I don't think of it as mud
> at all. It's perfectly natural that different companies stress different
> aspects, and emphasize them. That's what competition is all about! In
> fact we regard the open GNAT environment as having advantages over IDE's
> for many people, since it is much easier to put together the tool set
> you want from standard tools. But that's something users have to decide
> for themselves!
>
> Robert Dewar
> Ada Core Technologies.

I'm not intending to beat a dead horse here, and I have no problem with up front
competition, or with different companies emphasising different aspects of an offer as
being more important. What I have a problem with is the kind of "spin" we've all become
familiar with from politics, where a term with certain connotations in a community
("subset" in this case) is IMPLICITLY redefined in order to cause people to associate
negative connotations with other people's offerings. And as far as I can see, this is
exactly what was happening in that post, complete with the plausible deniability of your
explicit "Oh well, I really meant "dah-dah-dah.." in the followup.

We're a small enough community, with enough external "challenges" that we can probably
afford to keep the quality of competition a little higher. That's my point, and I don't
really intend to say more.

[Larry Kilgallen]

In article <325FFB...@io.com>, dave...@io.com writes:
> Robert Dewar wrote:
>>
>> "Garbage collection, by itself, is significant enough for one to
>> seriously consider choosing Java over Ada for projects which do not
>> require low-level timing control.
>> "
>>
>> Nope, that does not make any sense. Any project for which Java is currently
>> suitable could equally well be done in Ada using the Intermetrics compiler
>> to JBC, which has identical garbage collection capability.
>

> An excellent idea Robert -- except for one big problem: Engineers who are
> trying to build reliable, commercial products don't generally like to use
> proucts which are still in beta.

If someone is convinced that the Intermetrics compiler will eventually
be released, it is conceivable they could start development now.
Reliability requirements for inhouse development are generally
lower than for fielding an application.

Larry Kilgallen

[Larry Kilgallen]

In article <dewar.845149842@merv>, de...@merv.cs.nyu.edu (Robert Dewar) writes:

> I would personally like to see all the Ada 95 compilers implement all the
> annexes, except in cases where it makes no sense (I don't think the Patriot
> compiler needs to compute payrolls using the information systems annex :-).
> That's because I think the semantics in the distribution annex and the other
> special needs annexes greatly increase the semantic power of the language.

I imagine all Ada fans would like that ultimately, but for many
of us there are higher priority deliverables in areas such as
ease-of-use, code efficiency, etc. from compiler implementors.

I don't care about any annex until I need to use it :-)

Larry Kilgallen

[Norman H. Cohen]

Mitch Gart wrote:

> Ada package notation makes it worse:
>
> pkg1.func(obj, param);
>
> can really call the code in the body of pkg2, instead of pkg1, if there is
> dispatching. To me in this case the Ada syntax is lying to the person who
> is reading the program. It makes the code hard to read correctly in my opinion.

This is the wrong way to think about it. pkg1.func, called with a
classwide argument, is a polymorphic subprogram that is introduced in
pkg1.

The dispatching is part of the implementation of the polymorphic
subprogram, not part of its interface. When manipulating an object
through a classwide view, one should, in most circumstances, not be
concerned with the specific type of the object. From the caller's level
of abstraction, a dispatching call on pkg1.func is invoking the
polymorphic interface declared in pkg1. The fact that the polymorphic
behavior may implemented by dispatching to a body in pkg2 should be
irrelevant to the caller.

A comment in pkg1 should specify the behavior of func in general terms
that will apply to all future overridings of func. That is, when func
is overridden, the overriding subprogram should satisfy the
specifications of pkg1.func (and possibly additional specifications as
well). When calling pkg1.func, the caller should rely only on the more
general specifications that apply to pkg1.func and ALL its overridings.

--
Norman H. Cohen
mailto:nco...@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

[Mitch Gart]

Robert Dewar (de...@merv.cs.nyu.edu) wrote:
: Mitch says

: "To me the Ada is less readable, you have to look up the function's declaration
: and the parameter's type declaration and think a little bit to know whether the
: call is dispatching or not. Also the Java notation is more indicative of what
: is really going on in the program: the function is attached to the object and
: the function that will be called depends on the object."

: I really don't know why Mitch is cycling out this old argument, he does
: not seem to have anything new to say.

Because a person previously posted an opinion that Ada is much more readable
than Java. I gave what I thought (and still think) is a good counterexample.

: Which you prefer to look at is certainly a matter of opinion, and you

: really can't go much further on that than stating your opinion.

In most cases Ada is a lot more readable than C. Somebody could say "this
is just a matter of opinion, from somebody who likes Ada and doesn't like C"
but I don't think so. If somebody did an objective study I predict they would
be able to prove or strongly support the conclusion that Ada is more readable
than C. In this particular case, I also think it goes beyond a personal opinion,
I think the Ada notation

pkg1.func(obj)

is actively misleading when the code that will be executed at runtime is in the
body of pkg2. It's not just "Which you prefer to look at".

- Mitch

[Brian Rogoff]

Dave <da...@gte.net> writes:
Brian Rogoff wrote:
> While I agree with you that Java is mostly an improvement over C++, and
> I rather like it as a language, I don't see too many advantages that
> Java has over Ada. Garbage collection is a big one, but some would
> disagree.
<snip>
> I'm curious, what are the advantages that the Java language has over
> Ada 95, in your opinion?
>

Garbage collection, by itself, is significant enough for one to

seriously consider choosing Java over Ada for projects which do not
require low-level timing control.

Maybe, but IMO its other features are significant enough for it to compensate
for its 'deficiencies', where here I assume that lack of standard GC is a
deficiency. As I said, I generally like GC, and find that I am more productive
with it, but Ada does not have many of the weaknesses that make programming in
C or C++ so painful. We shall likely see more Ada implementations with garbage
collection in the future, in addition to the one that exists now, so I am
not too troubled by this.

Incidentally, I strongly disagree with your point about choosing Java over Ada
for any non-"low-level-timing-control" project. Java is a work-in-progress.
Native code compilers are scarce, and will take a long time to mature. And on
the purely "linguistic" side, no generics yet. This is a pain for me, because
I use generics a lot.

<snip>

Personally, however, Java would not be my first choice among languages
with garbage collectors. According to the data that I have seen, Eiffel
is an inherently more productive language than Java, and, like Ada, it
has a wide variety of features to promote "error-free" programming. (Of
course, Java does have an advantage in that it has better third party
support than Eiffel.)

Hey, if you want to kidnap the thread, you ought to rename it to "Eiffel vs
Ada 95" ;-). And I think that one has been done to death already. I personally
like having *packages* in addition to types. Eiffelists like to just have
classes, but then have LACE or CECIL or whatever in addition. You can have it.
I do like Eiffel's assertions though.

-- Brian

[Bevin R. Brett]

In article <326257...@watson.ibm.com>, "Norman H. Cohen" <nco...@watson.ibm.com> writes...

[Keith Thompson]

In <JSA.96Oct11152501@alexandria> jsa@alexandria (Jon S Anthony) writes:
[...]

> But *languages* don't have GC. Implementations of them do. Even
> Meyer says little about GC in ETL - just that all *implementations*
> are *expected* to have it.

That's not *quite* correct. It's admittedly difficult to define
garbage collection in a formal language definition, but the Java
definition at least attempts to do so. Here's paragraph 20.16.9
of The Java Language Specification, version 1.0 (available at
<http://java.sun.com/doc/language_specification.html>).

20.16.9 public void gc()

Calling this method suggests that the Java Virtual Machine expend
effort toward recycling discarded objects in order to make the
memory they currently occupy available for quick reuse. When
control returns from the method call, the Java Virtual Machine
has made a best effort to recycle all discarded objects. (The
name gc stands for "garbage collector.")

The Java runtime system will perform this recycling process
automatically as needed, in a separate thread, if the gc method
is not invoked explicitly.

See also the method gc (§20.18.12) of class System, which is
the conventional and convenient means of invoking this method.

This does refer to the "Java Virtual Machine", but I don't think there's
any requirement that the JVM be implemented via the usual byte code
interpreter. Even for a Java compiler that generates machine code
directly, the runtime system has to provide a JVM implementation as
specified in the language specification. I think.

I don't believe that Java even defines a way to explicitly deallocate
a specified piece of memory, like Ada's Unchecked_Conversion or C++'s
free().

The Eiffel language definition recommends garbage collection but does
not mandate it. As far as I know, all existing Eiffel implementations
do provide automatic garbage collection.

In another article, Robert Dewar wrote, "The whole point of gc is that
it has no semantics, it is transparent!" I don't think that's quite
true either. For example, consider the following Ada program:

with System;
with Ada.Text_IO; use Ada.Text_IO;
procedure GC_Test is
type Pointer is access Integer;
P : Pointer;
begin
for I in 1 .. System.Memory_Size loop
P := new Integer;
end loop;
Put_Line("The system has garbage collection");
exception
when Storage_Error =>
Put_Line("The system does not have garbage collection");
end GC_Test;

For simplicity, I've assumed here that System.Memory_Size fits in an
Integer and that the compiler doesn't optimize out the allocation in
the loop; there are ways around that.

It's true that garbage collection is semantically transparent for
well-behaved programs (i.e., ones that wouldn't otherwise run out of
memory and don't try to play certain nasty tricks).

--
Keith Thompson (The_Other_Keith) k...@thomsoft.com <*>
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-2706
FIJAGDWOL

[Keith Thompson]

In <326003...@gte.net> Dave <da...@gte.net> writes:
> Garbage reduction works like this: When a type goes out of scope,
> all instances of that type are deleted.

Neither the Ada RM nor any other literature I've seen uses the term
"garbage reduction" in this context. A web search for the phrase
turned up 6 references, all of them having to do with trash collection.
This may explain why people are confused by your use of the term.

In any case, it's not true that all instances (objects) of a type are
necessarily deleted when a type goes out of scope. In practice, an
object created by a declaration, either as a standalone object or as
a (sub)component of another standalone object, will almost always be
deallocated on exit from the scope declaring the object; if the scope
is a declare block, the deallocation may wait until exit from the
enclosing subprogram. An object created by an allocator may or may
not be deallocated on exit from the scope declaring the access type.
None of this is mandated by the language.

> Actually, Ada95 provides a pragma (pragma Controlled) to turn off garbage
> collection. If the programmer can turn garbage collection on or off it is
> transparent only if the programmer wants it to be.

Note that pragma Controlled has no effect for systems that don't provide
automatic garbage collection. What "transparent" means is that the
visible behavior of most programs will be the same whether garbage
collection is provided or not.

[Brian Rogoff]

s...@houdini.camb.inmet.com (Tucker Taft) writes:
Dave (da...@gte.net) wrote:

: Garbage collection, by itself, is significant enough for one to

: seriously consider choosing Java over Ada for projects which do not
: require low-level timing control.

: Garbage collection greatly increases developer productivity and greatly
: reduces error counts. Except for hard real-time systems, it is, IMHO,
: very unwise to choose a language without a garbage collector when a
: language with a garbage collector is available.

For what it's worth, our AppletMagic(tm) Ada95 => Java byte-code
compiler gives you Java's garbage collection, along with Ada's many
compile-time advantages, such as enumeration types, strongly distinguished
numeric and array types, generic templates, separate spec and body,
in/out/in-out parameter modes, named parameters in calls, etc.

To which I would add "hierarchical package system", though I'm sure someone
out there must feel that this is also bad! This would approximate my short
list of Ada advantages over Java. Besides GC, which is arguable, no one has
listed any *language* advantages of Java over Ada.

-- Brian

[Ken Garlington]

Mitch Gart wrote:
>
> In this particular case, I also think it goes beyond a personal opinion,
> I think the Ada notation
>
> pkg1.func(obj)
>
> is actively misleading when the code that will be executed at runtime is in the
> body of pkg2. It's not just "Which you prefer to look at".

Note that this can occur in Ada 83, or for that matter other non-dispatching
languages. For example:

with Foo;
package body Pkg1 is
function func ( op : a_type ) return func_type is
begin
return Foo.Some_Other_Function(op);
end;
end;

So, the call to func in fact causes some other code to be executed at runtime.
In fact, with a good optimizer, the caller of func may in fact end up with
a direct call to Some_Other_Function in the object code. So, if you want to make
these calls explicit, you have to have a coding convention (in Ada, FORTRAN, C, etc.)
that prohibits such "wrappers".

Of course, as you pointed out earlier, you can eliminate the "confusion" of
dispatching by removing the package name via a use clause. If you've read some coding
standard that says "don't use Ada in this manner," and you choose to follow
that standard, that's your problem -- not the language!

>
> - Mitch

--
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

[Jon S Anthony]

In article <325FFB...@io.com> dave...@io.com writes:

> Robert Dewar wrote:
> >
> > "Garbage collection, by itself, is significant enough for one to
> > seriously consider choosing Java over Ada for projects which do not
> > require low-level timing control.
> > "
> >

> > Nope, that does not make any sense. Any project for which Java is currently
> > suitable could equally well be done in Ada using the Intermetrics compiler
> > to JBC, which has identical garbage collection capability.
>
> An excellent idea Robert -- except for one big problem: Engineers who are
> trying to build reliable, commercial products don't generally like to use
> proucts which are still in beta.

Hmmm, it would appear that you don't know Java as well as you might
think. The whole thing is basically in beta. Certainly the JVM
spec. available at the Sun Java web site specifically states this. So, I suppose you wouldn't want to use _any_ thing "Java"...

/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
j...@organon.com

[Mitch Gart]

: Jon asks

: "Do any Java "the language" implementations exsit which do not target
: the JVM? I don't know of any, but maybe there are? If not, this GC
: argument is just irrelevant. If Java means JVM, and you want that
: (for whatever reason) then using Ada in this context will also give
: you GC simply because the Ada->J implementations have GC (by using the
: JVM GC - just like the JTL impl does)"

Java is also supposed to be usable for embedded systems. From what I know
of the JVM it is implementatble in embedded systems with no major problems,
except for GC. IMHO the Java community is in a bit of a bind because:

- the language and its libraries are designed assuming that the runtime has GC

- GC is difficult in embedded systems for many reasons

In the next few months I will be very interested to see how this problem is
addressed.

- Mitch Gart

[Brian R. Hanson]

Robert Dewar wrote:
>
> Jon asks
>
> "Do any Java "the language" implementations exsit which do not target
> the JVM?

> Someone has done a front end for gcc, I don't know how usable it is. But
> more importantly several big companies are producting real Java compilers
> as oppposed to interpretive systems using JVM. Clearly this is an expected
> development. JVM is fine for a limited set of applications, but real
> compilers for Java will greatly increase the possible range of applications.

Does the work someone did for gcc also provide some sort of gc?

-- Brian Hanson
-- b...@cray.com

[Jon S Anthony]

In article <325FF8...@io.com> dave...@io.com writes:

> However, suppose you were in the position of a software engineer who
> needed to choose between Java and Ada. Suppose also that garbage
> collection was high on your list of "must haves". Well, you could wait
> until Intermetric's Applet Magic gets out of beta (and becomes available
> on your platform).

Since *Java* is beta, that should either a) eliminate Java (and thus
AdaMagic as well) or b) be irrelevant. I mean the JVM is a beta
spec., so all the JVMs out there may not even be Java in another 6
months (shades of C++)! In reality, this is probably overly dramatic,
but you get the idea.

> Or you could pay someone to write an add-on garbage collector for
> your compiler and hope that they finish on-time. Or you could get a
> Java (or Eiffel or Smalltalk or Lisp) system and start working now.

Well, not Java - not if you are worried about "beta" sw.

> If you were in this situation, then from your viewpoint, it might make
> sense to say that Java has garbage collection and Ada does not.

Nope. Not even a little sense. Since it depends on Java not being
"beta", it makes absolutely no sense.

> garbage collection. *** The world would be a much better place if we
> would all express ourselves with greater clarity and precision, so
> thanks to Jon -- and everyone else -- for pointing out my error. ***

Hey, you're welcome! :-)

> BTW: I have heard that, for C++, someone has written a garbage
> collector which can be added to almost any C++ program. Would it be any
> more difficult to do the same thing for Ada95?

There are a "few". And, for example, the Boehm collector should work
about as well on Ada95 (say GNAT, in particular) as it does on C++
impls. I think I recall a discussion of this particular point on the
GC mail list.

> I would certainly look forward to such a product. IMHO, memory
> management is something that a machine should do (whenever possible)
> -- freeing up humans to do things which require more skill and
> creativity.

Sounds about right to me.

[Jon S Anthony]

In article <dewar.845162841@merv> de...@merv.cs.nyu.edu (Robert Dewar) writes:

> GC. During the Ada 95 development effort I made the suggestion that
> we at least "require" GC for the information systems annex, but
> other people found this laughably unrealistic, and there was zero
> support inside and outside the Ada 9X design group, DR's and ISO for

I've seen you mention this before. It is depressing. Putting it in
an annex of its own would probably have been even nicer (and from what
you say, even less likely). Really. This is a pretty sad and
incomprehensible story.

> such a step. Note of course that Ada 95 certainly *permits* garbage
> collection, and the design was carefully carried out to ensure that
> this is the case, but there was no sympathy for trying to require it
> (the requirement of course would be a somewhat wooly one, since GC
> is not something you can specify formally, but there are plenty of
> other wooly requirements like this already.

Just the sort of thing that would have fit in an annex rather nicely.
Implementations that supported it could have said they support Annex
such-and-such and everyone would have had a reasonably good idea of
what it meant and required. Those that didn't want it, could simply
not use it - or even get implementations that did not provide it.

> 4. There are some worrisome interactions between garbage collection and
> finalization that have to be sorted out, and between garbage collection
> and other features, such as ATC.

Yes, this is definitely an issue...

[Jon S Anthony]

In article <dewar.845147148@merv> de...@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon asks
>
> "Do any Java "the language" implementations exsit which do not target

> the JVM? I don't know of any, but maybe there are? If not, this GC
> argument is just irrelevant. If Java means JVM, and you want that
> (for whatever reason) then using Ada in this context will also give
> you GC simply because the Ada->J implementations have GC (by using the
> JVM GC - just like the JTL impl does)"
>

> Someone has done a front end for gcc, I don't know how usable it is. But
> more importantly several big companies are producting real Java compilers
> as oppposed to interpretive systems using JVM. Clearly this is an expected
> development. JVM is fine for a limited set of applications, but real
> compilers for Java will greatly increase the possible range of applications.

Well, that certainly makes things more interesting. To be honest, I
didn't expect this so soon for various reasons.

[Robert Dewar]

Jon Anthony said "I've seen you mention this before. It is depressing. Putting it in an annex of its own would probably have been even nicer (and from what you say, even less likely). Really. This is a pretty sad and incomprehensible story." Not incomprehensible at all, it just means the world does not agree with you, or at least the world of people involved and interested in the Ada 95 design. When I argue for something, and everyone else disagrees, I don't go around mumbling "sad and incomprehensible", I just figure I was wrong! In this particular case, the feeling was that including GC in the IS annex would make the annex too difficult to implement, which, since it is optional, might be counter productive. There could have been an annex for GC, but no one was interested enough to suggest that, and if they had, I don't think it would have interested people enough to survive. Just because you want something in Ada and not many other people do does not mean the majority is wrong and you are right :-) Now, as I have noted before, I think Java may change people's attitude towards GC (in fact I think this is really the only interesting thing about Java that is really new). Note that in saying from a formal point of view that whether a language does or does not have GC, we are being a little too pedantic in one important respect. If you have a language like Algol-68 or (as far as I know, I am not an expert) Java, that has no way of explicitly freeing storage, then from a practical point of view, you have no way of implementing the language (assuming it does have dynmaic allocation explicitly or implicitly, without using garbage collection). To get a feel for the orginal intent in Ada (which was that typical implementations would have GC), note that although NEW is clearly a first class citizen in Ada, and is introduced early on in the RM, the corresponding FREE operation is buried in chapter 13 and given a disparaging name (unchecked_deallocation). Just as the thought was that most programs would not need to use unchecked conversion, the thought was that most programs would not need to use unchecked deallocatoin, because GC would be there. Well maybe this is a little overreaching :-)

[Dale Stanbrough]

> I don't believe that Java even defines a way to explicitly deallocate
> a specified piece of memory, like Ada's Unchecked_Conversion or C++'s
> free().

The Java LRM recommends

s = null;

to force the deallocation of items (at least i think it's "null"!)

Dale

[Robert A Duff]

In article <dewar.845340573@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:
>Not incomprehensible at all, it just means the world does not agree with
>you, or at least the world of people involved and interested in the Ada
>95 design. When I argue for something, and everyone else disagrees, I
>don't go around mumbling "sad and incomprehensible", I just figure I
>was wrong!
>
>In this particular case, the feeling was that including GC in the IS
>annex would make the annex too difficult to implement, which, since
>it is optional, might be counter productive.

It is true that few people pushed for GC during the Ada 9X process. But
one should remember that the people involved were primarily existing Ada
83 users. Somebody who thinks GC is extremely important would have
become an Eiffel, Lisp, Smalltalk, or whatever programmer long before
the Ada 9X project started.

Therefore, although existing Ada users may be perfectly happy without
GC, it might well be the case that non-Ada users would be attracted to
Ada if it had GC. All is not lost -- it may well happen that Ada will
have GC in a few years. (Several have pointed out that "having GC" is
an implementation issue. Correct, but I think one can reasonably define
"language X has GC" to mean "I am confident that all implementations of
language X now and in the future will have GC". In that sense, Lisp has
GC, but Ada does not (yet).)

- Bob

[Mitch Gart]

Brian Rogoff (rog...@sccm.Stanford.EDU) wrote:
: Besides GC, which is arguable, no one has

: listed any *language* advantages of Java over Ada.

Calling superclass methods is easy in Java and hard in Ada:

type parent_obj is tagged record ...;
type parent_ptr is access all parent_obj;
procedure p(param: access parent_obj);

type child_obj is new parent_obj with ...;
type child_ptr is access all child_obj;
procedure p(param: access child_obj);

now inside the child's p, to call the parent's p:

p(parent_obj(param.all)'access);

is the way to do it. Converting the pointer to parent_ptr won't work because
the call will dispatch back to the child. This ".all'access" trick is pretty
painful. In Java the keyword "super" does what's wanted:

super.p();

Calling the parent type's operation is common in OOP and is painful to code,
and read, in Ada.

- Mitch

[Brian R. Hanson]

This does not force the deallocation of the item. It removes a
reference so that it can be reclaimed at some point (if not otherwise
referenced). A common problem when coding in the presence of GC is
leaving a dangling reference so some unneeded item preventing it from
being reclaimed. It is most unfortunate if it is the head of a very
large list or tree.

[Brian Rogoff]

jsa@alexandria (Jon S Anthony) writes:

rog...@sccm.Stanford.EDU (Brian Rogoff) writes:

> I rather like it as a language, I don't see too many advantages that
> Java has over Ada. Garbage collection is a big one, but some would
> disagree.

I don't disagree that GC is great in most circumstances. I disagree that
Java has it and Ada does not in any current environment where Java "the
language" is implemented. So, Java having GC in this context is just
plain irrelevant.

Yes, I am being a bit sloppy here. I think it is fairly safe to say though
that no one would accept a Java without GC as being "Java (TM)", whereas
an Ada 95 compiler sans GC would still be Ada 95. So in this fuzzy sense,
I think we can agree that Java has it, Ada doesn't. If in a few years, most
Ada 95 compilers have GC, or if there is a way to provide a decent GC
capability as a library and it gets widely used, then this would change.

In any case, others have also pointed out that many of Ada's other features
compensate for the lack of GC. And as I do not work in real-time or embedded
systems, I am not qualified to discuss the merits of RTGC, so I defer to the
wisdom of others, who clearly don't want it forced on them.

> Simplicity of the threading model might be another.

It's way too primitive and low level. Some seem to think of this as
simply "simpicity"...

Here I agree, though I think Ada tasking could have been simpler and more
powerful. Backwards compatibility with Ada 83 and all that I suppose. I
hope future revisors will be given a little more room to change things.

> I'm curious, what are the advantages that the Java language has over
> Ada 95, in your opinion?

Hype and buzz and the fact that "sheep look up".

Now, now! I could say "widespread commercial support, and market acceptance"
too. These are certainly good reasons to use Java, but I specifically excluded
them from my question.

Technically? Nothing.

That's what I think too, but I wanted to know if mg thought there was
something important. If it is Java being Object.Method(Arg1,...,ArgN) versus
Method(..., ArgJ'Class, ...), that won't count to me either ;-). I suppose
we could dig up the mutually recursive interpackage types argument again,
but I don't know if I could stand it!

-- Brian

[Mike Stark]

Brian Rogoff wrote:
>
> s...@houdini.camb.inmet.com (Tucker Taft) writes:

> Dave (da...@gte.net) wrote:
>
> : Garbage collection, by itself, is significant enough for one to
> : seriously consider choosing Java over Ada for projects which do not
> : require low-level timing control.
>

> : Garbage collection greatly increases developer productivity and greatly
> : reduces error counts. Except for hard real-time systems, it is, IMHO,
> : very unwise to choose a language without a garbage collector when a
> : language with a garbage collector is available.
>
> For what it's worth, our AppletMagic(tm) Ada95 => Java byte-code
> compiler gives you Java's garbage collection, along with Ada's many
> compile-time advantages, such as enumeration types, strongly distinguished
> numeric and array types, generic templates, separate spec and body,
> in/out/in-out parameter modes, named parameters in calls, etc.
>
> To which I would add "hierarchical package system", though I'm sure someone
> out there must feel that this is also bad! This would approximate my short

> list of Ada advantages over Java. Besides GC, which is arguable, no one has

> listed any *language* advantages of Java over Ada.
>

> -- Brian

To which I would add further the fact that Java requires all
user-defined
exceptions raised by a method to be defined as part of the interface
and caught by the client invoking the method (the "throws" keyword as
used in specifying member functions). Ada does not make the list of
exceptions raised by a subprogram part of the signature, let alone
requiring user-defined exceptions to be handled by the caller. This
alone is not a reason to say Java is better than Ada, but it is in-
accurate to say that there are no features where Java has the advantage.
BTW, I am also a fan of interfaces, as was said in another post within
this lengthy thread.

Mike

[Robert A Duff]

In article <ROGOFF.96O...@sccm.Stanford.EDU>,

Brian Rogoff <rog...@sccm.stanford.edu> wrote:
>To which I would add "hierarchical package system", though I'm sure someone
>out there must feel that this is also bad! This would approximate my short
>list of Ada advantages over Java. Besides GC, which is arguable, no one has
>listed any *language* advantages of Java over Ada.

How about portability of arithmetic? In Java, int is always exactly 32
bits 2's complement. In Ada, Integer is whatever the machine supports.
And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or
I might get 8-bit arithmetic, or who-knows-what. In Java, 64-bit
integers are supported, and no more. In Ada, 64-bit integers are
supported by GNAT, but not by other compilers. A compiler could support
more, or less, according to its whim. Is "type T is range 1..10**10;"
legal? It is on *some* Ada compilers, but not others.

On the other hand, at least Ada notifies you of overflows -- in Java, it
just silently gets the wrong answer. (This is the C and C++ culture --
Java inherits much more than just syntax from that culture.)

- Bob

[Robert I. Eachus]

For the record:

with System;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;

with Ada.Text_IO; use Ada.Text_IO;
procedure GC_Test is

P: Unbounded_String := Null_Unbounded_String;
Mem_Size: Integer;
begin
if System.Memory_Size >= Integer'Last
then Mem_Size := Integer'Last;
else Mem_Size := Integer(System.Memory_Size);
end if;
Put_Line(" Mem_Size set to " & Integer'Image(Mem_Size));

for I in 1 .. Mem_Size loop
P := To_Unbounded_String(Integer'Image(I));
if I mod 100_000 = 0
then Put_Line(" At I = " & To_String(P));
end if;
end loop;
Put_Line("The system has garbage collection.");
exception
when Storage_Error =>
Put_Line("The system is not legal Ada 95. " &
" It does not implement garbage collection.");
end GC_Test;

Is running in the background on this machine right now. (SunOS
4.1.3, gnat 3.05) Output to date is:

spectre% gc_test
Mem_Size set to 2147483647
At I = 100000
At I = 200000
At I = 300000
At I = 400000
...
At I = 4000000
At I = 4100000
At I = 4200000
At I = 4300000
At I = 4400000
At I = 4500000

I may leave it running overnight, but ps shows that memory use is
steady. Any questions? (To translate, Ada 95 has built in GC
required--but not for all types.)
--

Robert I. Eachus

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

[Mark A Biggar]

In article <1996Oct15.154148.1@eisner> kilg...@eisner.decus.org (Larry Kilgallen) writes:
>In article <DzBM79....@inmet.camb.inmet.com>, m...@dsd.camb.inmet.com (Mitch Gart) writes:
>> Brian Rogoff (rog...@sccm.Stanford.EDU) wrote:
>> : Besides GC, which is arguable, no one has

>> : listed any *language* advantages of Java over Ada.

>> Calling superclass methods is easy in Java and hard in Ada:
>> type parent_obj is tagged record ...;
>> type parent_ptr is access all parent_obj;
>> procedure p(param: access parent_obj);
>> type child_obj is new parent_obj with ...;
>> type child_ptr is access all child_obj;
>> procedure p(param: access child_obj);
>> now inside the child's p, to call the parent's p:
>> p(parent_obj(param.all)'access);
>> is the way to do it. Converting the pointer to parent_ptr won't work because
>> the call will dispatch back to the child. This ".all'access" trick is pretty
>> painful. In Java the keyword "super" does what's wanted:
>> super.p();
>> Calling the parent type's operation is common in OOP and is painful to code,
>> and read, in Ada.

>Presuming a long body for the child, that Ada code potentially must
>be altered in many places if the immediate parent changes. At least
>the whole body of code must be inspected if the "quiesce" method is
>to invoke the "quiesce" method of the immediate parent, whatever that
>may be this month. Some have argued that one should not insert new
>generations without reviewing all such code, but for some orderly
>environments I claim it is quite reasonable to count on coding
>standards having been followed.
>Macintosh Object Pascal does this with an "inherited" keyword.

There is a simple way to handle the change of immediate super parent in the
above. Take the above example: if you wanted to drop an imtermediate type
in between parent_obj and child_obj two things must tbe changed: the
declaration of child_obj must be changed to mention the new intermediate type
and the body of the child version of p must be changed to mention the
new intermediate type. Note that you must do the first of these in any case,
but the second can be avoided (assuming you know ahead of time that you may
want to make a change like this by writing the example like so:

type parent_obj is tagged record ...;
type parent_ptr is access all parent_obj;
procedure p(param: access parent_obj);

...
subtype super is parent_obj;
type child_obj is new super with ... ;

type child_ptr is access all child_obj;
procedure p(param: access child_obj);

and then write the redispatch call in the child version of p as:

p(super(param.all)'access);

Now to drop in an imtermediate type the only change you have to make to
the child code is to redefine the subtype super.

Although a attribute for tagged types 'SUPER would have made this a lot easier.

--
Mark Biggar
m...@wdl.lmco.com

[Larry Kilgallen]

In article <DzBKK...@world.std.com>, bob...@world.std.com (Robert A Duff) writes:

> Therefore, although existing Ada users may be perfectly happy without
> GC, it might well be the case that non-Ada users would be attracted to
> Ada if it had GC. All is not lost -- it may well happen that Ada will
> have GC in a few years. (Several have pointed out that "having GC" is
> an implementation issue. Correct, but I think one can reasonably define
> "language X has GC" to mean "I am confident that all implementations of
> language X now and in the future will have GC". In that sense, Lisp has
> GC, but Ada does not (yet).)

It seems to me, therefore, that "has GC" does not belong in the standard
or in an annex any more than "has an optimizing back end". Standards
must leave some areas for implementors to differentiate themselves,
or else one will be stuck like Unix or HTML with each implementor
striving to add their own source-incompatible "added-value" extensions
thereby undercutting the standard. GC, peephole optimizers, and the
like can all be left unstandardized without harm to source portability.

Larry Kilgallen

[Larry Kilgallen]

In article <DzBrF...@world.std.com>, bob...@world.std.com (Robert A Duff) writes:
> In article <ROGOFF.96O...@sccm.Stanford.EDU>,
> Brian Rogoff <rog...@sccm.stanford.edu> wrote:
>>To which I would add "hierarchical package system", though I'm sure someone
>>out there must feel that this is also bad! This would approximate my short

>>list of Ada advantages over Java. Besides GC, which is arguable, no one has

>>listed any *language* advantages of Java over Ada.
>

> How about portability of arithmetic? In Java, int is always exactly 32
> bits 2's complement. In Ada, Integer is whatever the machine supports.
> And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or
> I might get 8-bit arithmetic, or who-knows-what.

And why should it matter ? If your specification is to cover that
range, a compiler is meeting that specification even if it converts
it to BCD to accomplish it on some _very_ old hardware.

Larry Kilgallen

[Robert Dewar]

Robert Duff said

"How about portability of arithmetic? In Java, int is always exactly 32
bits 2's complement. In Ada, Integer is whatever the machine supports.
And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or

I might get 8-bit arithmetic, or who-knows-what. In Java, 64-bit
integers are supported, and no more. In Ada, 64-bit integers are
supported by GNAT, but not by other compilers. A compiler could support
more, or less, according to its whim. Is "type T is range 1..10**10;"
legal? It is on *some* Ada compilers, but not others.

On the other hand, at least Ada notifies you of overflows -- in Java, it
just silently gets the wrong answer. (This is the C and C++ culture --
Java inherits much more than just syntax from that culture.)"

That seems a bit confused. You get portable arithmetic in Ada by specifying
the range. That gives you completely portable arithmetic, certainly up to
32 bits in practice. If you say type T is range 1 .. 100, then it does not
matter if you get 8 bit or 32 bit arithmetic if you avoid overflowing this
range. As you note, in Java overflows are ignor3ed in any case. So to get
EXACTLY the equivalent of the Java int semantics, we do

type int is range - 2 ** 31 .. + 2 ** 31 - 1;

sure, a compiler can give you more than 32 bits, but providing you avoid
overflow that is irrelevant, and if you have overflow, then Java arithemtic
would also be undefined.

[Robert Dewar]

Robert Eachs says

" More of a confirmation if anything... The result of other
decisions was that Ada 95 did not require GC, but it did require all
compilers to support an unbounded string type that is (implicitly)
required to be garbage collecting (see A.4.5(88)). Most of us
considered this to be a good trade: no distributed overhead, and the
one type where GC was necessary provided with GC."

Well I am not sure I agree, the type Unbounded String is typically
implemented using a controlled type with a finalization routine that
frees it, but this does not mean that all unreachable unbounded strings
are in fact collected, becuase they may well be referenced from other
structures that are themselves not collected.

[Robert I. Eachus]

In article <dewar.845340573@merv> de...@merv.cs.nyu.edu (Robert Dewar) writes:

> In this particular case, the feeling was that including GC in the IS
> annex would make the annex too difficult to implement, which, since
> it is optional, might be counter productive.

> There could have been an annex for GC, but no one was interested enough

> to suggest that, and if they had, I don't think it would have interested
> people enough to survive.

> Just because you want something in Ada and not many other people do does
> not mean the majority is wrong and you are right :-)

More of a confirmation if anything... The result of other

decisions was that Ada 95 did not require GC, but it did require all
compilers to support an unbounded string type that is (implicitly)
required to be garbage collecting (see A.4.5(88)). Most of us
considered this to be a good trade: no distributed overhead, and the
one type where GC was necessary provided with GC.

--

[Robert Dewar]

Mike Stark says

"used in specifying member functions). Ada does not make the list of
exceptions raised by a subprogram part of the signature, let alone
requiring user-defined exceptions to be handled by the caller. This
alone is not a reason to say Java is better than Ada, but it is in-
accurate to say that there are no features where Java has the advantage."

Yes, but of course this omission is quite deliberate in the Ada design. This
is certainly something that is different in the two languages. Ada quite
deliberately omitted this feature, because it potentially means that small
changes to a single low level procedure can percolate up to affect specs
all over the place!

Any place that Ada and Java differ, someone will prefer the way that Ada
does it, and someone will prefer the way that Java did it. So you can't
say that one language or the other does or does not have advantages. Too
subjective!

[Larry Kilgallen]

In article <DzBM79....@inmet.camb.inmet.com>, m...@dsd.camb.inmet.com (Mitch Gart) writes:
> Brian Rogoff (rog...@sccm.Stanford.EDU) wrote:

> : Besides GC, which is arguable, no one has

> : listed any *language* advantages of Java over Ada.
>

> Calling superclass methods is easy in Java and hard in Ada:
>
> type parent_obj is tagged record ...;
> type parent_ptr is access all parent_obj;
> procedure p(param: access parent_obj);
>
> type child_obj is new parent_obj with ...;
> type child_ptr is access all child_obj;
> procedure p(param: access child_obj);
>
> now inside the child's p, to call the parent's p:
>
> p(parent_obj(param.all)'access);
>
> is the way to do it. Converting the pointer to parent_ptr won't work because
> the call will dispatch back to the child. This ".all'access" trick is pretty
> painful. In Java the keyword "super" does what's wanted:
>
> super.p();
>
> Calling the parent type's operation is common in OOP and is painful to code,
> and read, in Ada.

Presuming a long body for the child, that Ada code potentially must
be altered in many places if the immediate parent changes. At least
the whole body of code must be inspected if the "quiesce" method is
to invoke the "quiesce" method of the immediate parent, whatever that
may be this month. Some have argued that one should not insert new
generations without reviewing all such code, but for some orderly
environments I claim it is quite reasonable to count on coding
standards having been followed.

Macintosh Object Pascal does this with an "inherited" keyword.

Larry Kilgallen

[Lars Farm]

Larry Kilgallen <kilg...@eisner.decus.org> wrote:

> It seems to me, therefore, that "has GC" does not belong in the standard
> or in an annex any more than "has an optimizing back end". Standards
> must leave some areas for implementors to differentiate themselves,
> or else one will be stuck like Unix or HTML with each implementor
> striving to add their own source-incompatible "added-value" extensions
> thereby undercutting the standard. GC, peephole optimizers, and the
> like can all be left unstandardized without harm to source portability.

No! There must be a way to prevent programs that rely on GC from beeing
accepted by a compiler that does not support GC. The designs will be
different. GC may well be optional, but there must be a standard way to
detect at compiletime that "Error at line 534: Sorry, GC is an optional
and not implemented feature, please buy a compiler from one of our
competitors instead". Otherwise you can not trust your own program and
you can not share your code with others. It might compile and work on
one compiler, but compile and fail miserably on another. This is
something that I thought would be considered absolutely unacceptable for
Ada;-) GC is certainly not just an optimization. GC affects design.

The nice thing is that a program written without knowledge of GC will
work even if GC is present. At least as much as a program is now
portable between different compilers and OS. A program designed with GC
in mind will not function without GC, so there must be a way to prevent
such a program from compiling where GC is unavailable.

--
Lars Farm, lars...@ite.mh.se

[Robert A Duff]

In article <1996Oct15.174526.1@eisner>,

Larry Kilgallen <kilg...@eisner.decus.org> wrote:
>In article <DzBrF...@world.std.com>, bob...@world.std.com (Robert A Duff) writes:

>> How about portability of arithmetic? In Java, int is always exactly 32
>> bits 2's complement. In Ada, Integer is whatever the machine supports.
>> And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or
>> I might get 8-bit arithmetic, or who-knows-what.
>

>And why should it matter ? If your specification is to cover that
>range, a compiler is meeting that specification even if it converts
>it to BCD to accomplish it on some _very_ old hardware.

type T is range 1..100;
X: T := ...;
Y: T := ...;
Average: T := (X + Y) / 2;

Because the above code will work fine on some Ada compilers, and blow up
on others (the addition will overflow using 8-bit signed arithmetic) if
X and Y happen to be, say, 99. In Java, the above code is guaranteed to
work.

- Bob

[Robert Dewar]

Lars said

No! There must be a way to prevent programs that rely on GC from beeing
accepted by a compiler that does not support GC. The designs will be
different. GC may well be optional, but there must be a standard way to
detect at compiletime that "Error at line 534: Sorry, GC is an optional
and not implemented feature, please buy a compiler from one of our
competitors instead". Otherwise you can not trust your own program and
you can not share your code with others. It might compile and work on
one compiler, but compile and fail miserably on another. This is
something that I thought would be considered absolutely unacceptable for
Ada;-) GC is certainly not just an optimization. GC affects design.

You thought wrong. There are many implementation dependent aspects of
Ada compilers that affect design (just one of many examples: whether
or not mutable variant records are always assigned maximum size, another:
whether shared generics are implemented). Code that is required to be
portable must steer around such problems, GC would be just one more such
problem.

The nice thing is that a program written without knowledge of GC will
work even if GC is present. At least as much as a program is now
portable between different compilers and OS. A program designed with GC
in mind will not function without GC, so there must be a way to prevent
such a program from compiling where GC is unavailable.

Well of course you are talking about "real" GC here and not conservative
collectors, which, as we have discussed, can free blocks that are not
really free in some circumstances. Also conservative collectors definitely
have the possibility of generating programs that compile and work on one
compiler, and compile and fail miserably on another compiler, or even on
the same compiler later in the same day.

[Brian Rogoff]

da...@rmit.edu.au (Dale Stanbrough) writes:
" To which I would add "hierarchical package system", though I'm sure
someone out there must feel that this is also bad! This would approximate

my short list of Ada advantages over Java. Besides GC, which is arguable,

no one has listed any *language* advantages of Java over Ada."

I think Interfaces are a _very_ nice feature.

Dale, I think you may have got me! I don't think interfaces really add
anything that you can't do in Ada 95 with the access discriminant trick
(using a pointer to an containing type to parameterize a component; I think
Barnes has some examples of this in his excellent book), but they certainly
make one case of this a lot less work. The access discriminant trick also
allows more MI than do interfaces. Also, pure signature checking can be done
with generics, using generic formal package parameters.

So, while I think you can do (a lot) more with Ada 95, I agree that interfaces
are nice and convenient. I think they could only be considered an advantage if
it turned out that the style of programming that interfaces facilitate
constitute a very large fraction of programming compared to the Ada 95
facilities. Certainly my Java programs make heavy use of interfaces, in
particular implementations of the "Composite" pattern use interfaces rather
than abstract classes.

-- Brian

[Samuel T. Harris]

Jon S Anthony wrote:
>
> In article <325FFB...@io.com> dave...@io.com writes:

>
> > Robert Dewar wrote:
> > >
> > > "Garbage collection, by itself, is significant enough for one to
> > > seriously consider choosing Java over Ada for projects which do not
> > > require low-level timing control.
> > > "
> > >

> > > Nope, that does not make any sense. Any project for which Java is currently
> > > suitable could equally well be done in Ada using the Intermetrics compiler
> > > to JBC, which has identical garbage collection capability.
> >
> > An excellent idea Robert -- except for one big problem: Engineers who are
> > trying to build reliable, commercial products don't generally like to use
> > proucts which are still in beta.
>
> Hmmm, it would appear that you don't know Java as well as you might
> think. The whole thing is basically in beta. Certainly the JVM
> spec. available at the Sun Java web site specifically states this. So, I suppose you wouldn't want to use _any_ thing "Java"...
>

All the beta talk is making me dizzy
(in an alpha kind of way :)

The core of a application written with
AppletMagic can also be run/tested on
a validated Ada compiler producing
native code. This does present problems
in any areas where calls to any java.*
packaged provided by AppletMagic since
these do not exist in other Ada95
implementations. Fortunately, a project
I'm working on has a clear delineation
between the application itself and the
UI component, so I can proceed with the
hardest work with whatever compiler I
want and limit my "beta-risk" to just
the relatively simple UI component.

Other projects may not be so fortunate.
But variant code in the UI component
is nothing new. Ask anyone who codes
for Mac vs MS-Windows vs X-Windows.
In fact, applications which have a
loosely coupled UI component can have
a native portion and leave the UI in
the JVM.

From a distribution point of view in
the Ada95 world, technologies such
as AppletMagic are prime value-added
additions to the development environment.
It allows me to distribute any application
to anyone with access to a JVM. I can then
provide higher-performance native versions
of that application (with mostly the same
code) as customer needs (and their money)
justifies the effort.

Thus my supported environment list
would read ...

Platform X, OS Y, Windowing system Z
...
Anything with Netscape
Anything with MSIE
Anything with Appletviewer

--
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

[Mike Stark]

I agree that this is a subjective judgement. I think that it is a good
feature for designing safe and secure systems. In Ada systems I've
worked on, the exceptions raised were part of the commentary in a
package spec, and that is quite workable.

Mike

[Brian Rogoff]

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

In article <ROGOFF.96O...@sccm.Stanford.EDU>,
Brian Rogoff <rog...@sccm.stanford.edu> wrote:

>To which I would add "hierarchical package system", though I'm sure someone
>out there must feel that this is also bad! This would approximate my short
>list of Ada advantages over Java. Besides GC, which is arguable, no one has
>listed any *language* advantages of Java over Ada.

How about portability of arithmetic?

That's another, very minor IMO, advantage. The people who worry most about
this issue are doing systems or numeric programming. Java is unsuitable for
those applications in its current state anyways. For writing applets and such
stuff, the number sizes don't interest me too much. Of course it is important
so that the byte code can run on all machines, just not important to me when
I am coding in Java.

Also, this is really only an advantage when coding for the JVM. If you do
happen to work on one of those weird architectures for which the number sizes
may not be mapped well, an Ada compiler will not be hamstrung by this
restriction. This may be nitpicking though.

In Java, int is always exactly 32 bits 2's complement. In Ada, Integer is
whatever the machine supports. And if I say "type T is range 1..100;" I
might get 32-bit arithmetic, or I might get 8-bit arithmetic, or

who-knows-what. In Java, 64-bit integers are supported, and no more. In
Ada, 64-bit integers are supported by GNAT, but not by other compilers.

So, it is also a disadvantage, in that you can't have 128 bit integers :-).
Or you could, if you want them to be heap allocated, GC'ed beasties that
don't have standard math operators.

A compiler could support more, or less, according to its whim. Is "type T
is range 1..10**10;" legal? It is on *some* Ada compilers, but not others.

On the other hand, at least Ada notifies you of overflows -- in Java, it
just silently gets the wrong answer. (This is the C and C++ culture --
Java inherits much more than just syntax from that culture.)

In fact, as a non-technical advantage, Java's !@#$ing C-like syntax probably
overwhelms most of the technical advantages being discussed.

To be fair though, I'll count "portability of arithmetic" as a Java advantage.

-- Brian

[Brian Rogoff]

m...@dsd.camb.inmet.com (Mitch Gart) writes:
Brian Rogoff (rog...@sccm.Stanford.EDU) wrote:

: Besides GC, which is arguable, no one has

: listed any *language* advantages of Java over Ada.

Calling superclass methods is easy in Java and hard in Ada:

<snip>

Thanks Mitch. This is the best example I've seen so far. Interfaces are
second, although I think Ada allows you to do more, like write real mixins,
although it takes more work.

In the post that you wrote, which I responded to, you said that there were
numerous linguistic advantages of Java over Ada 95 (and vice versa!) so that
it was a toss-up in the choice between the two. I still think that is
incorrect, and that Java has few advantages over Ada 95. If "OO" is the only
style/paradigm that interests you, then those advantages may be more
compelling, since to get the same effect as Java the Ada will always be more
verbose, since you need to make your classes access types. However, I find
the virtue of Ada to be its multiparadigm nature, and the fact that it allows
high and low level programming. If there is to be an Ada 0X, I wouldn't want
it to be "just an OO language". Eiffel exists, and we all know where to find
it.

Calling the parent type's operation is common in OOP and is painful to
code, and read, in Ada.

- Mitch

This is a good example, and I am convinced (for now ;-).

Do you have any other examples? I've already noted that I don't agree that
obj.method() syntax is inherently better, and I disagree with your statement
that it is true in any sense that that syntax is more readable or
understandable. I think R. Dewar gave a good counterargument to that
statement.

-- Brian

[Jon S Anthony]

In article <1996Oct15.150155.1@eisner> kilg...@eisner.decus.org (Larry Kilgallen) writes:

> It seems to me, therefore, that "has GC" does not belong in the standard
> or in an annex any more than "has an optimizing back end". Standards
> must leave some areas for implementors to differentiate themselves,

This is not quite the same. An optimizer is not "user visible", but a
GC should indeed have various user visible hooks for specialized
needs. That is why an annex for it would have been appropriate (and a
damn good thing)! It also makes it somewhat more "official" that
implementations may well have it.

/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
j...@organon.com

[Jon S Anthony]

In article <EACHUS.96O...@spectre.mitre.org> eac...@spectre.mitre.org (Robert I. Eachus) writes:

> > Just because you want something in Ada and not many other people do does
> > not mean the majority is wrong and you are right :-)
>
> More of a confirmation if anything... The result of other
> decisions was that Ada 95 did not require GC, but it did require all
> compilers to support an unbounded string type that is (implicitly)
> required to be garbage collecting (see A.4.5(88)). Most of us
> considered this to be a good trade: no distributed overhead, and the
> one type where GC was necessary provided with GC.

Huh? No one is suggesting it be required. And the string thing is
the "one type where GC was necessary"??? Typically the types in need
of GC will be USER DEFINED.

[Jon S Anthony]

In article <dale-15109...@sambar.cs.rmit.edu.au> da...@rmit.edu.au (Dale Stanbrough) writes:

> I think Interfaces are a _very_ nice feature.

What makes you think the _capability_ is not available in Ada via
child packages?

[Jon S Anthony]

In article <DzBKK...@world.std.com> bob...@world.std.com (Robert A Duff) writes:

> In article <dewar.845340573@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:
> >Not incomprehensible at all, it just means the world does not agree with
> >you, or at least the world of people involved and interested in the Ada
> >95 design. When I argue for something, and everyone else disagrees, I
> >don't go around mumbling "sad and incomprehensible", I just figure I
> >was wrong!

> >
> >In this particular case, the feeling was that including GC in the IS
> >annex would make the annex too difficult to implement, which, since
> >it is optional, might be counter productive.
>

> It is true that few people pushed for GC during the Ada 9X process. But
> one should remember that the people involved were primarily existing Ada
> 83 users. Somebody who thinks GC is extremely important would have
> become an Eiffel, Lisp, Smalltalk, or whatever programmer long before
> the Ada 9X project started.

Precisely. The process was probably too "inbred".

> Therefore, although existing Ada users may be perfectly happy without
> GC, it might well be the case that non-Ada users would be attracted to
> Ada if it had GC.

Absolutely. I know of several cases where this isn't just theoretical!

> All is not lost -- it may well happen that Ada will have GC in a
> few years. (Several have pointed out that "having GC" is an
> implementation issue. Correct, but I think one can reasonably
> define "language X has GC" to mean "I am confident that all
> implementations of language X now and in the future will have GC".
> In that sense, Lisp has GC, but Ada does not (yet).)

Agreed.

[Jon S Anthony]

In article <dewar.845340573@merv> de...@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon Anthony said
>
> "I've seen you mention this before. It is depressing. Putting it in
> an annex of its own would probably have been even nicer (and from what
> you say, even less likely). Really. This is a pretty sad and
> incomprehensible story."

>
>
> Not incomprehensible at all, it just means the world does not agree with
> you, or at least the world of people involved and interested in the Ada
> 95 design. When I argue for something, and everyone else disagrees, I
> don't go around mumbling "sad and incomprehensible", I just figure I
> was wrong!

Well, if you can show me that I really am wrong about this, then I
will admit it. I do not believe that "everyone else disagrees" with
this. In fact, I would be surprised if most _potential_ users agreed
with me. Just because many (maybe even most) of the old users did not
think GC useful, does not in any way suggest that the large untapped
pool of users out there looking for something better than C/C++ rubish
would not have jumped for it. You are incorrectly generalizing from a
biased population.

> There could have been an annex for GC, but no one was interested enough
> to suggest that, and if they had, I don't think it would have interested
> people enough to survive.

As I suspected.

> Just because you want something in Ada and not many other people do does
> not mean the majority is wrong and you are right :-)

What "majority"? A few dozen people on a design review who took their
only comments from an existing user base? OK, maybe that's hyperbole
- but you have no sound basis on which to state "majority" here.

I see this may be a case where we are not seeing eye-to-eye :-)

> Now, as I have noted before, I think Java may change people's attitude
> towards GC (in fact I think this is really the only interesting thing
> about Java that is really new).

Well, as far as that goes, Ada95 could have played this role or at
least have been right there with it.

> If you have a language like Algol-68 or (as far as I know, I am not
> an expert) Java, that has no way of explicitly freeing storage, then
> from a practical point of view, you have no way of implementing the
> language (assuming it does have dynmaic allocation explicitly or
> implicitly, without using garbage collection).

Sure you do - it will just be a lousy implementation. Or maybe one
which is intended to never be used for any "real" applications. Just
leak away.

[Jon S Anthony]

In article <ROGOFF.96O...@sccm.Stanford.EDU> rog...@sccm.Stanford.EDU (Brian Rogoff) writes:

> Yes, I am being a bit sloppy here. I think it is fairly safe to say though
> that no one would accept a Java without GC as being "Java (TM)", whereas
> an Ada 95 compiler sans GC would still be Ada 95. So in this fuzzy sense,
> I think we can agree that Java has it, Ada doesn't. If in a few years, most
> Ada 95 compilers have GC, or if there is a way to provide a decent GC
> capability as a library and it gets widely used, then this would change.

Agree. This is why an annex on GC would have been nice. It would
have put at least some awareness on vendors that GC was "expected" in
a much stronger sense than in the current RM. But it would still have
been optional. Also, it could have regularized (standardized...) some
of the typical user visible bits.

> systems, I am not qualified to discuss the merits of RTGC, so I defer to the
> wisdom of others, who clearly don't want it forced on them.

The funny thing is, no one would be forcing it on them. This is the
same sort of goofy situation as occured for pragma Assert. Hey, a)
it's optional, b) if you don't want it, don't use it.

> > Simplicity of the threading model might be another.
>
> It's way too primitive and low level. Some seem to think of this as
> simply "simpicity"...
>
> Here I agree, though I think Ada tasking could have been simpler and more
> powerful. Backwards compatibility with Ada 83 and all that I suppose. I
> hope future revisors will be given a little more room to change things.

Agreed.

> > I'm curious, what are the advantages that the Java language has over
> > Ada 95, in your opinion?
>
> Hype and buzz and the fact that "sheep look up".
>
> Now, now! I could say "widespread commercial support, and market
> acceptance" too. These are certainly good reasons to use Java, but I
> specifically excluded them from my question.

:-)

> Technically? Nothing.
>
> That's what I think too, but I wanted to know if mg thought there
> was something important. If it is Java being
> Object.Method(Arg1,...,ArgN) versus Method(..., ArgJ'Class, ...),
> that won't count to me either ;-). I suppose we could dig up the
> mutually recursive interpackage types argument again, but I don't
> know if I could stand it!

Yes, there is indeed a good case of a real hole. Fortunately Tucker
is out saving the day on that one! :-)

[Jon S Anthony]

In article <EACHUS.96O...@spectre.mitre.org> eac...@spectre.mitre.org (Robert I. Eachus) writes:

> In article <JSA.96Oct11152501@alexandria> jsa@alexandria (Jon S Anthony) writes:
>
> > But *languages* don't have GC. Implementations of them do. Even
> > Meyer says little about GC in ETL - just that all *implementations*
> > are *expected* to have it.
>
> I think that the point that is getting lost in this discussion is
> that, if your compiler had a garbage collector, and a switch to turn
> it on or off, what switch position would you use?

On. Aside from those involved in various real-time circumstances, who
in their right mind wouldn't?

> For some languages the freedom from deallocation calls makes the
> answer a "no-brainer." Smalltalk, Lisp, and even C++ are much more
> useable with garbage collection. (It would also fix a LOT of C
> programs, but I digress.)
>
> However, in Ada, most cases where you have garbage problems in
> other languages simply don't exist. In particular, a function can

I disagree with this completely. Because most cases where a GC is
useful is in the context of _user defined_ types and these occur
pretty independent of language.

> function is completed, without explicit use of the heap. As long as
> compilers don't generate garbage for function returns, most of the
> need for GC goes away.

Wrong. There are many cases (boatloads of cases) where long lived
instances should be shared among users but when they all go away the
used object should also go away. Another is keeping various lists
around while a controlling agent needs the objects. When the
controlling agent (owner) goes away the lists should. Finalization
helps, but not in the general case. This is so common I can't
understand how you could ever make such a claim.

> The other case I often see is the complex data
> structure case where GC, especially conservative GC, is not the best
> cure.

??? Disagree (well, agree about the conservative bit).

> In Ada a well writen data structure such as a tree that cleans
> up after itself currently only has one drawback--the built-in cleanup
> still occurs at the end of the program.

But that drawback is the whole point. Having the cleanup occur at
program end is next to worthless for the vast majority of cases.

> The "extra" effort during
> implementation to get the garbage management correct is trivial. The
> last such package I wrote was about 1K lines, and maybe five were
> concerned with the deallocation process.

Too bad it doesn't do anything about the actual problem.

> So if I had an Ada compiler with a GC switch, I'd probably only
> turn it on for testing--of the compiler. ;-) Your milage may vary, but

Clearly, the type of programs you are writing are different from mine
and most people I've ever discussed the issue with. Perhaps you are
in the "real-time" arena.

> later freed by the OS--if you did everything correctly. The real-time
> world is exactly that forgiving, and GC is not really much help.
> (There are memory leaks which exist even if garbage is collected, so
> you need to be able to explicitly break reference chains.)

Ah. So you are in the real-time world. That's fine. But most
programs aren't.

[Jon S Anthony]

In article <Dz8zn...@thomsoft.com> k...@thomsoft.com (Keith Thompson) writes:

> In <JSA.96Oct11152501@alexandria> jsa@alexandria (Jon S Anthony) writes:
> [...]

> > But *languages* don't have GC. Implementations of them do. Even
> > Meyer says little about GC in ETL - just that all *implementations*
> > are *expected* to have it.
>

> That's not *quite* correct. It's admittedly difficult to define
> garbage collection in a formal language definition, but the Java
> definition at least attempts to do so. Here's paragraph 20.16.9
> of The Java Language Specification, version 1.0 (available at
> <http://java.sun.com/doc/language_specification.html>).
>
> 20.16.9 public void gc()
>
> Calling this method suggests that the Java Virtual Machine expend
> effort toward recycling discarded objects in order to make the
> memory they currently occupy available for quick reuse. When
> control returns from the method call, the Java Virtual Machine
> has made a best effort to recycle all discarded objects. (The
> name gc stands for "garbage collector.")
>
> The Java runtime system will perform this recycling process
> automatically as needed, in a separate thread, if the gc method
> is not invoked explicitly.
>
> See also the method gc (§20.18.12) of class System, which is
> the conventional and convenient means of invoking this method.
>
> This does refer to the "Java Virtual Machine", but I don't think there's
> any requirement that the JVM be implemented via the usual byte code
> interpreter.

But the point is that it is talking about the JVM, _not_ JTL. The JVM
is about a particular implementation. Moreover, "suggests", "expend
effort toward", "made a best effort", etc. sounds a lot like "expected
to have".

> Even for a Java compiler that generates machine code directly, the
> runtime system has to provide a JVM implementation as specified in
> the language specification. I think.

Where is this stated? Even if true, I don't see the relevance.

[Robert Dewar]

Bob Duff said

type T is range 1..100;

X: T := ...;
Y: T := ...;
Average: T := (X + Y) / 2;

Because the above code will work fine on some Ada compilers, and blow up
on others (the addition will overflow using 8-bit signed arithmetic) if
X and Y happen to be, say, 99. In Java, the above code is guaranteed to
work."

I am not sure I understand Bob's statement here. The above code is certainly
not valid Java code, so what does it mean to say that the above code works
in Java. If you mean it is possible to write this in a manner that works
in Java, then the same statement can be made in Ada:

type BT is range 1 .. 200;
subtype T is BT range 1 .. 100;

X : T := ...;
Y : T := ...;
Average : T := (X + Y)/2;

works fine. You can write invalid Ada code for anything, but doing so
does not prove anything!

[Robert Dewar]

"To be fair though, I'll count "portability of arithmetic" as a Java advantage."

Hmmm! I thought that Java left overflow undefined, I don't call that
portable!

[Robert A Duff]

In article <3264CC...@gsfc.nasa.gov>,

Mike Stark <michael...@gsfc.nasa.gov> wrote:
>I agree that this is a subjective judgement. I think that it is a good
>feature for designing safe and secure systems. In Ada systems I've
>worked on, the exceptions raised were part of the commentary in a
>package spec, and that is quite workable.

To me, it seems like Java's rules would end up requiring a whole lot of
"throws XXX" statements that lie, or bogus exception handlers that can
never be invoked. This is because the compile-time rules aren't really
very smart about what exceptions can *really* be raised.

An example of this shows up in the predefined streams stuff in Java.
I forget what they call it, but there's some sort of abstract class or
interface that represents streams of bytes, and you can do operations to
get the next byte and so forth. There's one subclass that represents
*file* streams, and file streams can raise various I/O exceptions. The
problem is that this fact percolates up, so that *all* streams claim
that they can raise (er, I mean, throw) I/O exceptions, when it's really
only streams attached to files that can raise those exceptions.
Why should I have to have a handler for I/O errors, when I'm reading
from an in-memory stream of bytes, that has nothing whatsoever to do
with I/O? And if somebody invents a new sort of stream, that can raise
new sorts of exceptions, they have to go back and modify some very
general class to say it can throw those exceptions, and modify all the
callers to know about it.

I agree with the sentiment -- that I would like to know what exceptions
are raised by any given call -- but I think Java's rules end up
requiring me to "cry wolf" too much. If every routine says "throws
most-anything" then it's not much use.

Another example (in Ada) is a generic, with a procedure parameter. An
instance of the generic can raise whatever exceptions that formal
procedure might raise, perhaps. Expressing that precisely requires a
much more complicated mechanism than Java provides.

Note also that Java doesn't follow its own advice -- the most common
exceptions (like dereferencing a null pointer) are exempt from this
mechanism. It's always suspicious when the predefined stuff (like
dereferencing null pointers, dividing by zero, etc) doesn't obey the
same rules that are expected of user code.

Ada's solution is not ideal, but Java's isn't either (for different
reasons).

- Bob

[Alan Brain]

Robert A Duff wrote:

>
> How about portability of arithmetic? In Java, int is always exactly 32

> bits 2's complement. In Ada, Integer is whatever the machine supports.
> And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or
> I might get 8-bit arithmetic, or who-knows-what.

If you really have to have 32 bits, just use

type INTEGER_32 is new INTEGER;
for INTEGER_32'size use 32;

Then use INTEGER_32 instead of Integer.That at least gets the size
right. Similar clauses give you 2's complement.

But unless interfacing with an IO device or some such, what the heck
does it matter whether it's 8,16,32,48,12,19 or whatever bits, providing
it's enough?

> On the other hand, at least Ada notifies you of overflows -- in Java, it
> just silently gets the wrong answer. (This is the C and C++ culture --
> Java inherits much more than just syntax from that culture.)

Concur.

---------------------- <> <> How doth the little Crocodile
| Alan & Carmel Brain| xxxxx Improve his shining tail?
| Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo oo oo oo
By pulling Maerklin Wagons, in 1/220 Scale

[Thomas Kendelbacher]

In article <dewar.845247229@merv>, de...@merv.cs.nyu.edu (Robert Dewar) writes:
>Lars says
>
>"Cultural bias or even prejudice is the most likely reason IMHO. Not
>technical reasons. On and off the same discussion comes up in the C++
>community. Those that control C++ and those that control Ada simply
>don't want GC :-("
>
>That's nonsense I think. [...]

No, it isn't. In the aerospace industry (probably the most faithful
of Ada's followers that are around) it's the decisive factor.

With so many technical managers and senior engineers who went into
management 10-15 years ago ... I won't say much more here. It just makes
for a good amount of technical conservatism: In those days, the common
belief in this community was that GC is a Bad Thing. Period.

--
Thomas Kendelbacher | email : Thomas.Ke...@erno.de (preferred)
DASA RI / Abt. RIT14 | voice : +49 421 539 5492 (working hours)
Postfach 28 61 56 | or : +49 421 576 9670 (any other time)
D-28361 Bremen | fax : +49 421 539 4529 (any time)
Germany

[Stephen Leake]

Robert A Duff wrote:
>
> In article <1996Oct15.174526.1@eisner>,
> Larry Kilgallen <kilg...@eisner.decus.org> wrote:

> >In article <DzBrF...@world.std.com>, bob...@world.std.com (Robert A Duff) writes:
> >> How about portability of arithmetic? In Java, int is always exactly 32
> >> bits 2's complement. In Ada, Integer is whatever the machine supports.
> >> And if I say "type T is range 1..100;" I might get 32-bit arithmetic, or
> >> I might get 8-bit arithmetic, or who-knows-what.
> >

> >And why should it matter ? If your specification is to cover that
> >range, a compiler is meeting that specification even if it converts
> >it to BCD to accomplish it on some _very_ old hardware.
>

> type T is range 1..100;

> X: T := ...;
> Y: T := ...;
> Average: T := (X + Y) / 2;
>
> Because the above code will work fine on some Ada compilers, and blow up
> on others (the addition will overflow using 8-bit signed arithmetic) if
> X and Y happen to be, say, 99. In Java, the above code is guaranteed to
> work.
>

> - Bob

Clearly, the Ada type should be defined to cover the expected range of
intermediate values, as well as the final values:

type T is range 1 .. 200;

What if I'm doing some computations in Java that have intermediate
values that need 33 bits? In Ada, the compiler tells me when it can't do
that.

--
- Stephe

[Robert A Duff]

In article <dewar.845506499@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:
>I am not sure I understand Bob's statement here. The above code is certainly
>not valid Java code, so what does it mean to say that the above code works
>in Java.

To write it in Java, you would use type 'int' or type 'char' or
whatever, and it would be portable. I admit it's not an exact
comparison, since Java doesn't have subranges (an important disadvantage
of Java, IMHO). I also admit that the lack of overflow checking in Java
weakens my point.

>... If you mean it is possible to write this in a manner that works

>in Java, then the same statement can be made in Ada:
>
> type BT is range 1 .. 200;
> subtype T is BT range 1 .. 100;

> X : T := ...;
> Y : T := ...;

> Average : T := (X + Y)/2;
>
>works fine. You can write invalid Ada code for anything, but doing so
>does not prove anything!

True, but it's easy to do it wrong, and have it work just fine, and then
find that it doesn't work when you port the code. Do all Ada
programmers understand that the above has to be written as you show
above? I suspect not. But I suspect all Java programmers understand
what the range of int is, and when arithmetic is supposed to work.

What about the following?

type T is range 1..100;

X: T := 100;
Y: T := 1;
Z: T := 100;
...
Z := Z + X - Y;

This will work fine in every Ada compiler that now exists or that ever
will exist. But it's not guaranteed to work by the RM. So, as a style
rule, should I declare a base subtype that goes up to 101 for the above?
I'm not sure.

Of course, Java will run horribly slowly on a machine with 36-bit
words. Ada was defined when such machines were more common.

- Bob

[Robert A Duff]

In article <dewar.845506606@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:
>Hmmm! I thought that Java left overflow undefined, I don't call that
>portable!

No, Java defines the result as wrap-around arithmetic. So an overflow
will give you the "wrong" answer (at least *I* would call it wrong, in
most situations), but it always gives you the *same* wrong answer on all
machines.

- Bob

[Robert A Duff]

In article <3266DC...@dynamite.com.au>,

Alan Brain <aeb...@dynamite.com.au> wrote:
>If you really have to have 32 bits, just use
>
>type INTEGER_32 is new INTEGER;
>for INTEGER_32'size use 32;

No, that doesn't work. What you want is "type Integer_32 is range
-2**31..2**31-1;". A Size clause does not affect the semantics of
arithmetic. So your Integer_32 might use 16 bits or 64 bits for
intermediate results.

> But unless interfacing with an IO device or some such, what the heck
>does it matter whether it's 8,16,32,48,12,19 or whatever bits, providing
>it's enough?

The portability issue arises for intermediate results within expressions
(as in (X + Y)/2). The compiler is not required to do the arithmetic in
"enough" bits to hold the intermediate result, so some compilers can
overflow where others do not. Java doesn't use "enough" bits either,
but at least it's always 32 or 64 bits (depending on the expression, not
on the compiler).

- Bob