Once again, Ada absent from DoD SBIR solicitation

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

Re: Once again, Ada absent from DoD SBIR solicitation

[Gandalf]

Gregory Aharonian wrote:
> 

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

Re: Once again, Ada absent from DoD SBIR solicitation

[Bill Nielsen]

Gregory Aharonian <srctran@world.std.com> wrote in article
<DyxtAA.Ez5@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
bnielsen@logicon.com
The above represents my own and not my company's opinion.

Re: Once again, Ada absent from DoD SBIR solicitation

[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_allen@hso.link.com
(713) 280-4445
-- my opinions only

C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

mg@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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <325BED6A.63F4@itg-sepg.logicon.com> David Shochat <shochat@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
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Dave]

Brian Rogoff wrote:
> 
> mg@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

Re: Once again, Ada absent from DoD SBIR solicitation

[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_allen@hso.link.com
(281) 280-4445
-- my opinions only

Re: Once again, Ada absent from DoD SBIR solicitation

[Mitch Gart]

Stanley R. Allen (s_allen@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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Once again, Ada absent from DoD SBIR solicitation

[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.
> --
> Stanley Allen
> s_allen@hso.link.com
> (713) 280-4445
> -- my opinions only

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Dave]

Stephen Leake wrote:
> 
> 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 :-)

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

Re: Once again, Ada absent from DoD SBIR solicitation

[Ken Garlington]

Mitch Gart wrote:
> 
> Stanley R. Allen (s_allen@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <ROGOFF.96Oct10095045@sccm.Stanford.EDU> rogoff@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.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <325D7F9B.2A8B@gte.net> Dave <dave@gte.net> writes:

> Brian Rogoff wrote:
> > 
> > mg@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.

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

Re: Once again, Ada absent from DoD SBIR solicitation

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <325D29A3.308@itg-sepg.logicon.com> David Shochat <shochat@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.

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

Ada and the DoD HLA (was: Once again, Ada absent from DoD SBIR solicitation)

[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.Cosby@cpmx.saic.com |  or opinion of SAIC unless specifically
noted.
(407) 282-6700 x216        |          Live long and perspire....

Re: Once again, Ada absent from DoD SBIR solicitation

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Tucker Taft]

Dave (dave@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   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Once again, Ada absent from DoD SBIR solicitation

[Mitch Gart]

Stanley R. Allen (s_allen@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Mitch Gart]

Brian Rogoff (rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[davedave]

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[davedave]

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.  

-- Dave Jones

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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!

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Kevin D. Heatwole]

In article <dewar.845091423@merv>, dewar@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.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Hannes Haug]

davedave@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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

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


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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <325FFB39.15A4@io.com>, davedave@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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <dewar.845149842@merv>, dewar@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

stt@houdini.camb.inmet.com (Tucker Taft) writes:
   Dave (dave@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

Re: Once again, Ada absent from DoD SBIR solicitation

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <325FFB39.15A4@io.com> davedave@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
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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
-- brh@cray.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <325FF8D0.6660@io.com> davedave@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <dewar.845162841@merv> dewar@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

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <dewar.845147148@merv> dewar@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.

/Jon

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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 :-)
\x1adp

Re: Once again, Ada absent from DoD SBIR solicitation

[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:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Once again, Ada absent from DoD SBIR solicitation

[Mitch Gart]

Robert Dewar (dewar@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

Dave <dave@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

Re: Once again, Ada absent from DoD SBIR solicitation

[Bevin R. Brett]

In article <3262572D.4E79@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes...
>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:ncohen@watson.ibm.com
>http://www.research.ibm.com/people/n/ncohen

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Keith Thompson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]


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) kst@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Keith Thompson]

In <326003FC.2038@gte.net> Dave <dave@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.

-- 
Keith Thompson (The_Other_Keith) kst@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <dewar.845340573@merv>, Robert Dewar <dewar@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Mitch Gart]

Brian Rogoff (rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian R. Hanson]

Dale Stanbrough wrote:
> 
> > 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"!)
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 Hanson
-- brh@cray.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

jsa@alexandria (Jon S Anthony) writes:
   rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Mike Stark]

Brian Rogoff wrote:
> 
> stt@houdini.camb.inmet.com (Tucker Taft) writes:
>    Dave (dave@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <ROGOFF.96Oct14095012@sccm.Stanford.EDU>,
Brian Rogoff <rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Mark A Biggar]

In article <1996Oct15.154148.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>In article <DzBM79.52n.0.-s@inmet.camb.inmet.com>, mg@dsd.camb.inmet.com (Mitch Gart) writes:
>> Brian Rogoff (rogoff@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
mab@wdl.lmco.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <DzBKKx.72M@world.std.com>, bobduff@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

Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

In article <DzBrFw.IAs@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <ROGOFF.96Oct14095012@sccm.Stanford.EDU>,
> Brian Rogoff <rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

In article <dewar.845340573@merv> dewar@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 I. Eachus

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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!

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <DzBM79.52n.0.-s@inmet.camb.inmet.com>, mg@dsd.camb.inmet.com (Mitch Gart) writes:
> Brian Rogoff (rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

dale@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Samuel T. Harris]

Jon S Anthony wrote:
> 
> In article <325FFB39.15A4@io.com> davedave@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!"

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Mike Stark]

Robert Dewar wrote:
> 
> 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!

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

bobduff@world.std.com (Robert A Duff) writes:
   In article <ROGOFF.96Oct14095012@sccm.Stanford.EDU>,
   Brian Rogoff <rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Brian Rogoff]

mg@dsd.camb.inmet.com (Mitch Gart) writes:
   Brian Rogoff (rogoff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <1996Oct15.150155.1@eisner> kilgallen@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
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <EACHUS.96Oct15141831@spectre.mitre.org> eachus@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <dale-1510961117020001@sambar.cs.rmit.edu.au> dale@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <DzBKKx.72M@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <dewar.845340573@merv>, Robert Dewar <dewar@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <dewar.845340573@merv> dewar@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <ROGOFF.96Oct15102253@sccm.Stanford.EDU> rogoff@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <EACHUS.96Oct14215330@spectre.mitre.org> eachus@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
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]


In article <Dz8znD.Fpt@thomsoft.com> kst@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.

/Jon



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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[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!

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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!

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Lars Farm]

Larry Kilgallen <kilgallen@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.farm@ite.mh.se

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <1996Oct15.174526.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>In article <DzBrFw.IAs@world.std.com>, bobduff@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <326628B8.7724@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>What if I'm doing some computations in Java that have intermediate
>values that need 33 bits?

In Java, you can use 'long', which is guaranteed to support exactly the
range -2**63..2**63-1, no more, no less.

>... In Ada, the compiler tells me when it can't do
>that.

So you port some code, and find that the compiler can't handle it.
So you have to rewrite a bunch of code.  Yuck.

- Bob

Why no Free?

[Matthew Heaney]

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


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

You know, I've always wondered about this.  It seemed rather strange that
the programmer would have to jump through all these hoops to deallocate
storage.

If I can do this

   The_Node : Node_Access := new Node;

then why shouldn't I be able to do this

   Free (The_Node);

without instantiating Unchecked_Deallocation?

This omission in the language seems curious given that in Ada 95, the
designers gave us explicit control of the storage pool, but no simple way
to reclaim storage.  (Maybe that's stretching things a bit; it's only an
instantiation...)

To the designers of Ada 95: Why didn't you throw in a Free?  Had this been
discussed?  Is it a candidate for inclusion in Ada 0X?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Why no Propagates?

[Matthew Heaney]

In article <326391B6.4B23@gsfc.nasa.gov>, Mike Stark
<michael.e.stark@gsfc.nasa.gov> wrote:


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

The designers of Ada 83 considered including explicitly naming the
exceptions propagated by a subprogram:

   procedure P (X : Integer) propagates A, B, C;

This feature, and the reasons it was rejected, is discussed in section
14.5.2  of the Ada 83 Rationale.

The reason they did not include the propagates feature is because they felt
that it would add too much baggage ("code expansion") to subprograms,
especially to those that were otherwise small.

Personally, I think it would be a cool feature to have.  Let me the
programmer decide whether I want to incur the code-expansion penalty.  (And
if the procedure tries to propagate something other than what's stated,
then raise Program_Error.)

To the designers of Ada 95: Was this feature considered for inclusion?  Is
it a candidate for inclusion in Ada 0X?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

"So you port some code, and find that the compiler can't handle it.
So you have to rewrite a bunch of code.  Yuck."

(Bob Duff, referring to finding that your friendly Ada compiler is not
 so friendly and will not support 64-bit integer arithmetic).

An obvious response: use GNAT, which guarantees 64-bit binary arithmetic,
and is almost certainly available for you to use, unless perhaps you are
on a Patriot missile, but in that case maybe you really don't WANT 64-bit
arithmetic, which is why of course the decision on whether or not to provide
it is left implementation dependent. I must say I see absolutely no good
reason for a general purpose Ada compiler not to support 64-bit binary
arithmetic.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Alan said

"If you really have to have 32 bits, just use

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

No, that's wrong, actually the easiest way to get 32 bit integers is
to get Integer_32 out of the standard Interfaces package, where it is
defined correctly.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

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

Oh, sorry, I did not realize this (it never occurred to me that a language
definition would mandate such patently unpleasant semantics for integer
arithmetic, sounds like an implementor rather than a language designer
at work if you ask me).

OK, we can't duplicate that arithmetic in Ada directly, and that is not
surprising, a semantics whhere you can add two positive numbers and get
a negative number is not exactly attractive to provide as a primitive.

If you really really want such strange arithmetic (perhaps to acomodate
a Java-to-Ada translator :-) then you could program it easily enough
using unchecked conversion and modular and signed arithmetic mixed in
the appropriate odd way.

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

Bob Duff says

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


Harrumph! Arguing that Java programmers know Java and Ada programmers
do not know Ada seems to be getting rather thin don't you think?

One very important distinction is the following. In either language
you can write code where intermediate results are out of range of
the type.

In both languages, such code may or may not work.

In Java, if it does not work, the program execution is (in Ada-ese)
erroneous, and who knows what values you get.

In Ada, if it does not work, you will get a runtime exception.

Arguing that Java arithmetic is more portable seems completely
specious to me. The type:

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

is almost exactly equivalent to the Java type int. Why only "almost", well
to make it exatly equivalent, I have to do

   pragma Suppress (Overflow_Check, int);

Now it is true that Java guarantees the presence of 64-bit signed
binary arithmetic, and Ada does not. However, in my experience, by
far the most common need for such high precision arithmetic is
in connection with fiscal applications, and here Ada's Decimal
type is much more attractive than the use of manually scaled int
values.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <3264CCEB.AC0@gsfc.nasa.gov>,
Mike Stark  <michael.e.stark@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[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

Re: Garbage Collection in Ada

[Thomas Kendelbacher]

In article <dewar.845247229@merv>, dewar@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.Kendelbacher@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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Stephen Leake]

Robert A Duff wrote:
> 
> In article <1996Oct15.174526.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
> >In article <DzBrFw.IAs@world.std.com>, bobduff@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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <dewar.845506499@merv>, Robert Dewar <dewar@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <dewar.845506606@merv>, Robert Dewar <dewar@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <3266DC85.D45@dynamite.com.au>,
Alan Brain  <aebrain@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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

In article <DzFB5z.D6A@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <dewar.845506499@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

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

I suspect _most_ Ada programmers understand the range of Integer in
their particular environment and know they are not close.     Those
who take the trouble to go beyond that simplistic view are as likely
to take intermediate result needs into account as not.

I suspect a smaller percentage of Java programmers than Ada programmers
have gone so far as to consider the range of int or Integer respectively.

Larry Kilgallen

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

In article <DzFC07.LMw@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <326628B8.7724@gsfc.nasa.gov>,
> Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:

>>... In Ada, the compiler tells me when it can't do
>>that.
> 
> So you port some code, and find that the compiler can't handle it.
> So you have to rewrite a bunch of code.  Yuck.

No, Hooray !  We have learned a lesson in reading specifications of
compilers before we go to depend upon them.  Industry might prefer
that educators spin off a "GNAT-lite" with pathetically inadequate
(but standard-conforming) limits as a target for their student's
first porting exercise.

No, I don't think it is better for them to learn in an environment
like Java where everything is always the same, because life is not
that way.

Larry Kilgallen

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Jon said

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


That is a principle often appealed to in the language design process "Hey,
put in my pet feature, you don't have to use it if you don't need it."

This is an invalid principle. It is important to remember that every feature
you add to a language damages it by adding to the complexity, and also
possibly by adding to the difficulty of implementation, which can damage
the quality and availability of implementations. Note that this applies even
to optional features, since any implementation effort will at least need to
take into account the possibility of implementing the feature in the future,
and very often one ends up implementing things that no one will use (how many
people have used all the features in the informatoin systems annex yet?)

So the question to ask is whether the increase in functionality compensates
for the damage being done by adding the new feature.

During the Ada 9X design process, the design team proposed MANY features
that you do not see today. For the feature enthusiasts, see mapping documents
one and two for some interesting archeology. The nearly unanimous reaction
of WG9 and the DR's was that the language as proposed was too big and too
complex.

The design team often responded by saying "Show us what is technically wrong
with a feature, and we will remove it." Well of course that was not the issue
there was nothng technically wrong with any one feature, it was just the
aggregate that was a problem. Sort of like being over-budget and insisting
that you will only remove unjustified items from the budget -- note that
you can trace many problems with the large deficit spending by governments
to this problem -- they are over budget, but cannot find individual items
in the budget that they can happily remove.

It's interesting in this thread that we essentially see a replay of many
of these discussions. What you have is a couple of people posting over and
over again saying that (a) they want feature x and (b) they are sure that
feature x would mean that many more people would use Ada. It would be more
convincing to have a single current commercial user of Ada make the statement
in a way that counts, but in priority wish lists we see from such users 
GC does not figure.

Maybe it should, but it is an unconvincing claim to simply state that yu
are sure that it is the case that adding new feature XXX will increase
Ada use by YYY without any evidence.

Note that for every feature not in Ada, there are ardent advocates
who insist on this being true for their feature. If you listened to
all of them, you would have far too much junk in the language.

For example, someone, I forget who, pops up and argues that the single
fatal error in Ada is the failure to provide full first class functions
(with full closures -- please don't confuse this with the downward
closure argument that has raged from time to time on CLA).

Just as the GC advocates point to Ada, the closure advocate points to ML,
LISP, SCHEME etc.

----------------------------------^ should be Java of course

I happen to agree that GC is an important feature, though I still have
some reservations about including it in a language of the semantic level
of Ada (which permits things like unchecked conversions between pointers
and integers). But there simply aren't enough people.

Some people complain about the community being inbred, but as in the theater
world, the most important thing is to worry about your current audience. There
is nothing more fatal than to go off on fantasy trips after new audiences,
and lose your current audience meanwhile. In the absence of hard data 
supporting the claim that adding feature X will attract existing of new
users, you have to react to unsupported claims carefully.

For an exmaple of a feature that DOES definitely attrct new Ada users,
consider Annex E (distribution). We are definitely finding that this
*is* attracting new users to consider Ada 95. This is not a guess, it is
based on real customers sending us messages telling us they are interested!

As I have said a few times, I think the most valuable contribution of Java
may be to heighten people's awareness of the value of garbage collection.
But I trust it should be clear to people that the success of Java is not
because it has garbage collection, in fact I look to exactly the opposite
effect, the success of Java will RESULT in more interest in GC.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

For those supporting the idea of an Annex requiring garbage collection, by
far the most constructive action, far more useful than posting messages
to CLA, would be to draft such an annex. If you can get something which
people agree on as making technical sense, then the next step would be to
get some implementors to implement it, and perhaps to add it to ACE.

Re: Why no Free?

[Robert Dewar]

Matthew asks

"If I can do this

   The_Node : Node_Access := new Node;

then why shouldn't I be able to do this

   Free (The_Node);

without instantiating Unchecked_Deallocation?
"

Well that has a simple answer. The new operation is safe, the free is
obviously not safe. Ada is designed as a safe language, and it is a
deliberate decision to make the use of non-safe operations inconvenient
and very clearly documented.

No one even considered adding a Free keyword to Ada 9X, I cannot imagine
anyone supporting such a change.

Re: Once again, Ada absent from DoD SBIR solicitation

[Rush Kester]

Matthew M. Lih (matt.lih@trw.com) wrote:
: 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

IMO, the "good" part that DoD is seeking about commercial practices is
that the product is developed and maintained with someone elses money.
My fear is that the "good" they will get is the "good enough to sell" to
nieve consumers, who won't find out about the flaws until after the sale
is consumated and who have little or no chance of recovering their money.

Rush Kester
Sr. Software Engineer
W (301) 640-3632 (in person M-F: 9am-5pm EDST, voicemail any time)
Fax        -4750 or -4940
-- 
Rush Kester
W (301) 640-3632 (in person M-F: 9am-5pm EDST, voicemail any time)
Fax        -4750 or -4940

Re: Why no Free?

[John Herro]

In article <mheaney-ya023180001710961727290001@news.ni.net>,
mheaney@ni.net (Matthew Heaney) writes:
> If I can do this
>    The_Node : Node_Access := new Node;
> then why shouldn't I be able to do this
>    Free (The_Node);
> without instantiating Unchecked_Deallocation? ...
> To the designers of Ada 95: Why didn't you throw
> in a Free?

I'm not a designer of Ada 95, but I think I know the answer: because it
would be dangerous!  You could write
   The_Node : Node_Access := new Node;
   Copy     : Node_Access := The_Node;

   Free (The_Node);
and then dereferencing Copy will have unpredictible results.  By forcing
you to instantiate Unchecked_Deallocation, the language designers are at
least making sure that you, the programmer, know that you're doing
something dangerous.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
The mathematical relationship between Christmas and Halloween:
25     =  31
  DEC       OCT

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <1996Oct17.131142.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>In article <DzFB5z.D6A@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
>>>    type BT is range 1 .. 200;
>>>    subtype T is BT range 1 .. 100;
>>>    X : T := ...;
>>>    Y : T := ...;
>>>    Average : T := (X + Y)/2;

>I suspect _most_ Ada programmers understand the range of Integer in
>their particular environment and know they are not close.

But the range of Integer has nothing to do with it.  Even if Integer is
the 32-bit range, an implementation might well use 8-bit arithmetic for
a range like 1..100, and on some machines it might even make sense
(80x86, perhaps).

I suspect lots of Ada programmers *do* assume that they'll get the same
range as Integer for intermediate results, and know that Integer is
"plenty" big, and on most compilers, that will work fine.  But it's not
portably true.

- Bob

Re: Why no Propagates?

[Robert A Duff]

In article <mheaney-ya023180001710961746550001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>To the designers of Ada 95: Was this feature considered for inclusion?

No, not that I recall.  There was a great deal of resistance to the
changes that *were* made to exceptions (like attaching strings to them).

>...Is
>it a candidate for inclusion in Ada 0X?

I suppose it might be.  Who knows?

- Bob

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <1996Oct18.074034.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>I thought the claim was made that those "bad" (I hope that is not a
>reserved word) Java results would be the same from machine to machine.
>That at least raises the hope that bugs which did not bite you on
>machine A will also not bite you on machine B.  If that hope is
>fulfilled, then it would seem that Java arithmetic is portable.
>
>I am not saying Java arithmetic is "good", since the first person to
>provide subtly different input on any platform might get undesired
>behaviour. But to the extent that the undesired behaviour is uniform
>across all platforms, Java arithmetic is "portable".

That's exactly what I've been trying to say.  Thanks for saying it more
clearly than I have.

I'm the the one that claimed that Java arithmetic is portable even in
the presence of overflow.  Several people have questioned that, so I
looked it up in "The Java Language Specification".  In section 15.17.2,
page 358, it says, "If an integer addition overflows, then the result is
the low-order bits of the mathematical sum as represented in some
sufficiently large two's complement format."  Subtraction is defined so
a-b is the same as a+(-b).  Unary minus is defined in 15.14.4 so -x
equals (~x)+1, where ~ is the bit-wise complement operator.  15.16.1
talks about multiplication, and says something similar about overflows.
I didn't bother to look up all the operators.

So, an overflow in Java always produces the same answer.  It is *not*
equivalent to pragma Suppress(Overflow_Check) in Ada.

So in general, the ranges supported are portable, and the behavior of
the operators is portable.  Neither of these is true for Ada.  In Ada,
you *can* write portable arithmetic in practise, if you stick to 32-bits
or less, and are careful about overflows in intermediate results.  You
can also accidentally write non-portable arithmetic.  In Java, you can't
make that mistake.

Whether this is an advantage of Java is open to debate, of course -- the
portability comes at some substantial run-time cost on machines with
strange word sizes.

In fact, Java is more portable than Ada in a *lot* of ways.  I'm about
2/3 of the way through the Java book, and the only non-portabilities
I've noticed are (1) getting Out_Of_Memory_Error and (2) the behavior of
multiple threads reading and writing shared variables.

- Bob

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert A Duff]

In article <1996Oct17.131934.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>No, I don't think it is better for them to learn in an environment
>like Java where everything is always the same, because life is not
>that way.

By this argument, anything portable about any language is a Bad Thing.
I don't buy this "school of hard knocks" idea.

- Bob

Re: Why no Propagates?

[Norman H. Cohen]

Matthew Heaney wrote:

> In article <326391B6.4B23@gsfc.nasa.gov>, Mike Stark
> <michael.e.stark@gsfc.nasa.gov> wrote:
> 
> >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.
...
> 
> The designers of Ada 83 considered including explicitly naming the
> exceptions propagated by a subprogram:
> 
>    procedure P (X : Integer) propagates A, B, C;
> 
> This feature, and the reasons it was rejected, is discussed in section
> 14.5.2  of the Ada 83 Rationale.
> 
> The reason they did not include the propagates feature is because they felt
> that it would add too much baggage ("code expansion") to subprograms,
> especially to those that were otherwise small.

A glance at the Ada-83 Rationale clarifies that the code expansion that
concerned designers was object-code expansion, not the cluttering of
source code.  The alternative against which the Rationale argues
presumes a run-time check that no exception other than A, B, or C (in
the example above) is raised in P without being handled locally.
This is quite different from the Java scheme (I hope that James Gosling
will be less sensitive than Robert Dole to the use of the word "scheme";
his Java Language Specification coauthor Guy Steele is certainly in no
position to object to it!), which is based on a compile-time check that
any method call capable of raising an exception  is either surrounded by
a try block that handles that exception or enclosed in a method declared
to throw that exception.  (An exception to this rule is made for certain
exceptional exceptions; see below.)

A complication with applying such a compile-time rule in Ada is that an
Ada exception can be propagated to places outside the scope of its
declaration.  If package P1 provides an exception E and a subprogram S1
that propagates E, and subprogram S2 (with a with clause for P1) calls
P1.S1 but does not handle the possible raising of P1.E, then another
subprogram S3 that calls S2 now requires a with clause not only for S2,
but also for P1, so that P1.E can be named in either an exception
handler or a "propagates" clause.  It can be argued that this is not
such a bad thing, especially if it imposes a discipline on the writer of
S2 to handle the exception potentially raised by its call on P1.S1.  It
can also be argued that if the interface of S2 declares that it may
propagate P1.E1, S2 ought to be enclosed in a package that also declares

   E: exception renames P1.E1;

--thus obviating the need for a caller of S2 to have a with clause for
P1.

> Personally, I think it would be a cool feature to have.  Let me the
> programmer decide whether I want to incur the code-expansion penalty.  (And
> if the procedure tries to propagate something other than what's stated,
> then raise Program_Error.)

(Presumably, this rule would not apply to the exceptions declared in
Standard, particularly to Program_Error itself!  Note that this is the
strawman run-time-check model of the Ada-83 Rationale, not the Java
compile-time-check model.)

Even though the Ada-83 Rationale was concerned with object-code bloat,
source-code bloat is also a serious concern.  Imagine having to
explcitly address the fact that any call on any I/O subprogram might
raise Device_Error!  Every Ada program I've ever seen ignores this
possibility, and manages to be just as useful and no less reliable.

Indeed, Java applies its compile-time rule inconsistently to some, but
not all, of the language-defined exceptions.  All exceptions that are
descendants of Error (essentially internal JVM implementation errors or
malformed class files) and all exceptions that are descendants of
RuntimeException (roughly the equivalent of Ada's Constraint_Error) are
excluded.  On the other hand, the rule does apply to all Java I/O
exceptions, and this can be quite an annoyance.

Sometimes I appreciate the discipline imposed by the Java rule, but
often I find it a royal pain, forcing me to write try blocks for
exceptions that can't be handled in any meaningful way anyway.  Even the
imposition of discipline depends on my good will:  A naughty Java
programmer can avoid the whole issue simply by adding

   throws Exception

to every method declaration (or customizing his language-sensitive
editor to it for him)!

> To the designers of Ada 95: Was this feature considered for inclusion?  Is
> it a candidate for inclusion in Ada 0X?

This feature did not come up during the Ada 9X revision process.  So
far, there is nobody vetting candidates for inclusion in Ada 0X.

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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:

> Harrumph! ...

...

> Now it is true that Java guarantees the presence of 64-bit signed
> binary arithmetic, and Ada does not. However, in my experience, by
> far the most common need for such high precision arithmetic is
> in connection with fiscal applications, and here Ada's Decimal
> type is much more attractive than the use of manually scaled int
> values.

Harrumph! What about 64-bit UNsigned binary arithmetic?  32-bit
arithmetic does not suffice for manipulating offsets into files larger
than 4GB, or for calculating the amount of space available on some
disks, or for timestamps accurate to the nearest millisecond and
spanning a range of 16 months or more.

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

Re: Why no Free?

[Robert A Duff]

In article <mheaney-ya023180001710961727290001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>To the designers of Ada 95: Why didn't you throw in a Free?

We would have been tarred and feathered.

By the way, what is the parameter type of the argument of this
procedure?  Root_Access'Class?  Hmm.  Or is "free" a reserved word, so
"free X" is a statement expecting any access type?

>...  Had this been
>discussed?

I don't think so.

>...  Is it a candidate for inclusion in Ada 0X?

I doubt it.  Probably by that time, garbage collection will be plentiful.
So the original assumptions in Ada 83 (GC available, and
Unchecked_Deallocation is dangerous) will be correct.  And given those
assumptions, the design decision to make Unchecked_Deallocation slightly
painful is the right decision.

- Bob

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

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

> "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."
> 
> 
> That is a principle often appealed to in the language design process "Hey,
> put in my pet feature, you don't have to use it if you don't need it."
> 
> This is an invalid principle. It is important to remember that every feature

Yes, yes, of course.  But you are pulling one of your Strawman
arguments here.  Sure, in general you can't allow this.  But clearly
it makes sense for those cases which are highly desireable but are
blocked for some rather specific sort of reason attached to a certain
highly vocal (probably) minority view.


> The design team often responded by saying "Show us what is technically wrong
> with a feature, and we will remove it." Well of course that was not the issue
> there was nothng technically wrong with any one feature, it was just the
> aggregate that was a problem. Sort of like being over-budget and insisting
> that you will only remove unjustified items from the budget -- note that
> you can trace many problems with the large deficit spending by governments
> to this problem -- they are over budget, but cannot find individual items
> in the budget that they can happily remove.

I don't see how this particular line of thought is relevant to the
particular case (GC or Assert) in question (especially as you made a
claim in a previous post that Assert would probably end up being in
every Ada95 compiler anyway, just not in a _standard_ way - thereby
giving the worst of all worlds situation).


> convincing to have a single current commercial user of Ada make the
> statement in a way that counts, but in priority wish lists we see
> from such users GC does not figure.

As others have pointed out this plays into the chicken/egg problem.
If there were GC, you may have a lot more (commercial) Ada users.
Market _size_, not market _share_, is the important point.


> Maybe it should, but it is an unconvincing claim to simply state that yu
> are sure that it is the case that adding new feature XXX will increase
> Ada use by YYY without any evidence.

Agreed.  And it is equally unconvincing to claim that not having it
makes no difference since you have no evidence for this.  Actually,
there is at least _some_ evidence (annecdotal for sure) for the claim
that it _would_ make a difference and absolutely _none_ that has been
offered for the other view.


> Note that for every feature not in Ada, there are ardent advocates
> who insist on this being true for their feature. If you listened to
> all of them, you would have far too much junk in the language.

Absolutely, but again, this is just irrelevant for the issue in
question.


> Just as the GC advocates point to Ada, the closure advocate points to ML,
> LISP, SCHEME etc.

Well, there are many differences with the only similarity being, yes
these are two constructs that have been desired.  For one thing, you
can roll your own closure stuff in Ada as it is.  For another, it is
no where near as general purpose an "enabling" construct as GC. For
another,... Really, it is just irrelevant to the question.


> and integers). But there simply aren't enough people.

As I say, you have no evidence for this.  You only have evidence that
there are not enough people currently using GNAT who want GC.


> meanwhile. In the absence of hard data supporting the claim that
> adding feature X will attract existing of new users, you have to
> react to unsupported claims carefully.

Well, fair enough.  But you have to realize that it is also dangerous
(perhaps far more dangerous in the long run) to gamble on this point
of view.


> For an exmaple of a feature that DOES definitely attrct new Ada
> users, consider Annex E (distribution). We are definitely finding
> that this *is* attracting new users to consider Ada 95. This is not
> a guess, it is based on real customers sending us messages telling
> us they are interested!

Well, THAT'S BECAUSE IT'S THERE!!  Come on - you can't even remotely
bring this up as a point here.  The chicken/egg dilemma is resolved.
Suppose it wasn't.  We could just as easily be having this
conversation about DSA.  Actually, it would not be as easy, because
DSA is covered (and more competely) by CORBA based ORBs directly
supporting Ada95.  For myself, while I think DSA is nice, it is just
not that big of a deal when you have the latter floating around all
over the place, offered by several vendors, language neutral, with
hooks into OLE/COM, with a cast of thousands improving it daily, etc.,
etc., etc.


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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <JSA.96Oct18155520@alexandria> jsa@alexandria (Jon S Anthony) writes:

> In article <dewar.845557517@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> > "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."
> > 
> > 
> > That is a principle often appealed to in the language design process "Hey,
> > put in my pet feature, you don't have to use it if you don't need it."
> > 
> > This is an invalid principle. It is important to remember that every feature
> 
> Yes, yes, of course.  But you are pulling one of your Strawman
> arguments here.  Sure, in general you can't allow this.  But clearly
> it makes sense for those cases which are highly desireable but are
> blocked for some rather specific sort of reason attached to a certain
> highly vocal (probably) minority view.

Ooops, forgot an important point: "put in my pet feature, you don't
have to use it ..." is not only irrelevant strawman here, it is just
plain inaccurate.  There is no suggestion of requiring GC (or even
Assert).  So, no one would even have to implement the thing.  Just
that there would be a) a stronger expectation and b) if implemented it
would have at least some regularity across implementations.

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

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

> For those supporting the idea of an Annex requiring garbage collection, by
> far the most constructive action, far more useful than posting messages
> to CLA, would be to draft such an annex. If you can get something which
> people agree on as making technical sense, then the next step would be to
> get some implementors to implement it, and perhaps to add it to ACE.

Well, now we're talking!  Perhaps a mailing list would be a good first
step?  I'd certainly be willing to help and be involved in this.

/Jon

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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

iNorman says

"Harrumph! What about 64-bit UNsigned binary arithmetic?  32-bit
arithmetic does not suffice for manipulating offsets into files larger
than 4GB, or for calculating the amount of space available on some
disks, or for timestamps accurate to the nearest millisecond and
spanning a range of 16 months or more."


Well if you are telling me that you have written applications that 
do all the above, interesting ... I sure have not seen many such uses
in the user code I have seen.

I am particularly interested in your comments on manipulating offsets
into files larger than 4GB, what operating system are you talking about
here for interest :-)

Re: Why no Propagates?

[Robert Dewar]

Matthew asks

"To the designers of Ada 95: Was this feature considered for inclusion?  Is
it a candidate for inclusion in Ada 0X?"

First question: not particularly. there were no strong user requirements
expressed in this area, and the thinking expressed in the original design
does not seem visiting.

Second question: There is no Ada 0X project, and I doubt that this would
be seriously considered for inclusion in the next version of Ada if and
when such is considered.

Meanwhile, if someone is interested in a feature like this, hack it into
GNAT, and play with it!

Re: Why no Propagates?

[Michel Gauthier]

In article <mheaney-ya023180001710961746550001@news.ni.net>,
mheaney@ni.net (Matthew Heaney) wrote:

>>  In article <326391B6.4B23@gsfc.nasa.gov>, Mike Stark
>>  <michael.e.stark@gsfc.nasa.gov> wrote:
>>  
>> [...]
>>  
>>  The designers of Ada 83 considered including explicitly naming the
>>  exceptions propagated by a subprogram:
>>  
>>     procedure P (X : Integer) propagates A, B, C;
>>  
>>  This feature, and the reasons it was rejected, is discussed in section
>>  14.5.2  of the Ada 83 Rationale.
>>   [...]
>>  Personally, I think it would be a cool feature to have.  Let me the
>>  programmer decide whether I want to incur the code-expansion penalty.  (And
>>  if the procedure tries to propagate something other than what's stated,
>>  then raise Program_Error.)
>>  
>>  To the designers of Ada 95: Was this feature considered for inclusion?  Is
>>  it a candidate for inclusion in Ada 0X?

I was not in the Ada9X team, hence I can't give any information about 
the question itself, but I guess you could reflect about some cases :

 - Consider a generic power function. It has a "*" parameter which can
"propagate X" for an overflow. Consequently, the power function can 
propagate the same exception, which must be a parameter of the construct.
Ada95 can do this, of course, but it is rather complex.

 - Consider a generic iterator. You reach the same problem, but complicated
by the fact that the iterator can raise exceptions by itself (for example
Device_Error if you scan a file).

 - Consider some use of "exception identities" in order to transmit an
exception through rendezvous, and more generally any use of an
exception identity variable. Then you need to make"propagate the
exception identified by V at some moment of the execution" explicit .
How will you write this ?

I fully agree that " it would be a cool feature to have", but I concluded
long ago that it would be very difficult to make it compatible with
all the other features of the language. Possibly an additional effort
on ANNotated Ada in this direction would have been useful, but
we cannot hope a full solution.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
    a partir du 19 octobre, depuis la France  : 05 55 45 73 35 
     from october,19 on, and from abroad : +33 5 55 45 73 35
fax +33 ()  55457315  [or ~7201]  
    and similar evolution
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Brian R. Hanson]

Robert Dewar wrote:
> 
> iNorman says
> 
> "Harrumph! What about 64-bit UNsigned binary arithmetic?  32-bit
> arithmetic does not suffice for manipulating offsets into files larger
> than 4GB, or for calculating the amount of space available on some
> disks, or for timestamps accurate to the nearest millisecond and
> spanning a range of 16 months or more."
> 
> Well if you are telling me that you have written applications that
> do all the above, interesting ... I sure have not seen many such uses
> in the user code I have seen.
> 
> I am particularly interested in your comments on manipulating offsets
> into files larger than 4GB, what operating system are you talking about
> here for interest :-)

I work on an application that regularly needs to manipulate file offsets 
that do not fit in 32 bits.  Two systems that can handle this are

Cray Research Unicos 
Silicon Graphics Irix 6.2

I worked at Control Data on Nos/VE which provided a user address space
of
2**16 segments of 2**31 bytes.  Unfortunately, because files were always 
memory mapped, any one file could not exceed 2**31 bytes and the
commercial
database people were on our case for having such a pathetic limitation
for
file size.  This was 8 years ago at least.

Database applications and video applications I would expect would
consider 
4GB extreemly limiting.

-- Brian Hanson
-- brh@cray.com

Re: Why no Propagates?

[Robert Dewar]

Norman says

"This feature did not come up during the Ada 9X revision process.  So
far, there is nobody vetting candidates for inclusion in Ada 0X.
"

Not quite true, it was discussed briefly during the requirements phase
and dropped as I remember.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Keith Thompson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4279 bytes --]


In <JSA.96Oct16173655@alexandria> jsa@alexandria (Jon S Anthony) writes:
> In article <Dz8znD.Fpt@thomsoft.com> kst@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.

Is it?  I was making an implicit assumption, which I will now make
explicit.

Note that I was quoting from the Java Language Specification, not the
Java Virtual Machine definition.  My assumption was that the JVM is an
abstract machine on top of which Java the language is implemented, and
that a conforming JVM can be implemented by means other than the typical
Java byte-code interpreter.

In other words, if I implement a Java compiler that generates
SPARC machine code, the JVM for that implementation consists of the
SPARC hardware plus whatever software is necessary to satisfy the JVM
definition.  This additional software presumably would include automatic
garbage collection, among other things.

If this is what the term Java Virtual Machine means, then it's perfectly
appropriate to refer to the JVM in the language specification.  It's an
interesting technique of separating low-level concerns from high-level
language concerns, while allowing the low level to be implemented either
in software, in hardware, or in some combination of the two.

On the other hand, if the term JVM refers specifically to the Java
byte-code interpreter, then referring to it in the language specification
is a serious flaw.

I haven't studied the Java documentation closely enough to resolve this.

>                                        Moreover, "suggests", "expend
> effort toward", "made a best effort", etc. sounds a lot like "expected
> to have".

I said it was stated.  I didn't say it was well stated.

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

It may not be stated anywhere.

As a practical matter, given that Java provides no explicit pointers
and no way to explicitly deallocate memory, it's unlikely that any
implementer would ever provide a Java implementation without automatic
garbage collection.  Such an implementation would be nearly useless.
Given this practical constraint, it's reasonable to say *informally*
that the Java language provides automatic garbage collection.

-- 
Keith Thompson (The_Other_Keith) kst@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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Keith Thompson]

In <3266DC85.D45@dynamite.com.au> Alan Brain <aebrain@dynamite.com.au> writes:
[...]
> If you really have to have 32 bits, just use
> 
> type INTEGER_32 is new INTEGER;
> for INTEGER_32'size use 32;

Um, no.

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

Your version assumes that Integer is at least 32 bits.  This is true
for many but not all implementations.

Digression:
    My version admittedly assumes a 2's-complement representation.
    Here's a version that doesn't.

        Twos_Complement : constant
           := System.Min_Int = -System.Max_Int - 1;
        type Integer_32 is
           range -2**31 + Boolean'Pos(not Twos_Complement) ..
                 +2**31 - 1;

    The extra little bit of portability probably isn't worth the
    esthetic cost.
end Digression;

-- 
Keith Thompson (The_Other_Keith) kst@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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

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

> One very important distinction is the following. In either language
> you can write code where intermediate results are out of range of
> the type.
> 
> In both languages, such code may or may not work.
> 
> In Java, if it does not work, the program execution is (in Ada-ese)
> erroneous, and who knows what values you get.

I thought the claim was made that those "bad" (I hope that is not a
reserved word) Java results would be the same from machine to machine.
That at least raises the hope that bugs which did not bite you on
machine A will also not bite you on machine B.  If that hope is
fulfilled, then it would seem that Java arithmetic is portable.

I am not saying Java arithmetic is "good", since the first person to
provide subtly different input on any platform might get undesired
behaviour. But to the extent that the undesired behaviour is uniform
across all platforms, Java arithmetic is "portable".

> In Ada, if it does not work, you will get a runtime exception.

What a neat idea ! :-)

Larry Kilgallen

Re: Why no Free?

[John Herro]

I wrote:
> ... dereferencing Copy will have unpredictible results.
                                   ^^^^^^^^^^^^^

I have a spelling checker;
   It came with my PC;
It plainly marks four my review
   Mistakes I cannot sea;
I've run this poem threw it;
   I'm sure you please to no
Its letter perfect in it's weigh;
   My checker tolled me sew.


- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

Brian, speaking from the high end at cray.com, notes that 64-bit
integers are definitely of use in high end applications.

I certainly don't disagree with that, and that is why ALL versions of
GNAT on ALL machines fully support at least 64-bit signed and unsigned
arithmetic.

I think it would be a GOOD THING if all Ada compilers (and all C compilers
for that matter) supported 64-bit integers.

The interesting thing is that obviously there has not been too much pressure
in the past for this, since almost all Ada 83 compilers and almost all C
and C++ compilers for 32-bit machines do NOT support 64-bit integers, even
though it is really pretty simple to do. So from that I conclude that at
least in the past it has not been a major requirement.

The reason that Ada, including Ada 95, was conservative in such requirements
at the language level was that there was concern that on small embedded
systems (e.g. the Patriot 2 implementation), it would be too much of a 
burden to make this a requirement.

Note that any full language implementation of Ada 95 (you already know my
definition of this term, it means that everything in the RM is implemented
including all the optional annexes), you do have 64-bit integer arithmetic
since you can say:

   type Big_Int is delta 1.0 digits 18;

and that maps typically into 64-bit binary arithmetic, or in any case is
presumably enough to provide for large file offsets. For the moment at
least files that are a million terrabytes long are presumably sufficient :-)

Note incidentally that this shows an interesting advantage of the optional
annexes. Here is a case where you can write an application that deals with
giant file offsets, and will still be portable to any full language
implementation of Ada 95 that includes the information systems annex.
Now you might have decided up front that you did not need this annex,
but it is often the case that facilities in one of the optional annexes
turn out to be helpful in all sorts of contexts. For example, you may
find the 'Body_Version attribute useful in tagging files to make sure
that they are read by an appropriate version of your software, evenb though
you have ZERO interest in distribution otherwise, or you may want to use
pragma Normalize_Scalars to help you track down bugs even if you are not
writing Safety-Critical software and do not need other features in the
safety and security annex. There are many other examples!

Of course in GNAT, you could simply use Long_Long_Integer, knowing that
it is at least 64-bits, but that might not be portable to another Ad 95
compiler, even one that did implement the full language, including all
the annexes.

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

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

> I think it would be a GOOD THING if all Ada compilers (and all C compilers
> for that matter) supported 64-bit integers.

Some of us might prefer to restrict C compilers to 8 bits.
Unfortunately C is used worldwide, so getting the US Congress
to tack an amendment onto an appropriation bill at the last minute
would be insufficient. :-(

> Note that any full language implementation of Ada 95 (you already know my
> definition of this term, it means that everything in the RM is implemented
> including all the optional annexes), you do have 64-bit integer arithmetic
> since you can say:
> 
>    type Big_Int is delta 1.0 digits 18;
> 
> and that maps typically into 64-bit binary arithmetic, or in any case is
> presumably enough to provide for large file offsets. For the moment at
> least files that are a million terrabytes long are presumably sufficient :-)

If you have files which are longer, you can probably afford to fund 
enhancement of the compiler you use :-)

Larry Kilgallen
(Sorry, it's Saturday.)

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Alan Brain]

Keith Thompson wrote:
>
> > If you really have to have 32 bits, just use
> >
> > type INTEGER_32 is new INTEGER;
> > for INTEGER_32'size use 32;
> 
> Um, no.
> 
>     type Integer_32 is range -2**31 .. +2**31-1;
> 
> Your version assumes that Integer is at least 32 bits.  This is true
> for many but not all implementations.

By George, the man's right.

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Richard Riehle]

On Thu, 10 Oct 1996, David Shochat wrote:

> 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

  And yet, David, we both know, and many readers of this forum know, that
  many DoD projects are being programmed in C++.  I just learned of a
  critical missile system, orginally planned to be done in Ada, which has
  been programmed in C++.  

  The fact that C++ is probably dangerous has minimal influence on the 
  decision-making process.  Rather, the managers who decide to use
  C++ make that decision on the basis of their skepticism vis a vis
  the longevity and health of Ada.  They see C++ tools everywhere,
  see very few Ada tools, and conclude that C++ is a better long-term
  choice.  Whether this is right or wrong, it is a simple fact. And
  the program managers I talk with believe, after examining Ada rather
  carefully, that Ada might be a better language, but C++ is a better
  business decision for their project. 

  We need to make the case that Ada is a better business decision,
  not just a better language design.

  Richard Riehle

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[nasser]

In article <Dz8znD.Fpt@thomsoft.com>, kst@thomsoft.com says...
>
>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).
>


Are you saying that the compiler will generate code (assuming
GC is supported) to free the memory pointed to by P before it 
does the next allocation? (that's why the program does not
run out of memory in this loop).

To me, this program is an erroneous program to start with. Having 
GC will only HIDE this fact. So having GC seems not such a good idea, 
since programmers will start writting sloppy code saying the GC will
take care of the memory.

So, based on this new radical point of view of mine, I would say that a
well written program should not need GC. If each function/package cleans
after itself, and the programmer is careful, then there is no need
for GC. Programs that have memory leakage are programs that defective, and
so one should fix them, GC is not the solution, the solution is to go
fix the code itself instead, wich would eleminate the need to having GC
to start with.  Here, I just solved this GC issue once and for all.


Nasser

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[nasser]

In article <Pine.GSO.3.95.961020164601.4990D-100000@nunic.nu.edu>, Richard says...

>  And yet, David, we both know, and many readers of this forum know, that
>  many DoD projects are being programmed in C++.  I just learned of a
>  critical missile system, orginally planned to be done in Ada, which has
>  been programmed in C++.  
>
....
>  We need to make the case that Ada is a better business decision,
>  not just a better language design.
>


Why do we need to make this case?

If a manager does not want to use Ada, let them. 

If someone is not smart enough to see an advantage in using Ada,
let someone smarter than them take advantage of this fact, and 
produce better software using Ada, which means they'll sell
more software and make more money with less completion, since the
end customer only cares about the quality of the product, not what
language it was written in, let the free market and the free 
competition decide. (When I go buy a car, I only care that it is
a good quality car, not HOW and what tools where used to build it).

If I want to open my own software company (as an example!) , and I 
believe Ada is the better choice language over C or C++, then I'll 
be very happy to see less people using Ada and more using C and C++, 
because this means I will have less competition for producing higher 
quality software, and if I believe that using C and C++ produces more
problems in the software than when using Ada, then the more my 
competitions use C and C++, the better I'll be. 

Just IMHO offcourse.

Nasser

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Lance Kibblewhite]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>iNorman says
>
>"Harrumph! What about 64-bit UNsigned binary arithmetic?  32-bit
>arithmetic does not suffice for manipulating offsets into files larger
>than 4GB, or for calculating the amount of space available on some
>disks, or for timestamps accurate to the nearest millisecond and
>spanning a range of 16 months or more."
>
>
>Well if you are telling me that you have written applications that 
>do all the above, interesting ... I sure have not seen many such uses
>in the user code I have seen.
>
>I am particularly interested in your comments on manipulating offsets
>into files larger than 4GB, what operating system are you talking about
>here for interest :-)
>

Windows NT, with NTFS for instance. and Visual C++ does includes the
__int64 type for faciliate this.

Also Digital Unix.
-- Lance.

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[David Emery]

Nasser said:
...
>If someone is not smart enough to see an advantage in using Ada,
>let someone smarter than them take advantage of this fact, and 
>produce better software using Ada, which means they'll sell
>more software and make more money with less completion, since the
>end customer only cares about the quality of the product, not what
>language it was written in, let the free market and the free 
>competition decide. (When I go buy a car, I only care that it is
>a good quality car, not HOW and what tools where used to build it).

The problem with this is that it takes the "commercial" view of things.
If my Mac crashes, usually the results are a few cusswords, 15 minutes
lost time, and I reboot.  But this "market-based" model doesn't work 
for safety-critical or embedded systems.  It's really rough to have to 
reboot an airplane in mid-flight.  And it's very difficult to send an upgrade
to every washing machine in the world, when the software has a bug in it.

For military systems, my life could very well depend on the system working
correctly the first time (this is no idle comment, I'm in the U.S. Army 
Reserves...)   We can't afford to wait for version 3.1 of a strategic
defense system to work correctly; after the first usage the bugs will 
all probably end up looking like Mothra...  

Unfortunately, the current market-driven commercial software model does 
not place a high value on quality.    This is why following commercial
models is not the right view for most (but not all) defense projects.  And
it's why regulatory and acquisition agencies (not just the DoD) have
standards, policies and mandates.  

In the military domain, mandates make sense.  Nassar's model works OK in
the commercial domain, -if- quality becomes a significant factor in 
that domain.  

				dave
--
<.sig is away on vacation>

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:

> I think it would be a GOOD THING if all Ada compilers (and all C compilers
> for that matter) supported 64-bit integers.
> 
> The interesting thing is that obviously there has not been too much pressure
> in the past for this, since almost all Ada 83 compilers and almost all C
> and C++ compilers for 32-bit machines do NOT support 64-bit integers, even
> though it is really pretty simple to do. So from that I conclude that at
> least in the past it has not been a major requirement.

In the past, there were no machines with 64-bit address spaces; now
there are several.  As Robert is well aware, several vendors of 64-bit
machines have sought to establish a common set of rules about how the C
integral types should correspond to 8-bit, 16-bit, 32-bit, and 64-bit
integers on 64-bit machines.

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

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <326B6DFD.732B@ainslie.com.au>,
Shayne Flint  <shayne@ainslie.com.au> wrote:
>I and other Ada users I know (and I suspect many organisations quietly
>using Ada) have felt this way for a long time. We would be mad to go out
>of our way to convince our competition to use Ada.
>
>Ada IS a competitive advantage for many developers including me! 

I disagree with this attitude.  Suppose everybody in the world used feet
and inches to measure lengths, and somebody comes up with a better way:
meters and millimeters, and so forth, where everything's a neat power of
10.  If you're the only company using meters, you're going to have a
hard time buying nuts and wrenches and so forth.  Even though it's
better.  The only way meters can *really* be better is if all your
suppliers adopt it as their normal way of measuring lengths.  Better
yet, all your employees should have learned about meters when they were
6 years old.  Sure, if that happens, then all your competitors will also
be able to use meters instead of inches, and they will benefit, too.

For Ada to succeed, it can't just be better in an isolated sense -- it
has to catch on.

If you were the last company on Earth using Ada, then you would not have
a competetive advantage -- you would be stuck shovelling money into the
last Ada compiler on Earth.  And it would be buggy and inefficient, and
the latest and greatest configuration management tools wouldn't work
with it.

- Bob

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:
 
> iNorman says
> 
> "Harrumph! What about 64-bit UNsigned binary arithmetic?  32-bit
> arithmetic does not suffice for manipulating offsets into files larger
> than 4GB, or for calculating the amount of space available on some
> disks, or for timestamps accurate to the nearest millisecond and
> spanning a range of 16 months or more."
> 
> Well if you are telling me that you have written applications that
> do all the above, interesting ... I sure have not seen many such uses
> in the user code I have seen.

I'm certainly aware of system code that does each of the above, and in
some cases there are 64-bit types in the APIs.  I am aware of certain
application areas in which 64-bit arithmetic is considered an absolute
requirement.
 
> I am particularly interested in your comments on manipulating offsets
> into files larger than 4GB, what operating system are you talking about
> here for interest :-)

I can only guess about the significance of the smiley, but AIX version 4
is one such operating system.

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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

iNorman said

"In the past, there were no machines with 64-bit address spaces; now
there are several.  As Robert is well aware, several vendors of 64-bit
machines have sought to establish a common set of rules about how the C
integral types should correspond to 8-bit, 16-bit, 32-bit, and 64-bit
integers on 64-bit machines.
"

Sought and failed so far? no?
or has there been progress here that I did not hear about. Last I heard
no one could agree.

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

iNorman says

"I'm certainly aware of system code that does each of the above, and in
some cases there are 64-bit types in the APIs.  I am aware of certain
application areas in which 64-bit arithmetic is considered an absolute
requirement."

Then how do you account for the fact that so few C compilers provide
64-bit integers?

Yes, this will change with 64-bit machines, but I still find it
surprising that on many machines you have to go to gcc to get decent
sized integers, and the same is true in the Ada 83 compiler world (did
ANY Ada 83 compiler implement 64-bit integers routinely?)

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Bob Duff said

"If you were the last company on Earth using Ada, then you would not have
a competetive advantage -- you would be stuck shovelling money into the
last Ada compiler on Earth.  And it would be buggy and inefficient, and
the latest and greatest configuration management tools wouldn't work
with it."

Unnecessarily pessimistic I think, in several respects. Sure this may be
true if you are talking about a proprietary compiler built and maintained
in a vacuum, but in fact it takes relatively little use of Ada to support
the continued development of GNAT, and the reason that is achievable is
that we maintain open systems standards precisely so that the "latest
and greatest configuration management tools" will work with minimial
or even zero effort.

We are committed to GNAT becoming the best compiler for any language, period.
Sure it would be nice if Ada really took off and became super succesful,
but our business plan does NOT depend on this hapenning, and GNAT can
continue to prosper and improve without depending on huge amounts of
resources. 

I think this is important. People have mentioned reently that top
management often worries about the future of Ada. If your only
response is to depend on the hope that Ada will become wildly
successful, then if I was in that position, I would ban Ada use
immediately. It is not that I am sure this will not happen, it is
that I certanly cannot say I am sure it will happen, and relying
on super sucess for Ada is far too risky.

It is much more convincing to be able to demonstrate that there will
be at least one usable high quality technology that allows the
potential of Ada 95 to be realized REGARDLESS of whether or not
Ada succeeds in grabbing a huge market share. Ironically, this
assurance that such success is not required is one thing that will
greatly help to increase the chances of such success.

I can't speak for any other Ada vendors, but Ada Core Technologies is
very optimistic about its future, and we see ourselves as being around
for the long term, and succeeding in continuing to improve the quality
of the compiler. Shortly we will release 3.07 which has some substantial
improvements. In fact, why not? here is a preview of the new features:

   GNAT now checks for the case of a body file present when the spec does
   not require a body. GNAT always diagnosed the error when the body was
   compiled, but if only the spec was compiled, the suspicious body was
   ignored. The presence of a body file when no body is allowed is now
   considered an error in Ada 95 mode, and a warning in Ada 83 mode.

   Packed arrays with bounds depending on a discriminant now work correctly

   The DEC pragmas have been implemented. Those of interest to GNAT ports
   in general are as follows (see below for full documentation)
       Common_Object
       Component_Alignment
       Export_Function
       Export_Object
       Export_Procedure
       Export_Valued_Procedure
       Import_Function
       Import_Object
       Import_Procedure
       Import_Valued_Procedure
       Suppress_All

   The DEC attributes have been implemented. Those of interest to GNAT ports
   in general are as follows (see below for full documentation)
       Bit
       Machine_Size
       Null_Parameter
       Type_Class

   Attribute Mechanism_Code allows determination of the parameter passing
   mechanism chosen by GNAT, as possibly controlled by the Import, Export
   and C_Pass_By_Copy pragmas.

   Pragma Extend_System allows transparent extension of package System to
   accomodate definitions from other implementations of Ada.

   Machine code insertions have been completely implemented. A new section
   in gnatinfo.txt describes the use. Both code statements as such, and
   also intrinsic calls are available. The latter allow interspersing
   machine instructions in Ada code. Inlining of machine code procedures
   is fully supported.

   The pragma C_Pass_By_Copy is implemented in a manner that is completely
   compatible with the Intermetrics implementation of this pragma.

   The default mechanism for passing records to foreign convention subprograms
   is now by-reference. This can be modified by either use of one of the
   DEC extended Import/Export pragmas, or by use of the C_Pass_By_Copy pragma.

   Further extended support for representation clauses, including more cases
   of misaligned fields, and non-standard layouts. Record representation
   clauses no longer require that the position of all fields be specified.

   Pragma Error_Monitoring has been removed. This pragma was not used and had
   a number of conceptual and implementation problems.

And of course that is 3.07, we are hard at work on 3.08, and have already
added many interesting new capabilities that will show up in 3.08. Not
listed in the above list is the general improvements in reliability and
performance that come from steady work on these aspects.

GNAT is still in its infancy if we take a long term view, which we do!
We have many ideas for improving its performance and realiability and
functionality, and fully expect to see these ideas realized in coming
years.

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Shayne Flint]

nasser@apldbio.com wrote:

> If a manager does not want to use Ada, let them.
> 
> If someone is not smart enough to see an advantage in using Ada,
> let someone smarter than them take advantage of this fact, and
> produce better software using Ada, which means they'll sell
> more software and make more money with less completion, since the
> end customer only cares about the quality of the product, not what
> language it was written in, let the free market and the free
> competition decide. (When I go buy a car, I only care that it is
> a good quality car, not HOW and what tools where used to build it).
> 
> If I want to open my own software company (as an example!) , and I
> believe Ada is the better choice language over C or C++, then I'll
> be very happy to see less people using Ada and more using C and C++,
> because this means I will have less competition for producing higher
> quality software, and if I believe that using C and C++ produces more
> problems in the software than when using Ada, then the more my
> competitions use C and C++, the better I'll be.
> 
> Just IMHO offcourse.
> 

I and other Ada users I know (and I suspect many organisations quietly
using Ada) have felt this way for a long time. We would be mad to go out
of our way to convince our competition to use Ada.

Ada IS a competitive advantage for many developers including me! 

Having said that, it is of course important to ensure that Ada
development tools continue to be developed and improved. This is, by the
way, going along very nicely - eg. ObjectAda, AppletMagic and Gnat.

--------------------------------------------------------------
-- Shayne Flint                          
-- Ainslie Software Pty Limited          
-- shayne@ainslie.com.au                
--------------------------------------------------------------

Re: Once again, Ada absent from DoD SBIR solicitation

[Dale Stanbrough]

Robert Dewar writes:

"Well that has a simple answer. The new operation is safe, the free is
 obviously not safe. Ada is designed as a safe language, and it is a
 deliberate decision to make the use of non-safe operations inconvenient
 and very clearly documented.
 
 No one even considered adding a Free keyword to Ada 9X, I cannot imagine
 anyone supporting such a change."


But it is there, at least in spirit. Package Ada.Strings.Unbounded
includes a free procedure for type String_Access.

Surely most package that export an access type also export the associated
"free" procedure?
If they do then aren't we getting into nit-picking? Whether it is
provided by the language, or by the implementor of an ADT, it is
there for use by client code.


Dale

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Shayne Flint]

Robert A Duff wrote:
> 
> In article <326B6DFD.732B@ainslie.com.au>,
> Shayne Flint  <shayne@ainslie.com.au> wrote:
> >I and other Ada users I know (and I suspect many organisations quietly
> >using Ada) have felt this way for a long time. We would be mad to go out
> >of our way to convince our competition to use Ada.
> >
> >Ada IS a competitive advantage for many developers including me!

I also said in the same post:

" Having said that, it is of course important to ensure that Ada
development tools continue to be developed and improved. This is, by the
way, going along very nicely - eg. ObjectAda, AppletMagic and Gnat. "


Robert A Duff continued:
> 
> I disagree with this attitude.  Suppose everybody in the world used feet
> and inches to measure lengths, and somebody comes up with a better way:
> meters and millimeters, and so forth, where everything's a neat power of
> 10.  If you're the only company using meters, you're going to have a
> hard time buying nuts and wrenches and so forth.  Even though it's
> better.  The only way meters can *really* be better is if all your
> suppliers adopt it as their normal way of measuring lengths.  Better
> yet, all your employees should have learned about meters when they were
> 6 years old.  Sure, if that happens, then all your competitors will also
> be able to use meters instead of inches, and they will benefit, too.

I'm not sure that you are going to get the world to use Ada. The USA
still uses inches! In any case Ada does interface with other languages
and systems with little effort. If we want to use Win32, we can (it
doesn't have to be written in Ada), we can use Java libraries (with
AppletMagic), we talk to X/Motif, SQL databases, etc. every day. Ada is
compatible with other standards.

> 
> For Ada to succeed, it can't just be better in an isolated sense -- it
> has to catch on.
> 

Well it is catching on enough to survive and that is what counts. It
does not have to be as popular as C/C++/Java. I have spent the last 15
years using, promoting and selling Ada products and I am convinced that
Ada will be around for a long long time, and that it will continue to
develop in terms of tools and understanding in the wider market place.

> If you were the last company on Earth using Ada, then you would not have
> a competetive advantage -- you would be stuck shovelling money into the
> last Ada compiler on Earth.  And it would be buggy and inefficient, and
> the latest and greatest configuration management tools wouldn't work
> with it.

If this were the case, then obviously the use of Ada would not be a
competitive advantage. If Ada were to die, it would not be because of
C/C++/Java (ie. popular technologies) - it will be because better
technology had appeared. Such technology may not be popular, but we
would still use it if it gave us an advantage.

Regards,
Shayne...

--------------------------------------------------------------
-- Shayne Flint                          
-- Ainslie Software Pty Limited          
-- shayne@ainslie.com.au                 
--------------------------------------------------------------

Re: Why no Propagates?

[Richard A. O'Keefe]

gauthier@unilim.fr (Michel Gauthier) writes:
[about Java-like exception annotations]

>I fully agree that " it would be a cool feature to have", but I concluded
>long ago that it would be very difficult to make it compatible with
>all the other features of the language. Possibly an additional effort
>on ANNotated Ada in this direction would have been useful, but
>we cannot hope a full solution.

Just a suggestion:
    this is precisely the kind of thing which a compiler can find out
    for you and put in a cross-reference file or listing or hypertext
    or whatever.

Typically, what you want to know is not "what exceptions can this procedure
raise" but "where is this exception raised" or "what exceptions might reach
this handler", which the Java syntax doesn't help with as much as one might
hope.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

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

> Yes, this will change with 64-bit machines, but I still find it
> surprising that on many machines you have to go to gcc to get decent
> sized integers, and the same is true in the Ada 83 compiler world (did
> ANY Ada 83 compiler implement 64-bit integers routinely?)

As ACT is certainly aware, DEC Ada for Alpha VMS routinely supplies:

   type LONG_INTEGER is {range -2**63 .. 2**63 - 1};
   type INTEGER is {range -2_147_483_648 .. 2_147_483_647};

in order to keep the name "INTEGER" compatible with DEC Ada for VAX VMS.

An INTEGER by any other name would smell just as sweet ?

Larry Kilgallen

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Tarjei Jensen]

Considering the C++ track record to date I would be more worried if I had a few
hundred thousand C++ sourcelines under maintenance than if they were in Ada.

With Ada I would not expect any major upheavals. With C++ anything could happen.

In the short term the risk of C++ could be view as small. In the long term I
don't know. If I had large amounts of legacy C++ code I would be worried.


Greetings,

 
-- 
// Tarjei T. Jensen 
//    tarjeij@ulrik.uio.no || fax +47 51664292  || voice +47 51 85 87 39
//   Support you local rescue centre: GET LOST!
// Working, but not speaking for the Norwegian Hydrographic Service.

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Rush Kester]

In a follow-up to Richard, nasser@apldbio.com wrote:
R: In article <Pine.GSO.3.95.961020164601.4990D-100000@nunic.nu.edu>, says...
R: >  And yet, David, we both know, and many readers of this forum know,that
R: >  many DoD projects are being programmed in C++.  I just learned of a
R: >  critical missile system, orginally planned to be done in Ada, which has
R: >  been programmed in C++.  
R: >
R: ....
R: >  We need to make the case that Ada is a better business decision,
R: >  not just a better language design.

N: Why do we need to make this case?

As a scientist/engineer, I feel the DoD needs to decide whether it
believes it's own statement that Ada lower's a systems life-cycle costs.
Having worked on a number of projects in a variety of languages, I believe
Ada is cost effective.  As a U.S. Taxpayer, it upsets me that DoD managers
are wasting my tax dollars. 
 
N: If a manager does not want to use Ada, let them. 

N: If someone is not smart enough to see an advantage in using Ada,
N: let someone smarter than them take advantage of this fact, and 
N: produce better software using Ada, which means they'll sell
N: more software and make more money with less completion, since the
N: end customer only cares about the quality of the product, not what
N: language it was written in, let the free market and the free 
N: competition decide. (When I go buy a car, I only care that it is
N: a good quality car, not HOW and what tools where used to build it).

If the DoD market was for volume sales of the same software package,
Nasser's argument that the free market would identify the "best" language
would hold.  However, unlike buying a car, the buyer in this case does not
have an existing product to examine and evaluate. 

For the DoD market, in most cases, software is custom built to the buyer's
specifications.  Most contractors will happily use whatever programming
language, tools, hardware, etc. the government specifies.  The incentives
to project managers, both contractor and government, is to minimize
development costs and ignore life-cycle costs.  However, the government
must pay not only development costs, but the cost to maintain and enhance
the system over its life time.

N: If I want to open my own software company (as an example!) , and I 
N: believe Ada is the better choice language over C or C++, then I'll 
N: be very happy to see less people using Ada and more using C and C++, 
N: because this means I will have less competition for producing higher 
N: quality software, and if I believe that using C and C++ produces more
N: problems in the software than when using Ada, then the more my 
N: competitions use C and C++, the better I'll be. 
N:
N: Just IMHO offcourse.
N:
N: Nasser

Where the customer doesn't have a preference for the language applications
are developed it, the above strategy will lead "smart" companies to
succeed.  However, in the case of the DoD, the customer has a preferred
language, whether it's stated explicitly in the project specifications or
implied by the current trend.  In these situations, it's contractors that
use the customer's "preferred"  language that will get business. 

Rush Kester
Sr. Software Engineer 
W (301) 640-3632 (in person M-F: 9am-5pm EDST, voicemail anytime)  
Fax        -4750 or -4940

-- 
Rush Kester
W (301) 640-3632 (in person M-F: 9am-5pm EDST, voicemail any time)
Fax        -4750 or -4940

Re: C++ Standardization (was: Once again,

[Ian Ward]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5472 bytes --]


In article cs2@ratatosk.uio.no, tarjeij@ulrik.uio.no (Tarjei Jensen) writes:
>Considering the C++ track record to date I would be more worried if I had a few
>hundred thousand C++ sourcelines under maintenance than if they were in Ada.
>
>With Ada I would not expect any major upheavals. With C++ anything could happen.
>
>In the short term the risk of C++ could be view as small. In the long term I
>don't know. If I had large amounts of legacy C++ code I would be worried.
>
>
>Greetings,
>
> 
>-- 
>// Tarjei T. Jensen 
>//    tarjeij@ulrik.uio.no || fax +47 51664292  || voice +47 51 85 87 39
>//   Support you local rescue centre: GET LOST!
>// Working, but not speaking for the Norwegian Hydrographic Service.

I agree totally with this.

One argument against the thriving of C++....

In my opinion, there are a strong body of people out there who, these days
are striving to make reliable code, but who are, quite wisely from their
fiscal point of view, (if not for software engineering as a whole) wanting
to keep the same sort of syntax for their code as they always have. (They
recognise it. Tt is a lot easier to write say, down the page instead of 
across in English, with the english characters, than it is to have to get
used to looking at the Mandarin or Cantonese character set, at the same time.)

It is these people I think, (the ones interested in building a more capable
'C',) that initially were the driving force behind the C++ explosion. Most
of the other people that use it are just raving hackers, who really write
'C' under C++'s banner. I have looked at C++, quite a bit, in fact, though
obviously not enough to pass an interview. A lot of the things said about
it, I agree with - most of them about the big system building. It was not
a bad first step.

It is still a complex language though, very complex compared to Ada, at
least to look at. I am not sure what notorious "blow your leg off comment"
was exactly about, but I suspect that the originator of it recognised that
a lot of the flexibility of the language, most notably the ease of pointers,
still was going to cause havoc for the average programmer during the long
run of big system creation.

As a consequence of this, I think that the original people that caused the
C++ explosion will be the people that recognise advantages Java has over
C++, and will be the people who instigate that Java explosion. (I am sure
that Java is not flawless either, but I do not know enough about it yet
to give a serious opinion.)

This is a good thing, there are two distinct approaches to manufacture of,
well, anything. One is to think about the problem, a lot, and to design 
an effective solution. The other is to start work on it, and applying
fixes to it as the process develops. If we consider Ada to be
at one edge, designing out the errors before the project starts, and 
'C' to be at the other with its host of (absolutely necessary) tools,
then C++ and Java are in the middle. In my opinion, software engineers
are migrating across, the playing field, albeit in small steps.

Eventually, due to the pressure of the people who actually want to get
the bastard thing to work, all but the most specialised languages will
design out common human mistakes, and use the computer to check the
paperwork for the authors.

If I am right, then the C++ code out there at the moment will become the
most horrendous legacy. People have made one step away from 'C', I think
the next step will be a bit easier for them. The first step is always the
hardest.


One argument for the defence of Ada.

I don't know if anyone remembers, but there used to be this old television
programme called "Kung Fu", with David Carradine as "Caine".
In one of the episodes, Master Po (the blind guy) said to Caine that when
defending oneself against an attacker who wished to kill you, all you had
to do was survive. If you did this, he had failed.
In an additional piece of history, less fictitious, and less well known,
my Grandfather was in a field with my Dad (they wer both drillers,) when
the subject of the Berlin Wall, which was being laid at the time, came up.
"Nice as the theory is, communism is flawed," said my grandad, "no matter
how strong it is, if it isn't knocked over, it will collapse from within."
Now, I am sure he was thinking in terms of basic human greed, rather than
Maslow's hierarchy of needs, and, although the USSR outlived him by 13�
years, he was right.

The analogy here is that there are some things that C++ cannot do,
namely airborne software. Now I am sure someone will come up with 
cases where I am wrong, but I would rather walk than fly with aircraft
whose Bus Controller was written in the language. I am sure I am not
the only one. People who work in embedded avionics generally have an
entrirely different definition of the word "reliable" to other
programmers. Thankfully, the people who make the decisions, generally
agree with me.

Until something comes along which is better than Ada at this game,
(which neither 'C', C++ and I am sure Java, are not) then Ada WILL survive.
Additionally, the revamped Ada95 is now a damned good general purpose
language. More importantly it can be acquired for nothing. This fact, its
freeness, above all others will, I believe, be the making of it. As a
fringe language, it would not have originally been taken on by the free
software people had it been crap. 











---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <326C1473.433C@ainslie.com.au>,
Shayne Flint  <shayne@ainslie.com.au> wrote:
>I'm not sure that you are going to get the world to use Ada.

Perhaps not.  But I'm hoping Ada use will be at least a substantial
minority.

>...The USA
>still uses inches!

Sad.

>...In any case Ada does interface with other languages
>and systems with little effort. If we want to use Win32, we can (it
>doesn't have to be written in Ada), we can use Java libraries (with
>AppletMagic), we talk to X/Motif, SQL databases, etc. every day. Ada is
>compatible with other standards.

Quite true, and this is good.  One of the most important requirements of
the Ada 9X project was to make these kinds of interfaces easy.

However, interfacing is still not painless.  If Win32 were written in
Ada, then interfacing to it from Ada would be somewhat easier.

>> For Ada to succeed, it can't just be better in an isolated sense -- it
>> has to catch on.
>> 
>
>Well it is catching on enough to survive and that is what counts. ...

Agreed.

- Bob

Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[Ken Garlington]

Robert A Duff wrote:
> 
> If you were the last company on Earth using Ada, then you would not have
> a competetive advantage -- you would be stuck shovelling money into the
> last Ada compiler on Earth.  And it would be buggy and inefficient, and
> the latest and greatest configuration management tools wouldn't work
> with it.

Oh, I dunno. I was on a project where we were competing with other companies
for a Government contract. For the particular host/target we were using, we
ended up being the only company shoveling money (and a lot of it) into an
Ada compiler for that host/target. Yet, we won the contract, more than making
up the extra expense of the money we spent. I can't say Ada was a reason we
won, or the only reason we won, but we did win.

I would certainly prefer to have Ada be widely accepted. However, I can understand
someone using a proprietary process to gain an advantage -- even if that process
is known to the world.

> - Bob

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

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Larry Kilgallen]

In article <dewar.846049177@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> "As ACT is certainly aware, DEC Ada for Alpha VMS routinely supplies:
> 
>    type LONG_INTEGER is {range -2**63 .. 2**63 - 1};
>    type INTEGER is {range -2_147_483_648 .. 2_147_483_647};"
> 
> Yes, that's true, although the DEC Ada 83 reference manual still says
> that LONG_INTEGER is 32 bits, at least the version we have does!

I believe the change is documented in the DEC Ada 3.2 for Alpha VMS
release notes or so.  Sometimes the reference manuals get updated
on CD-ROM before they do on paper, but sometimes they don't.

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Robert Dewar]

Larry said

"As ACT is certainly aware, DEC Ada for Alpha VMS routinely supplies:

   type LONG_INTEGER is {range -2**63 .. 2**63 - 1};
   type INTEGER is {range -2_147_483_648 .. 2_147_483_647};"

Yes, that's true, although the DEC Ada 83 reference manual still says
that LONG_INTEGER is 32 bits, at least the version we have does!

Re: Why no Propagates?

[Michel Gauthier]

In article <54hjb7$bmm$1@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au
(Richard A. O'Keefe) wrote:

>>  gauthier@unilim.fr (Michel Gauthier) writes:
>>  [about Java-like exception annotations]
>>  
>>  >I fully agree that " it would be a cool feature to have", but I concluded
>>  >long ago that it would be very difficult to make it compatible with
>>  >all the other features of the language. Possibly an additional effort
>>  >on ANNotated Ada in this direction would have been useful, but
>>  >we cannot hope a full solution.
>>  
>>  Just a suggestion:
>>      this is precisely the kind of thing which a compiler can find out
>>      for you and put in a cross-reference file or listing or hypertext
>>      or whatever.
>>  
>>  Typically, what you want to know is not "what exceptions can this procedure
>>  raise" but "where is this exception raised" or "what exceptions might reach
>>  this handler", which the Java syntax doesn't help with as much as one might
>>  hope.

Yes,  Richard, I agree.

Additionally, a thesis work is in process about such an issue.

But it is not as simple as we could wish. Without genericity
and exception identities, things goes rather well, but there is a
need of eliminating "unreachable raises" by program proofs.
How reliable are these proofs ?

If you add genericity, this requires additional parameterisation
by sets of exceptionbs (alone exceptions are not powerful enough).
Such parameters are not necessarily required by the language rules.
Of course, access-to-subprograms make the same problem arise.

If you add exception identities, then you can pray, or prefer good
style rules, or even insert sensible assertions. In this case, 
assertions are required with all exception raises, which very few
people do.

This is what I intended to say in my initial message.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
    a partir du 19 octobre, depuis la France  : 05 55 45 73 35 
     from october,19 on, and from abroad : +33 5 55 45 73 35
fax +33 ()  55457315  [or ~7201]  
    and similar evolution
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Portability of Arithmetic (was: Java vs Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:

> Then how do you account for the fact that so few C compilers provide
> 64-bit integers?

Most C compilers are old.

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

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

  > If you really really want such strange arithmetic (perhaps to acomodate
  > a Java-to-Ada translator :-) then you could program it easily enough
  > using unchecked conversion and modular and signed arithmetic mixed in
  > the appropriate odd way.

  Is it that odd?  You use the Unsigned arithmetic operators except
for divison and for 'PRED and 'SUCC and the Integer operations for all
the rest.  Certainly peculiar, but defining such a type is not
hard--except that it's real behavior emerges when passed as a generic
formal type.

--

					Robert I. Eachus

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

Re: Once again, Ada absent from DoD SBIR solicitation

[Robert Dewar]

"Surely most package that export an access type also export the associated
"free" procedure?
If they do then aren't we getting into nit-picking? Whether it is
provided by the language, or by the implementor of an ADT, it is
there for use by client code.
"

Partly true, and partly not true, but in any case irrelevant to the question,
which was why is new a first class citizen IN THE LANGUAGE, while free is
not!

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Kenneth Almquist]

mg@dsd.camb.inmet.com (Mitch Gart) wrote:
> 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.

No it won't.  Dispatching only occurs when you use class-wide types.[1]

You don't explain why you are using access types.  Normally you would
write:

   type parent_obj is tagged record ...;
   procedure p(param: in out parent_obj);

   type child_obj is new parent_obj with ...;
   procedure p(param: in out child_obj);

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

   p(parent_obj(param));

This reads quite well (or at least it would if parent_obj had a meaningful
name).
					Kenneth Almquist


[1] You don't want to convert to parent_ptr because of the possibility
    of accessibility errors.  Instead use a pointer type declared in p:

procedure p(param: access child_obj) is
   type super is access all parent_obj;
begin
   ...
   p(super(param));  -- call the parent's p
   ...
end p;

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Kenneth Almquist]

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

There may be no distributed overhead, but there certainly is overhead.
Here are some numbers from a toy benchmark:

	Ada with Unbounded_String:  10.02 seconds
	Icon (interpreted):          1.45 seconds

The Icon translator I used to get the above number performs *no*
optimizations whatsoever.  It produces byte codes which are interpreted.
There are no type declarations in Icon, so every time a value is used
its type must be checked at run time.  Simple integer code compiled
using GNAT runs 400 times faster than the equivalent Icon code.  Never
the less, Icon beats GNAT by a factor of 7 on the string code shown at
the end of this article.

I suspect that automatic garbage collection is required to implement
unbounded strings efficiently.  In Icon, the assignment "b := a" can
be performed by simply copying a pointer.
				Kenneth Almquist



----------------------------------------------------------------------
Details of benchmark numbers:

The Ada code was compiled using GNAT 3.05 in -O2 mode, and the Icon code
was run using version 8.10 of the interpreter from the University of
Arizona.  Test system:  90 Mhz Pentium on a Plato motherboard, running
the Linux operating system.

-- Version 1:  Ada with Unbounded_String:
with ada.strings.unbounded, ada.text_io;
use  ada.strings.unbounded, ada.text_io;
procedure str_speed is
    a, b, c: unbounded_string;
begin
    a := to_unbounded_string("abcdefghijklmnopqrstuvwxyz");
    b := to_unbounded_string("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
    for i in 1 .. 40_000 loop
        c :=  b & a & b;
        b := a;
        a := to_unbounded_string(slice(c, 1, 26));
    end loop;
    put_line(to_string(c));
end str_speed;


# Version 2:  Icon
procedure main()
    local a, b, c, i

    a := "abcdefghijklmnopqrstuvwxyz"
    b := "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
    every i := 1 to 40000 do {
        c :=  b || a || b;
        b := a;
        a := c[1 : 27];
    }
    write(c)
end

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <554c5d$4ag@nntpa.cb.lucent.com> ka@socrates.hr.att.com (Kenneth Almquist) writes:

Neat example of Unbounded_String and Icon strings in comparison.
Example pretty much speaks for itself.  My my my - what do the
nay-sayers think about this?  :-)

> I suspect that automatic garbage collection is required to implement
> unbounded strings efficiently.  In Icon, the assignment "b := a" can
> be performed by simply copying a pointer.

Yup, I don't see how you can compete with this using good ol' _new_
(malloc, whatever) and free...

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Kenneth says

"I suspect that automatic garbage collection is required to implement
unbounded strings efficiently.  In Icon, the assignment "b := a" can
be performed by simply copying a pointer."


This is an unjustified generalization from one benchmark. There are two
ways of handling unbounded strings, copy on modify and copy on assignment.
It is trivial to write a benchmark that will kill the ICON copy on 
assignment model, you just chose something which was the other way round.

Invoking parental methods (was: Java vs Ada 95)

[Larry Kilgallen]

I apologize for the following long quote, but "who said what to whom
gets messy here".

In article <5536en$2vk@nntpa.cb.lucent.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes:
> mg@dsd.camb.inmet.com (Mitch Gart) wrote:
>> 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.
> 
> No it won't.  Dispatching only occurs when you use class-wide types.[1]
> 
> You don't explain why you are using access types.  Normally you would
> write:
> 
>    type parent_obj is tagged record ...;
>    procedure p(param: in out parent_obj);
> 
>    type child_obj is new parent_obj with ...;
>    procedure p(param: in out child_obj);
> 
> Now inside the child's p, to call the parent's p:
> 
>    p(parent_obj(param));
> 
> This reads quite well (or at least it would if parent_obj had a meaningful
> name).
> 					Kenneth Almquist
> 
> 
> [1] You don't want to convert to parent_ptr because of the possibility
>     of accessibility errors.  Instead use a pointer type declared in p:
> 
> procedure p(param: access child_obj) is
>    type super is access all parent_obj;
> begin
>    ...
>    p(super(param));  -- call the parent's p
>    ...
> end p;

Declaring a pointer type within p does not meet the requirement
of minimizing the change required when an intermediate generation
gets inserted and there are many such invocations.  Why can't it
be declared at the top of the package ?

Larry Kilgallen

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

    Kenneth Almquist (ka@socrates.hr.att.com) said:

  > There may be no distributed overhead, but there certainly is overhead.
  > Here are some numbers from a toy benchmark:

  >	Ada with Unbounded_String:  10.02 seconds
  >	Icon (interpreted):          1.45 seconds

    First, nice benchmark.

    Second, do you have another version of gnat around?  If not 3.07
should be available soon.  This is one area where the reference
vs. value calling sequence pessimization is probably heavily felt, so
earlier (and later) versions of gnat should do better.

    Will it beat the Icon time?  I don't know, but certainly if it
doesn't the performance "problem" may occur other than in the gc
routines.  Even if Unbounded_String is implemented with a Controlled
type, clever optimization using RM rules only requires memory
allocation and freeing three times total.  (Finalization and the value
copies must occur, but there is no requirement to allocate new memory
when the new object is the same size, see 7.6(21).)

--

					Robert I. Eachus

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Stephen Leake]

Kenneth Almquist wrote:
> [snip]
>
> There may be no distributed overhead, but there certainly is overhead.
> Here are some numbers from a toy benchmark:
> 
>         Ada with Unbounded_String:  10.02 seconds
>         Icon (interpreted):          1.45 seconds
> 
> [snip]
> 
> I suspect that automatic garbage collection is required to implement
> unbounded strings efficiently.  In Icon, the assignment "b := a" can
> be performed by simply copying a pointer.

If Icon is assigning pointers, and Ada is copying values, these are NOT
comparable benchmarks! To get a real comparison, the semantics must
match.

>                                 Kenneth Almquist
-- 
- Stephe

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Kenneth Almquist]

> Kenneth says
>
> "I suspect that automatic garbage collection is required to implement
> unbounded strings efficiently.  In Icon, the assignment "b := a" can
> be performed by simply copying a pointer."
>
> This is an unjustified generalization from one benchmark.  There are two
> ways of handling unbounded strings, copy on modify and copy on assignment.
> It is trivial to write a benchmark that will kill the ICON copy on 
> assignment model, you just chose something which was the other way round.

The benchmark I presented did concatenation, assignment, and substring
operations.  What operations do you think a string benchmark should
contain, if not these?

In any case, the GNAT code ran so slowly that issues like copying don't
really change the picture.  We can cause the Icon interpreter to copy
a string before assignment by concatenating an empty string.  The
resulting timings are:

	 1.39 seconds for Icon
	 1.59 seconds for Icon with copy before assignment
	10.03 seconds for GNAT

The first number is a little lower than the value I gave in my previous
post because I deleted a null statement.  (The Icon interpreter takes
about a microsecond to execute a null statement.)

The point of my comment about doing string assignment by copying a
single pointer is that garbage collection allows you to eliminate
essentially all the code that GNAT currently generates for unbounded
string assignments.  Currently, copying the contents of the string is
only a small part of that.

If you can find a way to speed up the code that GNAT generates for
controlled types to the point that the majority of the cost of
assigning an unbounded string is the cost of copying the contents
of the string, then I'll post an article here complaining that the
GNAT implementation of unbounded string is unacceptably slow because
it copies the contents of strings on every assignment.  :-)  But my
guess is that no amount of work on the way GNAT handles controlled
types will get you to that point.  That's why I stated in my earlier
article that efficient implementation of Unbounded_String probably
requires automatic garbage collection.
				Kenneth Almquist



--------------------------------------------------------------------
# Version of benchmark where we prevent sharing of string memory by
# concatenating the null string before assignment when necessary.
procedure main()
    local a, b, c, i, first

    a := "abcdefghijklmnopqrstuvwxyz"
    b := "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
    every i := 1 to 40000 do {
        c :=  b || a || b
        b := a || ""
        a := c[1 : 27] || ""
    }
    write(c)
end

Re: Invoking parental methods (was: Java vs Ada 95)

[Larry Kilgallen]

In article <5599k7$bjr@nntpa.cb.lucent.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes:
>> In article <5536en$2vk@nntpa.cb.lucent.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes:
>>> procedure p(param: access child_obj) is
>>>    type super is access all parent_obj;
>>> begin
>>>    ...
>>>    p(super(param));  -- call the parent's p
>>>    ...
>>> end p;
>>
>> Declaring a pointer type within p does not meet the requirement
>> of minimizing the change required when an intermediate generation
>> gets inserted and there are many such invocations.  Why can't it
>> be declared at the top of the package ?
> 
> Because of the accessibility rules, which are designed to prevent
> dangling references to local variables.  The code below illustrates
> the problem that they are designed to solve.  As the comment notes,
> Ada prevents a dangling reference from being created by raising
> Contraint_Error when an attempt is made to convert the argument to
> and Obj_Ptr.
> 
> If you want to minimize the changes required when inserting an
> intermediate generation, declare "subtype Super is Parent_Ptr;" at
> the top of the package, and the declare "type Super_Ptr is access
> all Super;" in each of the individual routines.
> 				Kenneth Almquist
> 
> 
> procedure Outer is
>     type Obj is record
>         I : Integer;
>     end record;
>     type Obj_Ptr is access all Obj;
> 
>     Dangling_Reference : Obj_Ptr;
> 
>     procedure Create_Dangling_Reference(P : access Obj) is
>         type T is access all Obj;
>         P2 : T;
>         P3 : Obj_Ptr;
>     begin
>         P2 := T(P);        -- Legal.
>         P3 := Obj_Ptr(P);  -- Raises Constraint_Error.
>         Dangling_Reference := P3;
>     end Create_Dangling_Reference;
> 
>     procedure Inner is
>         Data : aliased Obj;
>     begin
>         Create_Dangling_Reference(Obj'access);
>     end Inner;
> begin
>     Inner;
>     -- Dangling_Reference would point to a nonexistent object if
>     -- execution were to reach this point.  Fortunately, execution
>     -- does not reach this point because Constraint_Error is raised
>     -- above.
>     Dangling_Reference.I := 0;
> end Outer;

But the dangling reference seems to be precipitated by the
the pointer object, not by the the pointer type.
What is wrong with:

    type super is access all parent_obj; -- this line may get changed

    procedure p_first(param: access child_obj) is
    begin
       ...
       p_first(super(param));  -- call the parent's p_first
       ...
    end p_first;

    procedure p_second(param: access child_obj) is
    begin
       ...
       p_second(super(param));  -- call the parent's p_second
       ...
    end p_second;

    procedure p_third(param: access child_obj) is
    begin
       ...
       p_third(super(param));  -- call the parent's p_third
       ...
    end p;

Larry Kilgallen

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <32776D5D.5768@gsfc.nasa.gov> Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

> Kenneth Almquist wrote:
> > [snip]
> >
> > There may be no distributed overhead, but there certainly is overhead.
> > Here are some numbers from a toy benchmark:
> > 
> >         Ada with Unbounded_String:  10.02 seconds
> >         Icon (interpreted):          1.45 seconds
> > 
> > [snip]
> > 
> > I suspect that automatic garbage collection is required to implement
> > unbounded strings efficiently.  In Icon, the assignment "b := a" can
> > be performed by simply copying a pointer.
> 
> If Icon is assigning pointers, and Ada is copying values, these are NOT
> comparable benchmarks! To get a real comparison, the semantics must
> match.

Huh?  Of course the semantics match - at the programmers level!  Which
is all that matters in this case.  These are _completely_ comparable
benchmarks - they do the same task in virtually the same user level
coding style.  The difference is "simply" one of quality of service
and this comes in large part from the Icon technique for string
storage management (which is GC based).

You could do something similar for an Unbounded_String impl, and then
you would have a specific type which had GC in your implementation.
But it would not be based on malloc/adjusting/copying/freeing (which
will never be able to compete here).

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Kenneth Almquist]

eachus@spectre.mitre.org (Robert I. Eachus) writes:
>     Second, do you have another version of gnat around?  If not 3.07
> should be available soon.  This is one area where the reference
> vs. value calling sequence pessimization is probably heavily felt, so
> earlier (and later) versions of gnat should do better.

I have an older version, but it generates a.out format binaries
and I can't get it to work with the ELF tools I recently installed.

>     Will it beat the Icon time?  I don't know, but certainly if it
> doesn't the performance "problem" may occur other than in the gc
> routines.  Even if Unbounded_String is implemented with a Controlled
> type, clever optimization using RM rules only requires memory
> allocation and freeing three times total.

The allocations and dealocations appear explicitly in the Adjust and
Finalize operations for the Unbounded_String type.  (The Unbounded_
String objects are not allocated or deleted inside the loop; only
the memory containing the values of the unbounded strings.)

It occurs to me that a comparison with Modula 3 speed would be more
meaningful than a comparison with Icon interpreter speed.  Modula 3 is
a compiled languge, and even uses the GCC back end on most systems.
Unfortunately I don't have Modula 3 installed anywhere...
				Kenneth Almquist

Invoking parental methods (was: Java vs Ada 95)

[Kenneth Almquist]

> In article <5536en$2vk@nntpa.cb.lucent.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes:
>> procedure p(param: access child_obj) is
>>    type super is access all parent_obj;
>> begin
>>    ...
>>    p(super(param));  -- call the parent's p
>>    ...
>> end p;
>
> Declaring a pointer type within p does not meet the requirement
> of minimizing the change required when an intermediate generation
> gets inserted and there are many such invocations.  Why can't it
> be declared at the top of the package ?

Because of the accessibility rules, which are designed to prevent
dangling references to local variables.  The code below illustrates
the problem that they are designed to solve.  As the comment notes,
Ada prevents a dangling reference from being created by raising
Contraint_Error when an attempt is made to convert the argument to
and Obj_Ptr.

If you want to minimize the changes required when inserting an
intermediate generation, declare "subtype Super is Parent_Ptr;" at
the top of the package, and the declare "type Super_Ptr is access
all Super;" in each of the individual routines.
				Kenneth Almquist


procedure Outer is
    type Obj is record
        I : Integer;
    end record;
    type Obj_Ptr is access all Obj;

    Dangling_Reference : Obj_Ptr;

    procedure Create_Dangling_Reference(P : access Obj) is
        type T is access all Obj;
        P2 : T;
        P3 : Obj_Ptr;
    begin
        P2 := T(P);        -- Legal.
        P3 := Obj_Ptr(P);  -- Raises Constraint_Error.
        Dangling_Reference := P3;
    end Create_Dangling_Reference;

    procedure Inner is
        Data : aliased Obj;
    begin
        Create_Dangling_Reference(Obj'access);
    end Inner;
begin
    Inner;
    -- Dangling_Reference would point to a nonexistent object if
    -- execution were to reach this point.  Fortunately, execution
    -- does not reach this point because Constraint_Error is raised
    -- above.
    Dangling_Reference.I := 0;
end Outer;

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Lars Farm]

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:

> If Icon is assigning pointers, and Ada is copying values, these are NOT
> comparable benchmarks! To get a real comparison, the semantics must
> match.

The point of GC is that it allows simpler, but still correct solutions.
Simpler sometimes means faster too.

Most are well aware that collecting garbage takes time. "GC is slow".
Most ignore that with GC the need to copy datastructures is smaller.
Less copying means faster. As long as reference counting is there to
know when to release data, there is no need for reference counts.

FWIW I tried the benchmark in c++ on a PowerPC 604/120, a PowerMac 8500.
I used the standard string class (refcounted) and Boehms GC + his string
wrapped in a string class similar to the stdlib string.

 - refcounted std string:   2.8 s
 - Boehms GC and string:    0.4 s including 32 garbage collections

I don't know how Icon or Ada strings are implemented. I don't know what
kind of GC Icon uses. Still the results are similar. Boehms strings
concatenate and assign fast (pointers only) and copy on substring
extraction (once per iteration). The standard string class copies on
concatenation and substring extraction, but increments a referece count
on assignment.


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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <EACHUS.96Nov1103759@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>    Yes, an implementation of Unbounded_String which uses reference
>counts and lazy copying would work much better in this case.  It is a
>perfectly legal and reasonable implementation of Unbounded_String, and
>it looks like it would take a day or two to gin up.  The question is
>whether it would be a global win, or just specific to some cases.  My
>guess is that it is a net win in general, but only a few percent. I
>may try it, but not this week.

Note that in Ada, or any language with tasking, the reference count
updates have to do locking in general, which might be rather expensive.

- Bob

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

In article <JSA.96Oct31145647@alexandria> jsa@alexandria (Jon S Anthony) writes:

  > You could do something similar for an Unbounded_String impl, and then
  > you would have a specific type which had GC in your implementation.
  > But it would not be based on malloc/adjusting/copying/freeing (which
  > will never be able to compete here).

    Yes, an implementation of Unbounded_String which uses reference
counts and lazy copying would work much better in this case.  It is a
perfectly legal and reasonable implementation of Unbounded_String, and
it looks like it would take a day or two to gin up.  The question is
whether it would be a global win, or just specific to some cases.  My
guess is that it is a net win in general, but only a few percent. I
may try it, but not this week.

    Besides, it would be better to do it against 3.07 to get a real
comparison.


--

					Robert I. Eachus

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Jon S Anthony]

In article <19961031103614491013@dialup122-5-3.swipnet.se> lars.farm@ite.mh.se (Lars Farm) writes:

> FWIW I tried the benchmark in c++ on a PowerPC 604/120, a PowerMac 8500.
> I used the standard string class (refcounted) and Boehms GC + his string
> wrapped in a string class similar to the stdlib string.
> 
>  - refcounted std string:   2.8 s
>  - Boehms GC and string:    0.4 s including 32 garbage collections

The refcounted time is probably around what the GNAT time would be if
3.04 or 3.07 were used (3.05 has a serious performance bug in always
copying structures).  Ken, did you use 3.05 GNAT in this test???


> I don't know how Icon or Ada strings are implemented. I don't know what
> kind of GC Icon uses. Still the results are similar. Boehms strings

For pretty complete answer to the Icon question, see:

The Implementation of the Icon Programming Language, Griswold&Griswold.
It is pretty clever.


> concatenate and assign fast (pointers only) and copy on substring
> extraction (once per iteration). The standard string class copies on
> concatenation and substring extraction, but increments a referece count
> on assignment.

It is worth noting that even the Boehm version in native code is still
only about 3 times better than the non-optimized byte code of Icon.

/Jon

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Robert Eachus said

"    Yes, an implementation of Unbounded_String which uses reference
counts and lazy copying would work much better in this case."

Be careful about casually suggesting reference counts. They are potentially
VERY expensive in a tasking context where taking a lock for incrementing
a reference count requires a system call.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <55gkch$gg6@fozzie.sun3.iaf.nl>,
Geert Bosch <geert@fozzie.sun3.iaf.nl> wrote:
>Robert A Duff (bobduff@world.std.com) wrote:
>`` Note that in Ada, or any language with tasking, the reference count
>   updates have to do locking in general, which might be rather
>   expensive. ''
>
>It is possible to have implementations that do not need locking for
>objects that are not aliased or allocated by an allocator (using new).

I don't understand what you mean by that.  I thought we were talking
about unbounded strings, and similar packages, where you allocate stuff
on the heap and use reference counting to know when to reclaim it.  The
stuff on the heap is, of course, aliased.

>In the more general case a very simple spin-lock is enough and the
>overhead should only be one memory-read when the object is not locked.
>String objects are locked almost never and when they are locked they
>are only locked for a short time.

True, but we're talking about an implementation of unbounded strings
where a simple string assignment is just a copy of a pointer.  Adding
locking, plus incr/decr of reference counts, is a substantial overhead
for such a simple operation.  If GC can eliminate that overhead, it may
well be a performance win, despite the fact that there is also some
GC-specific overhead.  (And I've seen some papers giving measurements
that agree with that suspicion.)

- Bob

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Geert said

">In the more general case a very simple spin-lock is enough and the
>overhead should only be one memory-read when the object is not locked.
>String objects are locked almost never and when they are locked they
>are only locked for a short time."


What do you mean by a very simple spin lock in a uniprocessor environment.
Can you explain, are you talking about an EWD style implementation of
semaphores using sequential memory models?

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Hannes Haug]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 
> Robert Eachus said
> 
> "    Yes, an implementation of Unbounded_String which uses reference
> counts and lazy copying would work much better in this case."
> 
> Be careful about casually suggesting reference counts. They are potentially
> VERY expensive in a tasking context where taking a lock for incrementing
> a reference count requires a system call.

I hope it will be possible to use a test-and-set-lock instruction in
an inlined while loop in gnat-3.08. This would be faster. Sometimes
you can't even trust the "system calls" (e.g. solaris semaphores).

 -hannes

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Larry says

"Running under an operating system on a uniprocessor there clearly
must be a method of yielding to the lock-holder.  In a preemptive
scheduling environment this is automatic (although a yielding call
is more polite).  In a non-preemptive scheduling environment,
a simple call to yield the processor should suffice, and that
still leaves the overhead as approximately a memory read and
test."

This is still far too vague to know what you have in mind, and henbce
to determine if (a) it works and (b) it is likely to violate priority
rules. Please give clear details.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

In article <1996Nov4.072757.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

  > Running under an operating system on a uniprocessor there clearly
  > must be a method of yielding to the lock-holder.  In a preemptive
  > scheduling environment this is automatic (although a yielding call
  > is more polite).  In a non-preemptive scheduling environment,
  > a simple call to yield the processor should suffice, and that
  > still leaves the overhead as approximately a memory read and
  > test.

   Not to pick on Larry--or anyone participating in this
discussion--but I am really confused.  Since all of the possible
modifications of Bounded_Strings must be done (legally) through a few
calls in the package, and Ada rules are really very clear in this
area, the Bounded_Strings package doesn't have to maintain any locks.

   It is the case that if you want to have a program which has
multiple tasks which reference the same bounded string, and one of
them does an update, then you have to have a synchronization point
before the next reference.

   Now as long as there are no synchronization points in the string
ops, you don't have a problem.  You can even allow for the case where
an allocation or free can be an external synchronization point.  The
only problem is transitive updates:

   Task 1:                     Task 2:

     Create string A;
     Create B = A; 
     Synch with task 2;          Synch with task 1;
     Modify B;                   Create string C = A;

     If you pay attention to the order of operations--and you have
atomic memory increment and decrement instruction--this works fine.
On systems where "cheap" synchronization operations are other than the
test and set model or counting semaphores, you may be limited to at
most two strings sharing the same text.  A better alternative would be
to put the creating task id in the heap object and only allow sharing
between strings created by the same task.  (It turns out not to be a
problem if a task goes away an a new task takes its identity.)

     So my proposal would be to write the code calling 'PRED and 'SUCC
on a volatile count field, and provide the current body on machines
which can't honor the pragma Volatile.  Oops!  One last merry little
detail.  Make the count type unsigned full word size so that you don't
get pessimistic code to deal with overflow.  (Yes, on some machines it
might be possible to have Unsigned'LAST + 1 pointers to the same
string object without overflowing memory, but I'm not going to worry
about it.)

--

					Robert I. Eachus

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <dewar.847053681@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Geert said
> 
> ">In the more general case a very simple spin-lock is enough and the
>>overhead should only be one memory-read when the object is not locked.
>>String objects are locked almost never and when they are locked they
>>are only locked for a short time."
> 
> 
> What do you mean by a very simple spin lock in a uniprocessor environment.

Running under an operating system on a uniprocessor there clearly
must be a method of yielding to the lock-holder.  In a preemptive
scheduling environment this is automatic (although a yielding call
is more polite).  In a non-preemptive scheduling environment,
a simple call to yield the processor should suffice, and that
still leaves the overhead as approximately a memory read and
test.

Larry Kilgallen

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Larry Kilgallen]

In article <EACHUS.96Nov4182340@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
> In article <1996Nov4.072757.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>   > Running under an operating system on a uniprocessor there clearly
>   > must be a method of yielding to the lock-holder.  In a preemptive
>   > scheduling environment this is automatic (although a yielding call
>   > is more polite).  In a non-preemptive scheduling environment,
>   > a simple call to yield the processor should suffice, and that
>   > still leaves the overhead as approximately a memory read and
>   > test.
> 
>    Not to pick on Larry--or anyone participating in this
> discussion--but I am really confused.  Since all of the possible
> modifications of Bounded_Strings must be done (legally) through a few
> calls in the package, and Ada rules are really very clear in this
> area, the Bounded_Strings package doesn't have to maintain any locks.
> 
>    It is the case that if you want to have a program which has
> multiple tasks which reference the same bounded string, and one of
> them does an update, then you have to have a synchronization point
> before the next reference.

I think the issue may be one of terminology clash.  What Ada folk
call a synchronization point may very well be implemented in what
OS folk call a spinlock.  I responded to what struck me as an
OS-style discussion (I did not introduce the term spinlock to
the thread) using OS-speak.  Perhaps we should be talking
about the overhead of a "synchronization point", but the
original claim was that it can be cheap where there is no
contention, so if nobody disagrees we can forget the term
"spinlock" was ever mentioned :-)

Larry

Re: Invoking parental methods (was: Java vs Ada 95)

[Larry Kilgallen]

In article <E0ED6w.24D.0.-s@inmet.camb.inmet.com>, mg@harp.camb.inmet.com (Mitch Gart) writes:
> Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
> 
> : But the dangling reference seems to be precipitated by the
> : the pointer object, not by the the pointer type.
> : What is wrong with:
> 
> :     type super is access all parent_obj; -- this line may get changed
> 
> :     procedure p_first(param: access child_obj) is
> :     begin
> :        ...
> :        p_first(super(param));  -- call the parent's p_first
> :        ...
> :     end p_first;
> 
> This is the trap I fell into the first time I tried to write this code.
> The above solution doesn't work because the type conversion super(param)
> converts param into a pointer to the parent type, but tag inside the
> object that is pointed to still says the object is a child_obj, not a 
> parent_obj, so the call dispatches to the wrong place.  This line
> 
> :        p_first(super(param));  -- call the parent's p_first
> 
> in fact doesn't call the parent's p_first, in spite of the comment.  If
> the object pointed to by "param" is a child_obj this call is an infinite
> resursion.

Then I would judge this area of Ada 95 quite flawed.
It is bad enough that ancillary changes must be made
when genealogy is modified, but lacking a straightforward
mechanism for knowing how many changes must be made to each
package really takes the cake.

Suggestions to survey all code for consequences when someone
simply wants an "inherited" belong right up there with assertions
that perfectly adequate code can be written in C if on pays strict
attention to all details.

Larry Kilgallen

Re: Invoking parental methods (was: Java vs Ada 95)

[Tucker Taft]

Mitch Gart (mg@harp.camb.inmet.com) wrote:

: Larry Kilgallen (kilgallen@eisner.decus.org) wrote:

: : But the dangling reference seems to be precipitated by the
: : the pointer object, not by the the pointer type.
: : What is wrong with:

: :     type super is access all parent_obj; -- this line may get changed

: :     procedure p_first(param: access child_obj) is
: :     begin
: :        ...
: :        p_first(super(param));  -- call the parent's p_first
: :        ...
: :     end p_first;

: This is the trap I fell into the first time I tried to write this code.
: The above solution doesn't work because the type conversion super(param)
: converts param into a pointer to the parent type, but tag inside the
: object that is pointed to still says the object is a child_obj, not a 
: parent_obj, so the call dispatches to the wrong place.  

No, the call as written does not dispatch at all, because the
actual parameter is of an access-to-specific, rather than an
access-to-class-wide type.  The above call is a statically bound
call to the p_first of the parent type.

*However* the above call does involve a conversion to a library-level
named access type, "super", which results in a run-time accessibility
check.  The check will succeed unless the original caller passed
in a pointer to a local aliased/heap object.

The call which avoids the accessibility check, and accomplishes the
statically bound call on the parent's operation, is:

    p_first(parent(param.all)'access);

: ... This line

: :        p_first(super(param));  -- call the parent's p_first

: in fact doesn't call the parent's p_first, in spite of the comment.  If
: the object pointed to by "param" is a child_obj this call is an infinite
: resursion.

No, that's not right.  It does call the parent's p_first, but it
also performs an accessibility check, which may not be desired.

: - Mitch Gart

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

Re: Invoking parental methods (was: Java vs Ada 95)

[Larry Kilgallen]

In article <E0EIM2.A3p.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) writes:

> The call which avoids the accessibility check, and accomplishes the
> statically bound call on the parent's operation, is:
> 
>     p_first(parent(param.all)'access);

So what is the recommended method of expressing that in such a fashion
as to have a single instance of the name "parent" in a package body
supporting multiple calls of the type under discussion?

My problem, again, is maintainability in the face of genealogy shifts.
Since Ada 95 does not have a mechanism to do it with zero changes
to the body in the fashion of Macintosh Object Pascal, I am hoping
for 1.

Larry Kilgallen

Fast locking (Was Re: Java vs Ada 95)

[Geert Bosch]

In article <dewar.847053681@merv> Robert Dewar writes:
   Geert said
   
   "In the more general case a very simple spin-lock is enough and the
    overhead should only be one memory-read when the object is not locked.
    String objects are locked almost never and when they are locked they
    are only locked for a short time."

   What do you mean by a very simple spin lock in a uniprocessor environment.

I meant a lock that uses some form of busy-waiting instead of
blocking. Such a lock can be implemented using atomic test-and-set 
or atomic swap. Although these locks are not efficient for long
waits because of wasted CPU time and possible starving of other
tasks, for resources that are only locked for a short time, like
the ref-counted bounded string example, they are the best solution.

When implementing a sample package for spin locks I found that GNAT
doesn't provide intrinsic subprograms as described in Annex C of the
RM:  "It is recommended that intrinsic subprograms be provided for
convenient access to any machine operations that provide special
capabilities or efficiency that are not otherwise available through the
language constructs." (RM95 C.1(11))

This means that test-and-set is not possible using just GNAT at the
moment and indeed implementing efficient spin-locks is not possible.
Hopefully the extra intrinsic subprograms will be implemented
sometime.

Regards,
   Geert


-- 
E-Mail: geert@sun3.iaf.nl    

Re: Invoking parental methods (was: Java vs Ada 95)

[Mitch Gart]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:

: But the dangling reference seems to be precipitated by the
: the pointer object, not by the the pointer type.
: What is wrong with:

:     type super is access all parent_obj; -- this line may get changed

:     procedure p_first(param: access child_obj) is
:     begin
:        ...
:        p_first(super(param));  -- call the parent's p_first
:        ...
:     end p_first;

This is the trap I fell into the first time I tried to write this code.
The above solution doesn't work because the type conversion super(param)
converts param into a pointer to the parent type, but tag inside the
object that is pointed to still says the object is a child_obj, not a 
parent_obj, so the call dispatches to the wrong place.  This line

:        p_first(super(param));  -- call the parent's p_first

in fact doesn't call the parent's p_first, in spite of the comment.  If
the object pointed to by "param" is a child_obj this call is an infinite
resursion.

- Mitch Gart

Re: Fast locking (Was Re: Java vs Ada 95)

[Larry Kilgallen]

In article <55o4g4$ki8@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

> This means that test-and-set is not possible using just GNAT at the
> moment and indeed implementing efficient spin-locks is not possible.
> Hopefully the extra intrinsic subprograms will be implemented
> sometime.

Descriptions of the GNAT developer environment posted here have
emphasized uniformity across platforms indicating that many of
those depending on it required that uniformity.

My presumption is that those folks have portable Ada code in mind.
The machine semantics of test-and-set on whatever machine you are
describing would seem to be somewhat different from the Alpha AXP
load-locked/store-conditional semantics.  A higher level construct
which supports portable programs seems better to me than something
specific to test-and-set hardware semantics.

(When I wrote about spin locks earlier in this thread, I thought we
were discussing techniques for compiler writers to use rather than
something exposed to Ada programmers.)

Larry Kilgallen

Re: Invoking parental methods (was: Java vs Ada 95)

[Mitch Gart]

Tucker is right.  But here's a slightly different example, which
shows the problem where a type conversion of an access type doesn't
do what might be expected.  The difference is that super is a
classwide access type.

    with ada.text_io; use ada.text_io;
     
    procedure supertest is
	package p1 is
	    type parent_obj is tagged null record;
	    type super is access all parent_obj'class;
	    procedure p_first (param: access parent_obj);
	end p1;
	package body p1 is
	    procedure p_first (param: access parent_obj) is
	    begin
		put_line("parent p_first");
	    end;
	end p1;
     
	package p2 is
	    type child_obj is new p1.parent_obj with null record;
	    procedure p_first (param: access child_obj);
	end p2;
	package body p2 is
	    procedure p_first (param: access child_obj) is
	    begin
		put_line("child p_first");
		p1.p_first(p1.super(param));	-- ***
	    end; 
	end p2;
     
	child: aliased p2.child_obj;
    begin
	p2.p_first(child'access);
    end;

The line marked *** dispatches back to p2.p_first, causing an
infinite recursion.  To get this one to do what's wanted, the
notation

    p1.p_first(p1.parent_obj(param.all)'access);

is needed.

- Mitch

Re: Fast locking (Was Re: Java vs Ada 95)

[Hannes Haug]

geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

> I meant a lock that uses some form of busy-waiting instead of
> blocking. Such a lock can be implemented using atomic test-and-set 
> or atomic swap. Although these locks are not efficient for long
> waits because of wasted CPU time and possible starving of other
> tasks, for resources that are only locked for a short time, like
> the ref-counted bounded string example, they are the best solution.

You can yield the task if the mutex is already locked.
Untested pseudo gnu c for sparc:

typedef struct mutex {
  volatile int lock;
} mutex_t;

static void
mutex_init (mutex_t *mp)
{
  mp->lock = 0;
}

static void
mutex_unlock (mutex_t *mp)
{
  mp->lock = 0;
}

static int
mutex_trylock (mutex_t *mp)
{
  int old_lock;
  asm volatile ("ldstub [%1],%0" : "=r" (old_lock) : "r" (&mp->lock));
  return old_lock;
}

static void
mutex_lock (mutex_t *mp)
{
  while (mutex_trylock (mp) != 0)
    thread_yield ();
}


typedef struct semaphore {
  mutex_t mutex;
  volatile int count;
} semaphore_t;

static void
semaphore_init (semaphore_t *sp, int count)
{
  mutex_init (&sp->mutex);
  sp->count = count;
}

static void
semaphore_post (semaphore_t *sp)
{
  mutex_lock (&sp->mutex);
  sp->count = sp->count + 1;
  mutex_unlock (&sp->mutex);
}

static int
semaphore_trywait (semaphore_t *sp) /* this is NOT the ordinary trywait */
{
  int old_count;
  mutex_lock (&sp->mutex);
  old_count = sp->count;
  if (old_count > 0)
    sp->count = old_count - 1;
  mutex_unlock (&sp->mutex);
  return old_count;
}

static void
semaphore_wait (semaphore_t *sp)
{
  while (semaphore_trywait (sp) == 0)
    thread_yield ();
}


This should be pretty fast. Even semaphore_wait
is small enough for automatic inlining.

 -hannes

Re: Fast locking (Was Re: Java vs Ada 95)

[Hannes Haug]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> My presumption is that those folks have portable Ada code in mind.
> The machine semantics of test-and-set on whatever machine you are
> describing would seem to be somewhat different from the Alpha AXP
> load-locked/store-conditional semantics.  A higher level construct
> which supports portable programs seems better to me than something
> specific to test-and-set hardware semantics.

Something like an inlined mutex_trylock?
This is something like test-and-set-lock.

> (When I wrote about spin locks earlier in this thread, I thought we
> were discussing techniques for compiler writers to use rather than
> something exposed to Ada programmers.)

The compiler writers should use fast locks and unlocks,
too. I think the os-mutexes are not fast enough.

 -hannes

Re: Invoking parental methods (was: Java vs Ada 95)

[Robert A Duff]

In article <1996Nov5.112527.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>My problem, again, is maintainability in the face of genealogy shifts.
>Since Ada 95 does not have a mechanism to do it with zero changes
>to the body in the fashion of Macintosh Object Pascal, I am hoping
>for 1.

Use a convention where you always write:

    subtype Parent is Whatever;
    type New_Type is new Parent ...;

Always use the name Parent in your type conversions (as in
"Parent(Param.all)'Access").  Then you can change the parent by changing
one line to "subtype Parent is Something_Else;".  No changes to the body
are needed.

- Bob

Re: Invoking parental methods (was: Java vs Ada 95)

[Larry Kilgallen]

In article <E0GI86.BH6@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1996Nov5.112527.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>My problem, again, is maintainability in the face of genealogy shifts.
>>Since Ada 95 does not have a mechanism to do it with zero changes
>>to the body in the fashion of Macintosh Object Pascal, I am hoping
>>for 1.
> 
> Use a convention where you always write:
> 
>     subtype Parent is Whatever;
>     type New_Type is new Parent ...;
> 
> Always use the name Parent in your type conversions (as in
> "Parent(Param.all)'Access").  Then you can change the parent by changing
> one line to "subtype Parent is Something_Else;".  No changes to the body
> are needed.

Thanks!

I had not even dared hope to be able to do it in the specification !

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert I. Eachus]

In article <1996Nov5.083552.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

  > I think the issue may be one of terminology clash.  What Ada folk
  > call a synchronization point may very well be implemented in what
  > OS folk call a spinlock.  I responded to what struck me as an
  > OS-style discussion (I did not introduce the term spinlock to
  > the thread) using OS-speak.  Perhaps we should be talking
  > about the overhead of a "synchronization point", but the
  > original claim was that it can be cheap where there is no
  > contention, so if nobody disagrees we can forget the term
  > "spinlock" was ever mentioned :-)

     No, actually a synchronization point in Ada-speak is where two
tasks interact and therefore the user can make some assumptions about
the order in which things happen.  The actual synchronization point
can be a task creation, termination, abort, rendezvous, etc., which
will be implemented in part using OS primitives.

    But my real point was that from the user's point of view an
Ada-defined synchronization point for a task can't happen in the
middle of a call to a string routine, and this has the effect (from a
legality point of view) of making the string operations atomic with
respect to tasking.  If you do something which the RM defines as
erroneous, you shouldn't be surprised to see erroneous behavior. (see
RM9X 9.10) Of course it would be nice for an implementation to do nice
things in such a case, but certainly losing track of garbage is not a
horrendous effect, especially since the way to avoid the erroneous
behavior is so simple.  (Do you really want two tasks asynchronously
doing reads and writes of the same string object?)


  
--

					Robert I. Eachus

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

Re: Fast locking (Was Re: Java vs Ada 95)

[Robert Dewar]

"> This means that test-and-set is not possible using just GNAT at the
> moment and indeed implementing efficient spin-locks is not possible.
> Hopefully the extra intrinsic subprograms will be implemented
> sometime."

GNAT fully supports machine intrinsics, starting with version 3.07.

Re: Invoking parental methods (was: Java vs Ada 95)

[Robert I. Eachus]

In article <1996Nov5.112527.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

  > My problem, again, is maintainability in the face of genealogy shifts.
  > Since Ada 95 does not have a mechanism to do it with zero changes
  > to the body in the fashion of Macintosh Object Pascal, I am hoping
  > for 1.

   I really feel that a 'SUPER attribute would make the language more
useable, and maybe implementors will start providing it.  However,
until they do, we are stuck with the best solution being:

   For classes where you expect to need super, define:

   function Super(X: in Child) return Parent'Class;

   as a predefined operation.  Now (with my hand never leaving my
wrist), I can write Foobar(Super(Foob)); where it is not ambiguous,
and Foobar(Bar'(Super(Foob))); if I have to disambiguate.  The problem
is I'd like to find an efficient way to define the Super function so
that there are no accessability checks or the like and and you don't
have to override it all the time.  Any suggestions?  (Writing it the
other way round: function Super(X: in Child'Class) return Parent; has
the "advantage" that the override is forced, but the disadvantage that
you are much more likely to need a qualified expression.)



--

					Robert I. Eachus

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

Re: Fast locking (Was Re: Java vs Ada 95)

[Geert Bosch]

Larry Kilgallen writes:
`` My presumption is that those folks have portable Ada code in mind.
   The machine semantics of test-and-set on whatever machine you are
   describing would seem to be somewhat different from the Alpha AXP
   load-locked/store-conditional semantics.  A higher level construct
   which supports portable programs seems better to me than something
   specific to test-and-set hardware semantics. ''

The Systems Programming Annex of the RM specifically advises atomic
read-modify-write operations like test and set, compare and swap etc.

I can't imagine there are many systems around these days that do not
provide efficient test-and-set semantics. Even the 8088 processor that
does not directly have a test-and-set instruction can easily emulate
one by doing an atomic swap between a processor register and a memory
location. On very simple processors it is almost always possible to
block all interrupts while doing the test-and-set.

Of course machines that do not have any instructions that can be used
to efficiently implement hardware-assisted locking will not have a
test-and-set intrinsic sub-program, but of course nobody expects to
magically be able to use hardware locking support when the target
platform does not have it. The point is that *when* it is available,
it should be usable in a consistent way.

Note that although test-and-set kind of mutual exclusion is a
very fast solution for locking resources for which is almost
never any contention, it certainly doesn't replace high-level
high-overhead locking provided by protected types.

The difference is that protected types provide strictly 
priority-based FIFO queuing which makes fair sharing of scarce
resources possible. It would be a good idea however to use
fast test-and-set locks in these as well.

The example below shows how to do this, when there is hardware
test-and-increment and decrement-and-test. Assumptions are
that the standard queuing is expensive (expensive system calls
involved) and non-queuing but blocking event semaphores are much
cheaper. I've verified that these assumptions hold on OS/2, but
I guess the situation is the same for other operating systems.

Implementing the solution below causes slightly more expensive
blocking/unblocking and essentially free locking/unlocking in absence
of contention for the lock. The semantics of the Fast_Queuing_Mutex
are exactly the same as for the Slow_Queuing_Mutex, although some
bookkeeping should be added to record the priority for the task
owning the fast-lock in case of Ceiling_Locking policy.

Example: (untested incomplete code, details might be wrong)

type Fast_Queuing_Mutex is record
   Slow_Lock	        : Slow_Queuing_Mutex; 
   Fast_Lock    	: Integer := 0;
   Fast_Lock_Ready      : Event_Semaphore := Not_Posted;
   Have_Slow_Lock	: Boolean := False;
end record;

procedure Request (L : in out Fast_Queuing_Mutex) is
   Was_Zero	: Boolean;
begin
   Test_And_Increment(L.Fast_Lock, Was_Zero);
   if Was_Zero then
      -- We have lock without any overhead
      return;
   else
      -- The fast lock already was in use.
      -- Now wait in the queue for the Mutex,
      -- (No wait if we're first)
      Request_Mutex(L.Slow_Lock);   
      -- We also have to wait for the fast lock
      -- This can be done using a non-priority based
      -- event semaphore
      Wait_Event(L.Fast_Lock_Ready);
      -- Can't set this before fast lock is released
      L.Have_Slow_Lock := True;
   end if;
end Request;

Article Unavailable

Re: Invoking parental methods (was: Java vs Ada 95)

[David Wheeler]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <1996Nov5.112527.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

:   > My problem, again, is maintainability in the face of genealogy shifts.
:   > Since Ada 95 does not have a mechanism to do it with zero changes
:   > to the body in the fashion of Macintosh Object Pascal, I am hoping
:   > for 1.

:    I really feel that a 'SUPER attribute would make the language more
: useable, and maybe implementors will start providing it.

I actually recommended such an attribute (I named it 'Parent) as part of
the Ada95 revision. My suggestion was struck down for the reason you see here
(you can emulate it with "subtype").  I still think it's a good idea,
even though there's a simple workaround, because it simplifies maintenance
and reduces possible errors (e.g. forgetting to redefine subtype Parent when
the hieararchy changes).


--- David A. Wheeler
    dwheeler@ida.org

Re: Fast locking (Was Re: Java vs Ada 95)

[Robert Dewar]

Geert says

"> I can't imagine there are many systems around these days that do not
> provide efficient test-and-set semantics. Even the 8088 processor that
> does not directly have a test-and-set instruction can easily emulate
> one by doing an atomic swap between a processor register and a memory
> location. On very simple processors it is almost always possible to
> block all interrupts while doing the test-and-set."

Your imagination is deficient. Examples are the RS6000 and all earlier
MIPS chips. There are others!

Re: Fast locking (Was Re: Java vs Ada 95)

[Larry Kilgallen]

In article <55r16k$m00@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

> I can't imagine there are many systems around these days that do not
> provide efficient test-and-set semantics. Even the 8088 processor that
> does not directly have a test-and-set instruction can easily emulate
> one by doing an atomic swap between a processor register and a memory
> location. On very simple processors it is almost always possible to
> block all interrupts while doing the test-and-set.

"Blocking all interrupts" in a multiprocessor environment would be
hazardous to the speed of other, non-interfering, activities.

> Of course machines that do not have any instructions that can be used
> to efficiently implement hardware-assisted locking will not have a
> test-and-set intrinsic sub-program, but of course nobody expects to
> magically be able to use hardware locking support when the target
> platform does not have it. The point is that *when* it is available,
> it should be usable in a consistent way.

My complaint is not that some machines lack fast locking primitives,
but rather that there was an assumption that those primitives will
always be "test and set".  DEC designers made the choice that their
"load-locked/store-conditional" semantics would be faster than more
traditional approaches.  Since they consistently win the SpecFP
and SpecInt comparisons with each new chip, I presume they know
what they are doing about fast hardware (although the portion of
their design having to do with locking primitives has nothing to
do with the portion of their design needed for the rather limited
SpecFP and SpecInt tests).

Larry Kilgallen

Re: Invoking parental methods (was: Java vs Ada 95)

[Jon S Anthony]

In article <E0GAKr.HB.0.-s@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch Gart) writes:

>     procedure supertest is
> 	package p1 is
> 	    type parent_obj is tagged null record;
> 	    type super is access all parent_obj'class;
> 	    procedure p_first (param: access parent_obj);
> 	end p1;
...[snip]...
> 	package p2 is
> 	    type child_obj is new p1.parent_obj with null record;
> 	    procedure p_first (param: access child_obj);
> 	end p2;
> 	package body p2 is
> 	    procedure p_first (param: access child_obj) is
> 	    begin
> 		put_line("child p_first");
> 		p1.p_first(p1.super(param));	-- ***
> 	    end; 
> 	end p2;

> The line marked *** dispatches back to p2.p_first, causing an
> infinite recursion.  To get this one to do what's wanted, the

I'm not sure why anyone would think otherwise.  I mean you haven't changed
anything about the thing referenced.  Would anyone be confused by:

    p : most_general_class_wide_access_type := new some_child_object
    q : most_general_class_wide_access_type := new some_other_child_object
...
    dispatchable_op(p); -- dispatch to some_child_object version
    dispatchable_op(q); -- dispatch to some_other_child_object version

??

If not, why would the above "super" example be confusing?

Also, I think someone else pointed out a while ago that using subtypes
(and maybe package renames) will make you immune to code "ripple effects"
if you change the parent:

    with p
    ...;
    package parents renames p;
    subtype parent is parents.t;
    type x is new parent;
...

Maybe news lost this...


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

Re: Fast locking (Was Re: Java vs Ada 95)

[Geert Bosch]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
   "Blocking all interrupts" in a multiprocessor environment would be
   hazardous to the speed of other, non-interfering, activities.

Please don't twist my words. I specifically said for that this
solution might be good for small/old systems. If you need an example,
think of microcontrollers.

I also wrote:
   "Of course machines that do not have any instructions that can be used
    to efficiently implement hardware-assisted locking will not have a
    test-and-set intrinsic sub-program"

How could you still think I was suggesting that "Blocking all interrupts"
in a multiprocessor environment was a good idea? A multiprocessor system
without test-and-set or similar mechanisms falls into the category:
   "[...] of course nobody expects to magically be able to use hardware
    locking support when the target platform does not have it. The
    point is that *when* it is available, it should be usable in a
    consistent way.

Larry wrote:
  "My complaint is not that some machines lack fast locking primitives,
   but rather that there was an assumption that those primitives will
   always be "test and set".  "

I never said that, although test-and-set is the most well-known
primitive in this area, so I used that. I even listed some of the
other possible primitives. In any case, the test-and-set operation
can easily be implemented with other fast-locking operations. 

And the point is not that these low-level locks should be used in
most applications, but that they can be very valuable tools in
cases where they are needed just like the other parts of Annex C
of the ARM.

Larry wrote:
  "DEC designers made the choice that their "load-locked/
   store-conditional" semantics would be faster than more traditional
   approaches."

If I use that instruction as load-locked/store-whenzero than I have the
equivalent of test-and-set, which is why it makes sense to provide a
very generic fast-locking primitive like test-and-set in Ada
implementations rather than using DECs instruction-of-the-day.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Invoking parental methods (was: Java vs Ada 95)

[Robert I. Eachus]

In article <55tm4r$8al@news.ida.org> wheeler@aphrodite (David Wheeler) writes:

  > I actually recommended such an attribute (I named it 'Parent) as
  > part of the Ada95 revision. My suggestion was struck down for the
  > reason you see here (you can emulate it with "subtype").  I still
  > think it's a good idea, even though there's a simple workaround,
  > because it simplifies maintenance and reduces possible errors
  > (e.g. forgetting to redefine subtype Parent when the hieararchy
  > changes).

   Once upon a time in Ada 9X you could emulate it fairly easily, if
you knew the name of the parent.  But with the current (and very
correct) rules on dispatching, it can be VERY difficult to get the
effect you want.  (A view conversion to the parent type that
dispatches dynamically or statically depending on context.)  I argued
for the attribute at more than one WG9 workshop, and got regularly put
aside with "it is easy" to emulate.  Now we have the rules for
dispatching right but it can be very hard to get the dynamic behavior
to work.

    I guess most people thought about the static case, and didn't
realize that there are cases where you want the dynamic behavior.  For
example, suppose I want to find out how deep an inheritance is.

    I want to write:

       function Count_Depth(Bar: in Foo'CLASS) return Integer is
       begin
         if Foo'Tag = Bar'Tag then return 0;
         else return Count_Depth(Parent(Bar)) + 1; end if;
       end Count_Depth;

    This is a semi-silly example, but think about a typical window
system where I want to add gadgets by inheritance.  Most of the time,
the behavior of the child statically calling the parent's method is
fine, but often you want to walk the inheritance list, doing something
at each level.  You either define all these methods on the root class,
which requires an impossible amount of forethough since you didn't
write that package, or you make them classwide, and need the dynamic
behavior.

--

					Robert I. Eachus

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

Re: Invoking parental methods (was: Java vs Ada 95)

[Joel VanLaven]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
: In article <E0ED6w.24D.0.-s@inmet.camb.inmet.com>, mg@harp.camb.inmet.com (Mitch Gart) writes:
: > Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
: > 
: > : But the dangling reference seems to be precipitated by the
: > : the pointer object, not by the the pointer type.
: > : What is wrong with:
: > 
: > :     type super is access all parent_obj; -- this line may get changed
: > 
: > :     procedure p_first(param: access child_obj) is
: > :     begin
: > :        ...
: > :        p_first(super(param));  -- call the parent's p_first
: > :        ...
: > :     end p_first;
: > 
: > This is the trap I fell into the first time I tried to write this code.
: > The above solution doesn't work because the type conversion super(param)
: > converts param into a pointer to the parent type, but tag inside the
: > object that is pointed to still says the object is a child_obj, not a 
: > parent_obj, so the call dispatches to the wrong place.  This line
: > 
: > :        p_first(super(param));  -- call the parent's p_first
: > 
: > in fact doesn't call the parent's p_first, in spite of the comment.  If
: > the object pointed to by "param" is a child_obj this call is an infinite
: > resursion.

I didn't see the original post, but from what I undeerstand of Ada95, this
ought to behave as you seemed to originally intend.  The way I understand it
is if you don't use 'class anywhere (including in the declaration of super)
then no dispatching takes place.  If it is taking place then I would bet on
a compiler bug.  If you could provide a test case that demonstrates the
problem you are having (preferably in e-mail as I missed the original post)
I would love to test it out on our compiler.  Remember, if you can make 
mistakes (especially interpreting RM rules) then compiler vendors sure can
too.
-- 
-- Joel VanLaven

Re: Fast locking (Was Re: Java vs Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:
> 
> Geert says
> 
> "> I can't imagine there are many systems around these days that do not
> > provide efficient test-and-set semantics. 
...
> 
> Your imagination is deficient. Examples are the RS6000 and all earlier
> MIPS chips. There are others!

The RS6000 is not a processor, but a family of systems, early versions
of which were based on the POWER architecture and later versions of
which were based on the PowerPC architecture.  Robert is presumably
referring to the POWER architecture, which did not include
syncrhonization operations for shared-memory multiprocessors.  In
contrast, the PowerPC architecture provides the lwarx (load word
arithmetic and reserve, indexed) and stwcx (store word conditional,
indexed) instructions, which provide powerful and efficient
syncrhonization.  Every PowerPC architecture document I have seen
includes an appendix with syncrhonization programming examples, showing
how a handful of instructions, generally built around a lwarx/stwcx
pair, can be used to program such syncrhonization idioms as
Fetch-and-Store, Fetch-and-Add, Test-and-Set, Compare-and-Swap, and
lock/unlock.

(My favorite PowerPC syncrhonization instruction, used to ensure that
out-of-order loads and stores do not violate the semantics of volatile
variables and memory-mapped I/O ports, is Enforce In-Order Execution of
I/O.  Its mnemonic is, naturally, eieio.)

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Robert Eachus says

"   It is the case that if you want to have a program which has
multiple tasks which reference the same bounded string, and one of
them does an update, then you have to have a synchronization point
before the next reference.

   Now as long as there are no synchronization points in the string
ops, you don't have a problem.  You can even allow for the case where
an allocation or free can be an external synchronization point.  The
only problem is transitive updates:"


At first I thought this must be wrong, but as I think about it, I think
it is the complete answer to the concern about reference counts, but it
is hardly a satisfactory answer. If you are using reference counts for
unbounded strings, then it is indeed the case that the code manipulating
these refrence counts is highly likely to be erroneous (wrt the reference
counts as shared variables), if there is any sharing of string values
between tasks.

So I think one must conclude that such sharing is not required to work.

Perhaps an example is worthwhile

Suppose we have two variables V1 and V2

We write V1 := V2 (these are unbounded strings by the way)

then we spawn two tasks, T1, T2, then in T1 we assign a completely
new value to V1 and in T2 we assign a completely new value to V2.

Well this program execution may be erroneous, which is at least to 
me a bit of a surprise.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Geert Bosch]

Robert Dewar wrote:
  "If you are using reference counts for unbounded strings, then it is
   indeed the case that the code manipulating these refrence counts is
   highly likely to be erroneous (wrt the reference counts as shared
   variables), if there is any sharing of string values between tasks."

   [example deleted]

  "Well this program execution may be erroneous, which is at least to
   me a bit of a surprise."

It is a suprise, because the user of the Unbounded_String package
would not expect that the package body contains code that may lead to
erroneous execution. 

A correct and efficient implementation of the Unbounded_String package
is easy if the system provides Test_And_Increment and
Decrement_And_Test, where the Test tests wether the value is zero.
Both of these primitives can be implemented easily using Test_And_Set.
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Robert Duff says

"I don't see this.  To prove that something is erroneous, you have to
reason from the RM, not from a (possibly incorrect) implementation.  You
can't say, "I choose to implement unbounded strings using erroneous
updates of reference counts (i.e. without locking the counts).
Therefore so-and-so uses of unbounded strings are erroneous."  It seems
to me that the conclusion must be "Therefore this is not a correct
implementation."

I can see that you would *wish* this to be the case, but please prove
it from the RM. Where is the abstract semantics of unbounded strings
specified in such a way as to make my reference count implementation
incorrect? I don't see any language around the unbounded strings
package that explicitly says this (or for that matter, even implies it).

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <dewar.848026322@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Suppose we have two variables V1 and V2
>
>We write V1 := V2 (these are unbounded strings by the way)
>
>then we spawn two tasks, T1, T2, then in T1 we assign a completely
>new value to V1 and in T2 we assign a completely new value to V2.
>
>Well this program execution may be erroneous, which is at least to 
>me a bit of a surprise.

I don't see this.  To prove that something is erroneous, you have to
reason from the RM, not from a (possibly incorrect) implementation.  You
can't say, "I choose to implement unbounded strings using erroneous
updates of reference counts (i.e. without locking the counts).
Therefore so-and-so uses of unbounded strings are erroneous."  It seems
to me that the conclusion must be "Therefore this is not a correct
implementation."

- Bob

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Geert says

"It is a suprise, because the user of the Unbounded_String package
would not expect that the package body contains code that may lead to
erroneous execution.

A correct and efficient implementation of the Unbounded_String package
is easy if the system provides Test_And_Increment and
Decrement_And_Test, where the Test tests wether the value is zero.
Both of these primitives can be implemented easily using Test_And_Set."

Robert replies

You cannot assume anything about the bodies of standard units that is
not specified in the reference manual. The question here focuses on
whether RM A.3 applies to implicit calls to finalize, and what exactly
"perform as specified" means for these implicit calls, given that no
specification for finalize is given.

I think it is a real reach to say that RM A.3 forbids the reference count
approach, but it is certainaly discussable.

Note that Geert's claim about test and set is wrong, or at least wrong if
you claim to implemnt Annex D. Simple minded use of test and set can
lead to priority inversions of a type forbidden by Annex D, so I would
say that using test and set in the body of unbounded strings in an
implementation that claims to support annex D is a much clearer violation
of the RM, which has nothing to do with erroneous execution. It just has
to do with choosing an impermissible implementation strategy (test and
set) that does not conform to Ada semantics.

By the way, here is A.e for easy reference:

                         Implementation Requirements

3   The implementation shall ensure that each language defined subprogram is
reentrant in the sense that concurrent calls on the same subprogram perform
as specified, so long as all parameters that could be passed by reference
denote nonoverlapping objects.

oops, thats A.3 not A.e

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <dewar.848239512@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>You cannot assume anything about the bodies of standard units that is
>not specified in the reference manual. The question here focuses on
>whether RM A.3 applies to implicit calls to finalize, and what exactly
            ^^^
That's A(3), i.e. paragraph 3 of section A, not section A.3.

>"perform as specified" means for these implicit calls, given that no
>specification for finalize is given.

Type Unbounded_String (a private type) has no Finalize operation.  If
the implementation puts one in the private part, then it had better not
do anything that violates the semantics.  And the semantics of
Unbounded_Strings *are* specified pretty clearly (at least as clearly as
you can get when writing in English, as opposed to some formal
notation).  And those semantics do not call for any erroneousness.

>                         Implementation Requirements
>
>3   The implementation shall ensure that each language defined subprogram is
>reentrant in the sense that concurrent calls on the same subprogram perform
>as specified, so long as all parameters that could be passed by reference
>denote nonoverlapping objects.
>
>oops, thats A.3 not A.e

Oops, that's A(3).

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <dewar.848202876@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I can see that you would *wish* this to be the case, but please prove
>it from the RM. Where is the abstract semantics of unbounded strings
>specified in such a way as to make my reference count implementation
>incorrect? I don't see any language around the unbounded strings
>package that explicitly says this (or for that matter, even implies it).

I'd say A.4.5(1) proves it -- these things "represent strings", not
strange pointers into evilly shared variables.  If you want to use
strange pointers in the implementation, then you have to make it behave
as if they are really (varying length) strings.

I don't see any statement in the RM that says these things are erroneous
-- therefore they aren't.  (You *have* to read the RM that way --
otherwise *everything* is erroneous, because we rarely say "so-and-so is
not erroneous".)

By your reasoning, it is erroneous to use every type in every predefined
package, because who knows what's in the package body -- maybe the body
of Text_IO writes zeroes over the whole address space (since the RM
doesn't explicitly forbid that)!

It seems to me that the burden of proof should be on you -- you claim
that so-and-so is erroneous, so to prove it, you have to point to an
explicit statement in the RM saying it's erroneous.  You can't just
point out that it doesn't say it's not erroneous.  Otherwise, I'll say,
"Prove that 'X := 1;' is not erroneous.", and the whole language falls
apart.

- Bob

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Norman H. Cohen]

Robert Dewar wrote:

> You cannot assume anything about the bodies of standard units that is
> not specified in the reference manual. The question here focuses on
> whether RM A.3 applies to implicit calls to finalize, and what exactly
> "perform as specified" means for these implicit calls, given that no
> specification for finalize is given.
> 
> I think it is a real reach to say that RM A.3 forbids the reference count
> approach, but it is certainaly discussable.
...
> By the way, here is A.e for easy reference:
> 
>                          Implementation Requirements
> 
> 3   The implementation shall ensure that each language defined subprogram is
> reentrant in the sense that concurrent calls on the same subprogram perform
> as specified, so long as all parameters that could be passed by reference
> denote nonoverlapping objects.
> 
> oops, thats A.3 not A.e

Robert means A(3), i.e., the third paragraph of RM Annex A, not A.3 (the
third subsection of Annex A).  

I agree with Bob Duff that an implementation of Unbounded_String is
incorrect if it can trigger implicit calls on Finalize that cause
execution to become erroneous.  I agree with Robert Dewar that this
can't be inferred from a literal reading of A(3), but I think it is the
clear intent of A(3) that the overall behavior of a type in a predefined
package--not just the behavior of its subprograms--should be task-safe. 
The wording of A(3) needs to be strengthened.

(The intent can be inferred, for example, from paragraph A(3.c) of the
Annotated Ada Reference Manual.  The AARM is not a part of the standard,
but is an indication of what the authors of the standard were thinking. 
This paragraph says:

   Ramification:  The rule implies that any data local to the 
   private part or body of the package has to be somehow protected
   against simultaneous access.

This isn't exactly the case of a reference count, which resides in
individual objects of the data type provided by the package rather than
in variables declared inside the private part or body of the package,
but similar issues apply.  In particular, the AARM asserts that
protection against simultaneous access is necessary regardless of
whether this access arises directly from an invocation of one of the
package's explicit subprograms.)

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

+-----------------------------------------------------------------------+
| Message found at the bottom of my Netscape window:                   
|
|                                                                      
|
|   Connect: Host godot.watson.ibm.com contacted.  Waiting for reply...
|
+-----------------------------------------------------------------------+

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Bob Duff says

"I'd say A.4.5(1) proves it -- these things "represent strings", not
strange pointers into evilly shared variables.  If you want to use
strange pointers in the implementation, then you have to make it behave
as if they are really (varying length) strings.

I don't see any statement in the RM that says these things are erroneous
-- therefore they aren't.  (You *have* to read the RM that way --
otherwise *everything* is erroneous, because we rarely say "so-and-so is
not erroneous".)"


Nope, I don't buy that for a moment. By that reasoning, A.3

3   The implementation shall ensure that each language defined subprogram is
reentrant in the sense that concurrent calls on the same subprogram perform
as specified, so long as all parameters that could be passed by reference
denote nonoverlapping objects.


would be entirely redundant, since according to you, it is implicit in the
specs of the routines.

In fact it is perfectly possible to do things with the defined procedures
that definitely ARE erroneous, for example, surely you dont think that
two tasks that modify the same string at the same time must work
correctly. No of course not, that we would expect to be erroneousw.
"behave as if they are really (varying length) strings"

is meaningless, either we ignore the parenthetical remark, in which case
it is nonsense, since these do not behave like Ada strings, or we include
it, in which case we are talking about something not in the language and
so are defining varying length string semantics in terms of varying
length string semantics which is nonsense.
\x1adp

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

Bob Duff says

"Type Unbounded_String (a private type) has no Finalize operation.  If
the implementation puts one in the private part, then it had better not
do anything that violates the semantics.  And the semantics of
Unbounded_Strings *are* specified pretty clearly (at least as clearly as
you can get when writing in English, as opposed to some formal
notation).  And those semantics do not call for any erroneousness."


Where does it specify "pretty clearly" the semantics of assigning
unbounded strings. Maybe I have a defcetive copy of the RM, the word
assign only occurs in 88:

88   No storage associated with an Unbounded_String object shall be lost upon
assignment or scope exit.

this of course is a nonsense requirement since the formal notion of 
losing storage is not defined, but informally we get the idea.

So, what is the semantics of assignment of unbounded strings? Presumably
the same as normal assignment for other types, but that can have all
sorts of different semantics depending on the full type, and we are not
supposed to do anything that relies on this. For example, if the full
type is a controlled type, then the RM specifies various things about
the way assignment works.

Basically the rule for the semantics of assignment of a private type is
that it is goverened by the semantics of assignment to the underlying
full type.

So, the long and the short of it is that when you assign a private type,
you don't know exactly what the semantics are.

This is a similar situation to the stream attributes on unbounded_string.
The RM leaves them completely undefined. A recent AI (apporved yet> I
can't remember ....) specifies that they "work" properly, but we did not
discuss assignment at the same time, maybe we should!

I am sure that I can't read Bob Duff's semantics into the RM without
a healthy dose of interpretation.

Such interpretation is usually guided by what you want, but I am not so
sure I agree that I want a huge overhead of locking and unlocking just
so that unbounded strings shared between tasks "work" right.

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
   Robert replies to my earlier remark:

   You cannot assume anything about the bodies of standard units that is
   not specified in the reference manual. The question here focuses on
   whether RM A.3 applies to implicit calls to finalize, and what exactly
   "perform as specified" means for these implicit calls, given that no
   specification for finalize is given.

I think it is a real reach to say that an Ada implementation is allowed
to provide an Unbounded_Strings package body which execution can be
erroneous in tasking programs.

   I think it is a real reach to say that RM A.3 forbids the reference count
   approach, but it is certainaly discussable.

Of course the RM doesn't forbid refcounting! It just has to be implemented
properly, ie task-safe. It is possible to write a safe and correct 
reference counted implementation of bounded strings that satisfies
these criterea. Of course you need a low-overhead locking primitive 
as I said, or even better, you would just use an Ada compiler with a
fast implementation of simple protected types (using test-and-set or a
similair primitive instead of OS calls).

   Note that Geert's claim about test and set is wrong, or at least wrong if
   you claim to implemnt Annex D. Simple minded use of test and set can
   lead to priority inversions of a type forbidden by Annex D,

Simple minded use of any locking scheme can lead to problems, but
that is not an excuse to use no locking at all for a reference-counting
Bounded_String implementation. 

A possible scheme for safe reference counting using test-and-set
as locking mechanism is given below, but it is not tested or whatsoever.

   type Safe_Fast_Lock is array (System.Priority'Range) of Boolean;
   pragma Pack (Safe_Fast_Lock);
   pragma Volatile_Components (Safe_Fast_Lock);

   Locking_Error : exception;

   procedure Get
     (The_Lock     : in out Safe_Fast_Lock;
      The_Priority : in Priority) is
   begin
      while Test_And_Set (The_Lock (The_Priority)) loop
	 delay 0.0;
      end loop;
      for P in reverse Priority.First .. The_Priority - 1 loop
	 if Test_And_Set (The_Lock (P)) then
	    -- Task with lower priority already has the lock and may
	    -- be starved. A more advanced scheme might be used here.
	    for Q in P + 1 .. The_Priority loop
	       The_Lock (P) := False;
            end loop;
	    raise Locking_Error;
         end if;
      end loop;
   end Get;

   procedure Release
     (The_Lock     : in out Safe_Fast_Lock;
      The_Priority : in Priority) is
   begin
      for P in Priority'First .. The_Priority loop
	 The_Lock (P) := False;
      end loop;
   end Release;
      
   type Referenced_Data is record
      Lock     : Safe_Fast_Lock := (others => False);
      Count    : Natural := 0;
      Data     : ...;
   end record;

   procedure Add_Reference (Reference : in out Referenced_Data) is
      My_Priority : Get_Priority;
   begin
      Get (Reference.Lock, My_Priority);
      Reference.Count := Reference.Count + 1;
      Release (Reference.Lock (My_Priority));
   end Add_Reference;

   procedure Remove_Reference (Reference : in out Referenced_Data) is
      My_Priority   : Get_Priority;
      No_References : Boolean;
   begin
      Get (Reference.Lock, My_Priority);
      Reference.Count := Reference.Count - 1;
      No_References := (Reference.Count = 0);
      Release (Reference.Lock, My_Priority);
      if No_References then
	 ... -- Deallocate the data
      end if;
   end Remove_Reference;
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert A Duff]

In article <dewar.848352338@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Such interpretation is usually guided by what you want, but I am not so
>sure I agree that I want a huge overhead of locking and unlocking just
>so that unbounded strings shared between tasks "work" right.

So implement a full garbage collector, and your problem is solved.  ;-)

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <dewar.848352010@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Nope, I don't buy that for a moment. By that reasoning, A.3

A(3).

>3   The implementation shall ensure that each language defined subprogram is
>reentrant in the sense that concurrent calls on the same subprogram perform
>as specified, so long as all parameters that could be passed by reference
>denote nonoverlapping objects.
>
>
>would be entirely redundant, since according to you, it is implicit in the
>specs of the routines.

Actually, I think it *is* redundant, and I had a big argument about that
with Tucker.  (I think it should have been a NOTE or an
[bracketed-in-AARM] thing.)  The reason it's there is that some Ada 83
compilers failed to make things like Text_IO work properly.  And because
Tucker wanted it there.

This is like many real-life laws -- legislatures are continually passing
laws that are just special cases of existing laws, because somebody is
griping about a rash of some particular crime.  Legislatures don't
normally sit around thinking of every possible evil, and pass a law
against it.  RM authors, on the other hand, try to do something like
that.  ;-)

>In fact it is perfectly possible to do things with the defined procedures
>that definitely ARE erroneous, for example, surely you dont think that
>two tasks that modify the same string at the same time must work
>correctly. No of course not, that we would expect to be erroneousw.

Agreed.

>"behave as if they are really (varying length) strings"
>is meaningless, either we ignore the parenthetical remark, in which case
>it is nonsense, since these do not behave like Ada strings, or we include
>it, in which case we are talking about something not in the language and
>so are defining varying length string semantics in terms of varying
>length string semantics which is nonsense.

Whenever the RM uses a term that it doesn't define, which is quite
often, you have to take the most reasonable meaning you know from plain
English, or from general computer jargon.  Perhaps I interpret this
section using a "friendly reading".  I'm not going to worry about it
until some compiler vendor tries to get away with making things
erroneous that shouldn't be.

And you still haven't answered my main objection to your reading -- if
you read it that way, then why isn't practically everything in Annex A
erroneous?  And lots of other stuff.  E.g:

    X, Y: Calendar.Time := Clock;
    
    X := Y; -- Erroneous?

(No tasks here.)  How do we know that the implementer has not evilly
made the full type for Time controlled, with an Adjust routine that does
something erroneous?  Or raises GNAT.Evil_Exceptions.Whatever_Error?  Or
writes the value 17 into all integer variables in the program?  We know
that, because the correct way to interpret the RM is that if it doesn't
say any of those bad things happen, then they don't.  The same way we
know that 1+1 of Integers doesn't have side effects.

(Of course I know that two tasks modifying X at the same time would be
erroneous.  That's covered by 9.10.)

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Joel VanLaven]

This discussion is related to Unbounded strings and someone's suggestion to
use a reference-count finalization scheme and the possible problems with
that with respect to tasking.  The problem is that multiple tasks could
all try to access the reference count at the same time, one decrementing
and one incrementing for instance, right?  So, to prevent that, some sort
of locking would have to occur.  However, we are talking about simply
incrementing and/or decrementing 1 value in memory.  On most processors
that I can think of that is 3 operations, two memory accesses and an
integer operation.  Is the Ada tasking/priority method so accurate that
that one lower priority task can't tie up the machine for 2 extra
instructions?  I think it ought to be able to handle even more than that.
What about making an increment/decrement function that is a task or protected
object at the very highest priotity level (higher than the highest as this
is the compiler writer ... :) So essentially all reference counts are on the
same lock.  When a task wanted to adjust a reference count it would call /
rendevous with the increment/decrementer which would take over and
deal with the requested reference count.  As long as that doesn't take
too long and the call overhead isn't too large, no ones toes will be
stepped on.
  On the issue of the RM and the implementation's responsibility I bring up
the point that there are always trade-offs.  Some users may not want to use
tasking at all and want the fastest code possible.  Some might want
tasking and can handle less performance.  The real responsibility of the
implementation is to be explicit about what trade-offs were made.  A
suggestion is to provide multiple alternitives when feasible.  Portability
concerns suggest that implementations chose similar trade-offs, but I will
leave that can of worms for another discussion.
-- 
-- Joel VanLaven

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Jon S Anthony]

In article <E14DCH.5EK@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <dewar.848352010@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >"behave as if they are really (varying length) strings"
> >is meaningless, either we ignore the parenthetical remark, in which case
> >it is nonsense, since these do not behave like Ada strings, or we include
> >it, in which case we are talking about something not in the language and
> >so are defining varying length string semantics in terms of varying
> >length string semantics which is nonsense.
> 
> Whenever the RM uses a term that it doesn't define, which is quite
> often, you have to take the most reasonable meaning you know from plain
> English, or from general computer jargon.  Perhaps I interpret this

Criminey!  You better watch out Bob, you're beginning to sound just
like me in this sort of context! ;^)

There are indeed many of these and the worst of it is, they don't seem
all that "fundamental" or "primitive" or "intuitive" like "reasonable"
undefined terms.  As you say - you have to guess the best you can...


> And you still haven't answered my main objection to your reading -- if
> you read it that way, then why isn't practically everything in Annex A
> erroneous?  And lots of other stuff.  E.g:
> 
>     X, Y: Calendar.Time := Clock;
>     
>     X := Y; -- Erroneous?
> 
> (No tasks here.)  How do we know that the implementer has not evilly
> made the full type for Time controlled, with an Adjust routine that does
> something erroneous?  Or raises GNAT.Evil_Exceptions.Whatever_Error?  Or
> writes the value 17 into all integer variables in the program?  We know
> that, because the correct way to interpret the RM is that if it doesn't
> say any of those bad things happen, then they don't.  The same way we
> know that 1+1 of Integers doesn't have side effects.

Hmmmm.  Really.  I think Robert has been hoisted on his own petard, :-)

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

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert I. Eachus]

In article <E14DCH.5EK@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > (Of course I know that two tasks modifying X at the same time would be
  > erroneous.  That's covered by 9.10.)

   And that is EXACTLY the point that kicked all this discussion off.
If an implementation works non-erroneously if the programmer read and
followed 9.10, end of discussion.

   I made an innocent seeming comment that in a tasking environment
the user of Unbounded_Strings HAS to provide a syncronization point
between any two references to the same value from different tasks, one
of which modifies it.  As a result, no simple implementation of
Unbounded_Strings should worry about race conditions.  Of course, any
hidden calls to new must be safe in a tasking environment even if some
other task is also allocating or freeing storage, but that is
different issue, and not local to Unbounded_Strings.

   However, if you do reference counts, there is a very unusual case
that needs to be considered.  But as I pointed out the potential
problems can be cleverly avoided, at the risk of doing some
"unnecessary" copies in race conditions.  So efficient "lazy"
implementations which use reference counting don't incur any
distributed overhead.  The extra copy in a transitive reference case
occurs only 1) if the case required to be non-erroneous occurs, or 2)
in an erroneous program where the reference counting version will do
the "right thing" instead of breaking.

   In other erroneous cases, the reference counting version will
break.  Tough!  The program would be just as erroneous, and more
likely to break if the unbounded string was actually a
Standard.String.  Hmmm... The language lawyer in my immediately reads
that and constructs weird cases.  There are cases where two tasks can
modify different sections of the same string non-erroneously, which
have to be considered erroneous if the operation is performed on an
unbounded string.  Those programs must be considered pathological,
however, I can imagine worst case scenarios where the erroneous
behavior is visible:

      Suppose one task creates an unbounded string, and passes it to
another task through a rendezvous.  Both task create copies, then
modify different sections of the original string.  Definitely
erroneous, but it will make lazy reference counting visible.

--

					Robert I. Eachus

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

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Van Snyder]

In article <dewar.845506606@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>"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!

If you want good arithmetic in a Java competitor, look at Inferno, from
AT&T Lucent Technologies.  I don't have the URL in my head, and I'm not
with my records, but if you're interested, send me e-mail and I'll
try to find it.  Or, look for Eric Grosse in the white pages at
www.netlib.org.

There's a "stack" of related products:  Inferno is the language.  Limbo
is the virtual machine.  Styx is the transport protocol.  Dis is the
operating system.

There are several implementations, including ones that run atop DOS,
Unix, or bare x86 hardware.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[Robert Dewar]

iGeert says

"I think it is a real reach to say that an Ada implementation is allowed
to provide an Unbounded_Strings package body which execution can be
erroneous in tasking programs."

  That's obviously wrong, if for instance two tasks try to do a slice
  operation in place on the same unbounded string from two different
  tasks, we definitely expect this to be erroneous in the normal manner
  for shared variables

  If Geert disagrees with this, he must certainly do more than provide
  an opinion "I think"

  Remember, the burden of proof is on you to show that an unlocked
  reference count scheme is incorrect, "I think" is not a proof. Please
  cite the exact argument from the RM to prove that this is wrong.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Bob Duff asks

"And you still haven't answered my main objection to your reading -- if
you read it that way, then why isn't practically everything in Annex A
erroneous?  And lots of other stuff.  E.g:

    X, Y: Calendar.Time := Clock;

    X := Y; -- Erroneous?

(No tasks here.)  How do we know that the implementer has not evilly
made the full type for Time controlled, with an Adjust routine that does
something erroneous?  Or raises GNAT.Evil_Exceptions ...."


No, I don't accept this as equivalent. The issue of the extent to which
library routines are task/thread safe is quite different from the issue
of single task semantics, which I think is clearly defined, and that is
why the above example definitely cannot be erroneous.

Obviously it is not the case that anything works in a threaded environment.
Your answer indeed agrees that certain things will be erroneous (e.g. if
the above assignment X := Y appeared in two tasks with no synhronization
then you would agree that it is probably erroneous -- not necessarily
of course, since the implementatoin may have a pragma atomic on its
Calendar.Time type, so this kind of erroneousness is definitely impl
dependent to some extent.

So just what *is* task safe, well the only guideline we have is the clause
in the reference manual that you don't think should be there, but I think
Tuck clearly was right to insist on it, otherwise we could not assume
anything about task safety of the libraryt routines.

As for your Text_IO example, what exactly IS required if two
tasks do a Put_Line to the same file at the same time? To me that
can still be erroneous (it is the same case as any other case where
two tasks molest the same variable, in this case the object for the
file type) at the same time, and I can't see why even the phrase in
the RM that you think is redundant gathers otherwise. Let's repeat
the RM phrase for reference:

3   The implementation shall ensure that each language defined subprogram is
reentrant in the sense that concurrent calls on the same subprogram perform
as specified, so long as all parameters that could be passed by reference
denote nonoverlapping objects.


Even if we decide that for the case of Put_Line with no file argument *is*
covered by this phrase, what does it mean? What level of interspersing
of output is implied by this wording (lines, characters, pixels???)

And of course it is quite clear that two writes to the same file using
Put_Line with a file argument are NOT covered by paragraph 3. So that's
mightly curious:

    Put_Line (Standard_Output, "xxxx");

appearing in two tasks is not covered, and could be erroneous, but

    Put_Line ("xxxx");

is OK. That seems quite weird to me, though I see how paragraph 3 could
be read this way.

Without paragraph 3, I have no idea why Bob Duff thinks that the language
has anything to say about either of these cases.

Friendly readings are fine, but I do not know what is friendly and what
is not.

Let'
s look at the reference count case.  I see two friendly readings here:

  1.  An efficient implementation with reference counts is permitted, no
      locks are needed, since if two tasks mess with the same sets of
      variables or values, the execution is erroneous.

  2.  If reference counts are used, task locks are required, requiring
      a kernel call on some systems, and therefore, becuase of the
      quite unacceptable efficiency effect, reference counts are out
      of the question.

Which of these is friendlier? Well if you don't use tasking, or if you
use only completely separated sets of values and variables in the
tasking case, you find 1 much friendlier, since a reference count
implementation makes a lot of sense in these cases.

If you insist on using unbounded strings across tasks, thinking that
the assignment semantics are like ordinary scalar types, then of course
you might find 1 friendlier.

Relying on a friendly reading is risky. I must say that initially I assumed
that reference counts could not be used and that consequently a copy on
modify approach is not practical, but I found Robert Eachus argument
here illuminating and convincing.

So Bob Duff thinks that the RM should say nothing, and that we should rely
on a friendly reading of what is and is not erroneous (he agrees that
certain calls to runtime routines are erroneous because of violating
shared variable rules, so this is a question of judgment). 

But in this case (reference counts), people do not agree on what is
friendly. So I think it is something the ARG should pin down. I don't
think that either decision (1 or 2 above) would be a major problem,
but failure to resolve this could lead to a very significant portability
problem.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Joel says

"This discussion is related to Unbounded strings and someone's suggestion to
use a reference-count finalization scheme and the possible problems with
that with respect to tasking.  The problem is that multiple tasks could
all try to access the reference count at the same time, one decrementing
and one incrementing for instance, right?  So, to prevent that, some sort
of locking would have to occur.  However, we are talking about simply
incrementing and/or decrementing 1 value in memory.  On most processors
that I can think of that is 3 operations, two memory accesses and an
integer operation.  Is the Ada tasking/priority method so accurate that
that one lower priority task can't tie up the machine for 2 extra
instructions?  I think it ought to be able to handle even more than that.
What about making an increment/decrement function that is a task or protected
object at the very highest priotity level (higher than the highest as this
is the compiler writer ... :) So essentially all reference counts are on the
same lock.  When a task wanted to adjust a reference count it would call /
rendevous with the increment/decrementer which would take over and
deal with the requested reference count.  As long as that doesn't take
too long and the call overhead isn't too large, no ones toes will be
stepped on."


The concern is not a semantic concern about taking the lock. As you point
out, as long as the lock has proper ceiling priority semantics, this is
consistent even with the strict semantic requirements of Annex D. The
concern is that in an operating system environment, taking this lock
may require a kernel call, and take thousands of instructions. This is
not just a regrettable inefficiency, it is sufficiently inefficient that
we could not consider using reference counts at all in this environment.

Basically reference counts and tasking do not go well together, which
is unfortunate, since reference counts are a powerful tool. Of course
on an architecture like the x86, which has an indivisible decrement
and increment that set the flags in a useful manner, you can implement
them efficiently, but this is not true on all architectures.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Unbounded_String's are built into the language from a semantic point of view.
>There are two possible implementations that are reasonable

There are more than just two.  For example, a third reasonable
implementation is to use garbage-collected storage with copy-on-write.
This has potential advantages over the two implementations that you
considered: it avoids the overhead of copying, and avoids the overhead
of locking.  (Of course, there are some potential disadvantages too.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <dewar.848758301@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>And of course it is quite clear that two writes to the same file using
>Put_Line with a file argument are NOT covered by paragraph 3. So that's
>mightly curious:
>
>    Put_Line (Standard_Output, "xxxx");
>
>appearing in two tasks is not covered, and could be erroneous, but
>
>    Put_Line ("xxxx");
>
>is OK. That seems quite weird to me, ...

Agreed.  In my opinion, both of the above should be considered
erroneous.  I said that in another article, and I also admitted that the
RM doesn't clearly say so.  As you say, if one thinks the above should
work, then one needs to worry about the granularity of interleaving.

>... though I see how paragraph 3 could
>be read this way.

>Without paragraph 3, I have no idea why Bob Duff thinks that the language
>has anything to say about either of these cases.

I think you're confusing what I said with what somebody else said.  Two
simultaneous Put_Lines are erroneous if they are writing to the same
file, but not if they are writing to two different files.  At least, in
my opinion, that's the way it *should* be.  The glitch in the RM wording
is that for the Put_Line without any file argument, there's no variable
in sight -- even though we know that Put_Line("xxx") and
Put_Line(Current_Output, "xxx") ought to have identical semantics.  If I
weren't so lazy, I tried to dig up some wording that says so, and then
we would be OK -- I don't remember exactly how the no-arg version is
defined.

>But in this case (reference counts), people do not agree on what is
>friendly. So I think it is something the ARG should pin down.

Apparently.  I'm surprised that you think the unprotected reference
count implementation is reasonable.  (Unless of course the compiler
knows there aren't any tasks causing trouble.)

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Fergus says

"There are more than just two.  For example, a third reasonable
implementation is to use garbage-collected storage with copy-on-write.
This has potential advantages over the two implementations that you
considered: it avoids the overhead of copying, and avoids the overhead
of locking.  (Of course, there are some potential disadvantages too.)"


Do you mean by this what I call copy-on-modify, if so this is indeed
one of the two possibilities that I considered. Note that if you have
a garbage collector around, you could take the position that ANYTHING
done with dynamic storage makes things erroneous acrosds tasks, on
the grounds that the garbage collector does non syncrhonized conflicting
accesses to storage, but this seems a bit extreme :-)

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Jon Anthony said

"Hmmmm.  Really.  I think Robert has been hoisted on his own petard, :-)"

Not at all, Jon, you have just been taken in by that classical argument
technique "argument by false analogy". It goes like this,

Ah ha, you said A, but if you say A, then you must also mean B and
B is ridiculous.

Fine, in this case I agree that B (not  providing proper sequential
semantics) is ridulous, but it has  very little to do with A (knowing
exactly what task safe means).

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

iRobert Eachus says

"      Suppose one task creates an unbounded string, and passes it to
another task through a rendezvous.  Both task create copies, then
modify different sections of the original string.  Definitely
erroneous, but it will make lazy reference counting visible."



The "definitely erroneous" here seems too strong to me. The point is that
we have two basic possible semantics of unbounded strings, one is to copy
on all assignments, and the other is to share copies, and copy only on a
modification.

I am completely unable to determine that one of these implementations is
somehow more reasonable, natural, expected, required or whatever, they
both seem quite reasonable to me.

But if we copy only on modification, then it is indeed true that the above
scenario is erroneous because the "create copies" presumably refers to
doing assignment statements, which do not create copies at the implementation
level. 

Bob tries to argue that this implemntation is somehow improper, but I don't
see that at all. Indeed copy on modify seems quite a reasonable 
implementation to me (it is for example what all SNOBOL4 and SPITBOL
implementations have done). In a garbage collected environment it is
also the most natural implementation.

But it certainly does have consequences with regard to thread safety!

The trouble here is that of course we expect to have proper value
semantics (and that indeed is why Bob's argument about other examples,
such as 1+1 not working are irrelevant, everyone agrees on the basic
single thread value semantics).

[[oops to clarify, Bob in the above  = Bob Duff]]

The trouble is that pure value semantics breaks down in a tasking
environment because of the shared variable issues, and we introduce
the notion of erroneous access to shared variables to patch this
up -- not a very satisfactory solution, but a pragmatic one, since
the only other alternative is to put locks on all variables all the
time.

Now when we get to Unbounded_String's, some kind of similar patch up
is required, but it definitely depends on the implementation model.
Since the RM text does not specify the implementation model, we are
unable to determine exactly the scope of the corresponding pragmatic
solution.

Going back to Robert Eachus' claim of "definitely erroneous", I guess
I *do* agree in the following sense:

Unbounded_String's are built into the language from a semantic point of view.
There are two possible implementations that are reasonable
For one of these implementations, the given operation *is* erroneous
Therefore, since one allowed implementation is erroneous, the set f
 possible effects is erroneous, even if in some implementations it
 might actually work (working is certainly one of the allowed
 behaviors for an erroneous execution -- the same is true after
 all of any shared variable erroneousity -- most of the time things
 are just fine.

One thing is clear, this should have been discussed during the language
design. The implementation technique of using transparent sharing via
pointers, with copy on modify rather than copy on assign is very
familiar, especially in the realm of variable length string processing,
so we shuld have anticipated this model, an discussed its interaction
with tasking.

---

The argument that this is NOT erroneous works something like this:


From a semantic point of view, assignment involves a copy. Yes, you can
"cheat" and not do a copy, but only if "as if" semantic equivalence is
maintained.

The copy-on-modify approach, though it might be fine (i.e. have fine
"as if" semantics in a single threaded environment) does NOT work fine
in a multi-threaded environment since it does not provide "as if"
semantics.

I find some merit in this argument, but I do not find it decisive, because
at the language level we have already introduced the notion of allowing
assignments and references to become erroneous as a result of shared
variable reference -- and we did it on pragmatic grounds, there would
have been no difficulty *semantically* in requiring assignment to work
properly in a threaded environment, even if shared variables are 
accessed, and no difficulty in implementing it -- just ghastly
efficiency issues.

Well here we sure have a similar case -- we have no trouble agreeing that
Bob Duff's claimed obvious semantics are fine, and that we can implement
them with no trouble -- but the implementation has a ghastly efficiency
problem (if taking locks is expensive).

Note that it is not just reference counts that cause this problem. Even if
we use what I would guess is the expected implementation of unbounded
strings which is to use controlled types (as in GNAT), we are in trouble.

Controlled types themselves implicitly reference global shared data
structures, or at least may do so in the model where chains of objects
to be finalized are maintained. If these chains must be protected against
multi-threading, there are again ghastly efficiency implications in 
systems where taking a lock is expensive. 

Of course if you carry the argument I and Robert Eachus are lmakig to logical
extremes, since type controlled is again just a type in a library package
whose implementation is hidden, it could be argued that it is not necessary
to take locks even in the controlled case, but this would introduce an even
more dramatic restriction on what could be done between tasks (basically
you would require controlled collections to be task specific -- and that
seems awfully restrictive).

Still, we definitely need more discussion here.

This is not the first time we have run into issues of having underspecified
the preefined library routines. Two previous cases are:

  1. The interaction of predefined private types with stream attributes. Do
     these predefined types have stream attributes that "work" in an 
     expected way. The RM does not ensure this (so for example using
     Read and Write with unbounded string is not rquired to work by the
     RM, but surely (?) it should, so an AI has been approved that 
     requires it to work -- this AI is a binding interpretation, a
     recognition that the RM was inadequate here.

  2. The package categorizatoin with respect to distribution pragmas was
     not thought through. The result is that the RM does not just fail to
     guarantee that certain types cannot be used with full flexibility in
     a distributed environment -- it REQUIRES that they NOT be able to be
     used. Again the ARG is looking into this.


Reasoning by what is friendly is never a safe occupation in the world
of language semantics. Certainly I think most poeple would agree that
the stream attributes SHOULD work for unbounded strings. The RM authors
either agreed with this explicitly, or implicitly, or simply did not
think about it. But the RM does NOT pin this down.

I think the business with reference counts and shared unbounded strings
between tasks is very much in this category, and certainly needs an
ARG discussion.

--

There is an interesting lesson for package and interface design here. Some
VERY detailed thought is required to properly document exactly what the
semantics of a package is when it is used in a multi-threaded environment.
I think we have been far too casual about this in the past.

Robert

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert I. Eachus]

   I said:

 > "      Suppose one task creates an unbounded string, and passes it to
 > another task through a rendezvous.  Both task create copies, then
 > modify different sections of the original string.  Definitely
 > erroneous, but it will make lazy reference counting visible."

   Robert Dewar said:

 > The "definitely erroneous" here seems too strong to me. The point is that
 > we have two basic possible semantics of unbounded strings, one is to copy
 > on all assignments, and the other is to share copies, and copy only on a
 > modification.

   I think Robert, you may need to reread my example.  If the two
tasks modified the copies, then the erroneousness would be
questionable.  But I have both tasks updating the same value without
an intervening synchronization point.  THAT is erroneous if anything
is.  The copies allow me to determine later whether lazy updating is
used, but are not what makes the example erroneous.  Even if the areas
modified are non-overlapping, an implementation can write words
instead of bytes.

   My point was that the program must be erroneous for lazy copies to
be visible with the given implementation strategy.  (There are other
methods involving unchecked conversions, but the addresses you get are
erroneous, because Unchecked_Conversion is not required to return
values by reference.)

   Other than that, I think Robert Dewar and I are in strong
agreement.  What happens if tasks share values without explicit
synchronization can't be used to govern how a library package is
implemented.  We can only reason about the behavior in cases where the
conditions in A(3) hold.

--

					Robert I. Eachus

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

Java vs Ada vs Inferno, floating point arithmetic

[Anssi Porttikivi]

About Inferno math library see <http://inferno.lucent.com/>
and especially <http://inferno.lucent.com/inferno/real.ps> or
<http://inferno.lucent.com/inferno/real.pdf> (same text).

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Kevin D. Heatwole]

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

>Well here we sure have a similar case -- we have no trouble agreeing that
>Bob Duff's claimed obvious semantics are fine, and that we can implement
>them with no trouble -- but the implementation has a ghastly efficiency
>problem (if taking locks is expensive).
>
>Note that it is not just reference counts that cause this problem. Even if
>we use what I would guess is the expected implementation of unbounded
>strings which is to use controlled types (as in GNAT), we are in trouble.
>
>Controlled types themselves implicitly reference global shared data
>structures, or at least may do so in the model where chains of objects
>to be finalized are maintained. If these chains must be protected against
>multi-threading, there are again ghastly efficiency implications in 
>systems where taking a lock is expensive. 

I think you might be going too far in categorizing this as having "ghastly
efficiency implications".  In a language that incorporates separate 
threads of execution, this "efficiency problem" occurs all over the place.
As you point out, an implementation for controlled types will probably
involve some need for serializing access to shared data structures.  So
does protected types, tasks, and even dynamic allocation of memory.

Indeed, the use of reference counts in an unbounded string implementation
is presumeably done to save a dynamic allocation which would involve
some taking of a lock anyway.

So, what is the big deal here as it applies to the specific case of unbounded
strings?

Certainly, initial implementations of controlled types, dynamic allocation,
and unbounded strings will be less than optimal, but it is up to us implementers
to provide efficient implementations of these features of Ada. 

Is it really that much harder to provide an efficient ref-counted tasking safe
implementation of unbounded strings than it is to provide an efficient tasking
safe allocator?

Kevin Heatwole
OC Systems, Inc.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <heatwole-ya023180002511960851580001@news.his.com>,
Kevin D. Heatwole <heatwole@his.com> wrote:
>Is it really that much harder to provide an efficient ref-counted tasking safe
>implementation of unbounded strings than it is to provide an efficient tasking
>safe allocator?

Two points:

You can make "new" efficient by having per-task pools of memory.
Allocate each task 4K (say) and use that for "new".  And if it runs out,
allocate some more from a global pool.  Or steal some from another task.
This will reduce the probability of lock contention.

I suspect that the most efficient method for unbounded strings is to use
full-fledged garbage collection.  I don't KNOW that, but from reading
various papers by GC advocates, I suspect it's probably true.  And I'm
talking about non-real-time systems here, where we care about best
"typical" performance -- I don't think one uses unbounded strings in
hard-real-time situations.  Of course, it's hard to implement an
efficient GC -- doubly so in a multi-threaded language.

OK, here's a third point:  All this talk about inefficient locks is
based on the assumption that each Ada task is mapped to a single OS
thread.  If you're willing to give up the benefits of that (on, say,
Windows 95), then it's not hard to do very efficient locking.

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Norman H. Cohen]

Robert Dewar wrote:

> Friendly readings are fine, but I do not know what is friendly and what
> is not.
> 
> Let's look at the reference count case.  I see two friendly readings here:
> 
>   1.  An efficient implementation with reference counts is permitted, no
>       locks are needed, since if two tasks mess with the same sets of
>       variables or values, the execution is erroneous.
> 
>   2.  If reference counts are used, task locks are required, requiring
>       a kernel call on some systems, and therefore, becuase of the
>       quite unacceptable efficiency effect, reference counts are out
>       of the question.
> 
> Which of these is friendlier? Well if you don't use tasking, or if you
> use only completely separated sets of values and variables in the
> tasking case, you find 1 much friendlier, since a reference count
> implementation makes a lot of sense in these cases.
> 
> If you insist on using unbounded strings across tasks, thinking that
> the assignment semantics are like ordinary scalar types, then of course
> you might find 1 friendlier.

What I would find friendliest is a run-time system with two versions of
Ada.Strings.Unbounded.  The version that uses reference counts but no
locks would only be linked in when I said

   pragma Restrictions (Max_Tasks => 1);

Otherwise, I would get the task-safe version (presumably without
reference counts, since the cost of locking would most likely outweigh
any savings from lazy copying).

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

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Franco Mazzanti]

Robert A. Duff wrote:

">And of course it is quite clear that two writes to the same file using
 >Put_Line with a file argument are NOT covered by paragraph 3. So that's
 >mightly curious:
  >
 >    Put_Line (Standard_Output, "xxxx");
 >
 >appearing in two tasks is not covered, and could be erroneous, but
 >
 >    Put_Line ("xxxx");
 >
 >is OK. That seems quite weird to me, ...

 Agreed.  In my opinion, both of the above should be considered
 erroneous.  I said that in another article, and I also admitted that the
 RM doesn't clearly say so.  As you say, if one thinks the above should
 work, then one needs to worry about the granularity of interleaving."


I know I am an heretic for my views on this subject. 

However I think that it is quite incorrect to consider "Standard_Output"
as a shared variable. "Standard_Output" is a function call, and it very likely
to return an anonymous temporary object. AT least this is what one would
expect by reading the RM (unless File_Type is a "return-by-reference" type).

Only if we make use of the version of "Standard_Output" which returns a
"File_Access" object, then in two concurrent calls of

   Put_Line (Standard_Output.all, "xxxx"); 

we would really use a shared variable.

However, even in this case, the erroneousnees is not clearly implied by the
reference manual because the File_Type argument has mode IN. So, we have
sharing, but this sharing is safe because it is "read only".

The picture which the RM naturally provides (at least to a naive reader) is
the only two concurrent Close, Delete, Reset, Flush operations on the same
File_Type variable are erroneous for 9.10 (or the execution of any of
these
operations bin parallel with a Get_Line, Put_Line, ...) because these 
operations actually take a File_Type parameter of mode IN OUT.

I agree that some attributes associated to file objects are modified by get 
and put operations (file position information). However, this kind of data
is completely outside the user view, is part of the underlying implementation
of the I/O system and A(3) seem really to imply that concurrent calls of
Put_line should be thread-safe.

With the respect to the granularity of the interleaving, I do not think that
one needs to worry about it. 
Once it is stated clearly that the effects of Put_line need not be atomic 
(with respect to the externel effect and the update of the file position
attributes) it is perfectly acceptable that the EXTERNAL effect of two 
put_line operations results in some unspecified interleaving of the data.

But this is very different from allowing the concurrent execution of even 
the operations:

   Put_Line(My_file, "my-string");
   V:Count := Col(F);

to be erroneous and "thrash my hard disk".

Franco Mazzanti

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <mazzanti-2511961115230001@131.114.200.115>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Only if we make use of the version of "Standard_Output" which returns a
>"File_Access" object, then in two concurrent calls of
>
>   Put_Line (Standard_Output.all, "xxxx"); 
>
>we would really use a shared variable.
>
>However, even in this case, the erroneousnees is not clearly implied by the
>reference manual because the File_Type argument has mode IN. So, we have
>sharing, but this sharing is safe because it is "read only".

One reason I object to this point of view is efficiency: It forces the
implementation to do some sort of locking inside Text_IO.  (In addition
to whatever the operating system does, I mean.)  But I need to do some
sort of locking in the program, too, because if I have two tasks writing
to the same file, I'm going to want to control the granularity of
interleaving.  So the locking with Text_IO is useless for a real
program.

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <heatwole-ya023180002611960850350001@news.his.com>,
Kevin D. Heatwole <heatwole@his.com> wrote:
>I suspect that even this approach would have some difficulties involving
>pool-specific (or global) locks.  While task A may allocate the storage
>out of its per-task pool of memory, task B may be the task that deallocates
>the memory later.  If you have two threads mucking about with the same
>pool of memory, you will need to implement some form of serialization.

If you implement your pools with free lists, then when you deallocate,
you can put that chunk of memory back on the current tasks free list,
despite the fact that it was allocated from some other task's free list.

>Of course, as you point out, garbage collection techniques might help to
>make the usual case efficient but this has its drawbacks (and still might
>not reduce/eliminate the need for locking).
>
>Also, note that getting the identity of the currently executing task may be
>inefficient as well.  On our target, AIX for the PowerPC, getting the identity
>of the current thread involves an AIX call to pthread_self.  Since there is
>no thread-specific memory, this call is implemented as a search of a thread
>id table using the current stack pointer with appropriate locking (boy, is this 
>slow!).

Good point.  (Of course, IMHO, the OS *ought* to support an efficient
Current_Thread primitive -- it's not that hard to implement.  But that
doesn't help you unless you've got control of the OS.)

>...  We have chosen to reserve a register to point to thread-specific 
>memory to alleviate this problem, but this makes C calling Ada slower 
>because it needs to call pthread_self to setup this register.

And if your target were an 80x86, you wouldn't have many registers to
spare.  Sigh.

>>OK, here's a third point:  All this talk about inefficient locks is
>>based on the assumption that each Ada task is mapped to a single OS
>>thread.  If you're willing to give up the benefits of that (on, say,
>>Windows 95), then it's not hard to do very efficient locking.
>
>Why is this true?  Is it because on most OSes, OS calls are inherently
>expensive?

Well, OS calls *are* inherently expensive, because you have to cross a
protection boundary.  But for multi-threading within a single
application, the protection boundary is pointless, IMHO.  After all,
threads share memory, so they can trash one another's data -- trashing
another task's return addresses is at least as bad as destroying the
data associated with locks and so forth.

>I would think that if the OS wanted to make this efficient and it was a
>priority for the users, the lock calls could be just as efficient (whether done
>by the OS or done by the Ada runtime).  Anyway, I suspect that now that
>many OSes are becoming multi-threaded and with the more common use of
>multiple processors (even in the PC world), that the OSes will become more
>friendly and efficient for us Ada compiler implementors.  The OSes are finally
>catching up with Ada!

Well, maybe.  Don't hold your breath.

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Larry Kilgallen]

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

> Well, OS calls *are* inherently expensive, because you have to cross a
> protection boundary.  But for multi-threading within a single
> application, the protection boundary is pointless, IMHO.  After all,
> threads share memory, so they can trash one another's data -- trashing
> another task's return addresses is at least as bad as destroying the
> data associated with locks and so forth.

Some thread-relevant OS calls affect the scheduler data in cases
where the OS can schedule separate threads on separate CPUs. The
scheduler data is typically stored together for all appications,
and one would not want an application to trash the data for some
other application.

Larry Kilgallen

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Geert Bosch]

Kevin D. Heatwole (heatwole@his.com) wrote:
 ``Is it really that much harder to provide an efficient ref-counted
   tasking safe implementation of unbounded strings than it is to
   provide an efficient tasking safe allocator? ''

No, it isn't. The only problems relate to the priority requirements of
Annex D.  When you want to use ceiling priority locks, it is necessary
to change and/or check priority of tasks which requires an expensive
system call.

As far as I'm concerned it is acceptable to have an implementation that
locks a reference counter, updates the count and unlocks it without any
priority checking, since the circumstances in which starvation of a
higher priority task occurs, because a lower-priority task has the lock
are very rare and the effects are much less disastrous then the
erroneous behavior of reference counts without locks. Also, raising an
exception in such cases is not too difficult to implement.

The problems related to implementing a locking scheme with such very
specific real-time behaviour as described by Annex D. should not be
an excuse to use no locks at all.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Kevin D. Heatwole]

In article <E1FnJC.HI4@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>In article <heatwole-ya023180002511960851580001@news.his.com>,
>Kevin D. Heatwole <heatwole@his.com> wrote:
>>Is it really that much harder to provide an efficient ref-counted tasking safe
>>implementation of unbounded strings than it is to provide an efficient tasking
>>safe allocator?
>
>Two points:
>
>You can make "new" efficient by having per-task pools of memory.
>Allocate each task 4K (say) and use that for "new".  And if it runs out,
>allocate some more from a global pool.  Or steal some from another task.
>This will reduce the probability of lock contention.

I suspect that even this approach would have some difficulties involving
pool-specific (or global) locks.  While task A may allocate the storage
out of its per-task pool of memory, task B may be the task that deallocates
the memory later.  If you have two threads mucking about with the same
pool of memory, you will need to implement some form of serialization.

Of course, as you point out, garbage collection techniques might help to
make the usual case efficient but this has its drawbacks (and still might
not reduce/eliminate the need for locking).

Also, note that getting the identity of the currently executing task may be
inefficient as well.  On our target, AIX for the PowerPC, getting the identity
of the current thread involves an AIX call to pthread_self.  Since there is
no thread-specific memory, this call is implemented as a search of a thread
id table using the current stack pointer with appropriate locking (boy, is this 
slow!).  We have chosen to reserve a register to point to thread-specific 
memory to alleviate this problem, but this makes C calling Ada slower 
because it needs to call pthread_self to setup this register.

>OK, here's a third point:  All this talk about inefficient locks is
>based on the assumption that each Ada task is mapped to a single OS
>thread.  If you're willing to give up the benefits of that (on, say,
>Windows 95), then it's not hard to do very efficient locking.

Why is this true?  Is it because on most OSes, OS calls are inherently
expensive?
I would think that if the OS wanted to make this efficient and it was a
priority for the users, the lock calls could be just as efficient (whether done
by the OS or done by the Ada runtime).  Anyway, I suspect that now that
many OSes are becoming multi-threaded and with the more common use of
multiple processors (even in the PC world), that the OSes will become more
friendly and efficient for us Ada compiler implementors.  The OSes are finally
catching up with Ada!

Kevin Heatwole
OC Systems, Inc.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Geert says, replying to Kevin:

Kevin D. Heatwole (heatwole@his.com) wrote:
 ``Is it really that much harder to provide an efficient ref-counted
   tasking safe implementation of unbounded strings than it is to
   provide an efficient tasking safe allocator? ''

No, it isn't. The only problems relate to the priority requirements of
Annex D.  When you want to use ceiling priority locks, it is necessary
to change and/or check priority of tasks which requires an expensive
system call.



Robert replies

That's incorrect, it is easy to think of strategies for writing task
safe allocators that greatly reduce the requirement for this expensive
locking. In particular, an obvious strategy is to cache a chunk of
storage for a task doing dynamic allocation, and use this cache to
satisfy local requests, so that the expensive locking is only required
to get a new chunk. We don't do that by default in GNAT, but it is
quite easy, using the storage pools mechanism and task attributes,
to write a storage pool that works that way and use it.

On the other hand, if you are forced into using locks for reference
counts, then no such tricks are at hand, and you will need the
expensive system call for every unbounded string assignment, which
is pretty fierce.

Note also that in a typical use of unbounded strings, you may do many
more assignments of UBS's than allocations, so even if you are using
the standard allocator which takes a lock, you pay that only on a new
string -- taking a lock on every assignment may be much worse.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Norman says

"What I would find friendliest is a run-time system with two versions of
Ada.Strings.Unbounded.  The version that uses reference counts but no
locks would only be linked in when I said
"


But the locks don't cost anything significant if no tasking is active,
at least this is true in the GNAT runtime (see the implementation of
System.Tasking_Soft_Links.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert Dewar]

Kevin D. Heatwole <heatwole@his.com> wrote:
>I suspect that even this approach would have some difficulties involving
>pool-specific (or global) locks.  While task A may allocate the storage
>out of its per-task pool of memory, task B may be the task that deallocates
>the memory later.  If you have two threads mucking about with the same
>pool of memory, you will need to implement some form of serialization.


That suspicion is wrong, there is for instance the familiar free storage
management technique (used in Microsoft Pascal, and in the x86 Alsys
implementation -- I know about the latter, I write it :-) where free simply
sets the free bit and NOTHING else, and recombination of blocks is done
entirely by the allocator. There are other techniques to avoid locking
for the free case.

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Norman H. Cohen]

Robert A Duff wrote:
 
> In article <heatwole-ya023180002611960850350001@news.his.com>,
> Kevin D. Heatwole <heatwole@his.com> wrote:
> >I suspect that even this approach would have some difficulties involving
> >pool-specific (or global) locks.  While task A may allocate the storage
> >out of its per-task pool of memory, task B may be the task that deallocates
> >the memory later.  If you have two threads mucking about with the same
> >pool of memory, you will need to implement some form of serialization.
> 
> If you implement your pools with free lists, then when you deallocate,
> you can put that chunk of memory back on the current tasks free list,
> despite the fact that it was allocated from some other task's free list.

That doesn't seem like a good idea.

Apparently you're assuming fixed-size allocations, so that there is
never a need to coalesce a freed block with neighboring free storage (or
else you are deferring the coalescing until the next allocation by the
task owning the free list).

More seriously, however, imagine a producer/consumer design in which the
producer task allocates and initializes an object and passes the access
value pointing to it to the consumer task.  The consumer task processes
the object and deallocates it.  In your scheme, the producer task will
constantly be requesting more and more storage blocks from the global
heap so that it can chop the blocks up into allocated objects; all of
the allocated objects eventually end up on the consumer task's free
list, but are never used again.

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

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Robert A Duff]

In article <329C945E.6FCB@watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>That doesn't seem like a good idea.

I didn't mean it's *always* a good idea -- it depends on the program.

>Apparently you're assuming fixed-size allocations, so that there is
>never a need to coalesce a freed block with neighboring free storage (or
>else you are deferring the coalescing until the next allocation by the
>task owning the free list).

Yes, but there are a lot of programs that use fixed sizes, or a small
number of fixed sizes.

>More seriously, however, imagine a producer/consumer design in which the
>producer task allocates and initializes an object and passes the access
>value pointing to it to the consumer task.  The consumer task processes
>the object and deallocates it.  In your scheme, the producer task will
>constantly be requesting more and more storage blocks from the global
>heap so that it can chop the blocks up into allocated objects; all of
>the allocated objects eventually end up on the consumer task's free
>list, but are never used again.

Yes, if you always go to the global heap when you run out.  An
alternative is to steal memory from another task.  This means that you
have to lock the per-task heaps, but the scheme can still win, because
getting a lock that's not already locked can be made cheap, and the
scheme reduces that probability in many cases (though not in the case
you mention above).

- Bob

Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[Fergus Henderson]

"Norman H. Cohen" <ncohen@watson.ibm.com> writes:

>[...] imagine a producer/consumer design in which the
>producer task allocates and initializes an object and passes the access
>value pointing to it to the consumer task.  The consumer task processes
>the object and deallocates it.  In your scheme, the producer task will
>constantly be requesting more and more storage blocks from the global
>heap so that it can chop the blocks up into allocated objects; all of
>the allocated objects eventually end up on the consumer task's free
>list, but are never used again.

You could avoid this by keeping a count of the space in each task's
free list: each deallocation would check the amount of free space,
and if this is greater than some threshold, return most of the free
memory chunks to the global heap.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.