* Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
@ 1996-10-10 0:00 ` Brian Rogoff
1996-10-10 0:00 ` Dave
1996-10-11 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
1996-10-11 0:00 ` Jon S Anthony
` (26 subsequent siblings)
27 siblings, 2 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Brian Rogoff
@ 1996-10-10 0:00 ` Dave
1996-10-11 0:00 ` Robert Dewar
` (4 more replies)
1996-10-11 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
1 sibling, 5 replies; 250+ messages in thread
From: Dave @ 1996-10-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Dave
@ 1996-10-11 0:00 ` Robert Dewar
1996-10-12 0:00 ` davedave
1996-10-11 0:00 ` Stephen Leake
` (3 subsequent siblings)
4 siblings, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-11 0:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Robert Dewar
@ 1996-10-12 0:00 ` davedave
1996-10-12 0:00 ` Robert Dewar
1996-10-13 0:00 ` Larry Kilgallen
0 siblings, 2 replies; 250+ messages in thread
From: davedave @ 1996-10-12 0:00 UTC (permalink / raw)
Cc: 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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` davedave
@ 1996-10-12 0:00 ` Robert Dewar
1996-10-13 0:00 ` Larry Kilgallen
1 sibling, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-12 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` davedave
1996-10-12 0:00 ` Robert Dewar
@ 1996-10-13 0:00 ` Larry Kilgallen
1 sibling, 0 replies; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-13 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Dave
1996-10-11 0:00 ` Robert Dewar
@ 1996-10-11 0:00 ` Stephen Leake
1996-10-11 0:00 ` Dave
1996-10-11 0:00 ` Tucker Taft
` (2 subsequent siblings)
4 siblings, 1 reply; 250+ messages in thread
From: Stephen Leake @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Stephen Leake
@ 1996-10-11 0:00 ` Dave
1996-10-11 0:00 ` Robert Dewar
0 siblings, 1 reply; 250+ messages in thread
From: Dave @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Dave
@ 1996-10-11 0:00 ` Robert Dewar
1996-10-12 0:00 ` Dave
0 siblings, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-11 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Robert Dewar
@ 1996-10-12 0:00 ` Dave
1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Keith Thompson
0 siblings, 2 replies; 250+ messages in thread
From: Dave @ 1996-10-12 0:00 UTC (permalink / raw)
Cc: davedave
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Dave
@ 1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Keith Thompson
1 sibling, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-12 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Dave
1996-10-12 0:00 ` Robert Dewar
@ 1996-10-14 0:00 ` Keith Thompson
1 sibling, 0 replies; 250+ messages in thread
From: Keith Thompson @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Dave
1996-10-11 0:00 ` Robert Dewar
1996-10-11 0:00 ` Stephen Leake
@ 1996-10-11 0:00 ` Tucker Taft
1996-10-14 0:00 ` Brian Rogoff
` (3 more replies)
1996-10-18 0:00 ` Why no Propagates? Michel Gauthier
1996-10-23 0:00 ` Michel Gauthier
4 siblings, 4 replies; 250+ messages in thread
From: Tucker Taft @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Tucker Taft
@ 1996-10-14 0:00 ` Brian Rogoff
1996-10-15 0:00 ` Robert A Duff
` (2 more replies)
1996-10-16 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Jon S Anthony
` (2 subsequent siblings)
3 siblings, 3 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Brian Rogoff
@ 1996-10-15 0:00 ` Robert A Duff
1996-10-15 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Larry Kilgallen
` (3 more replies)
1996-10-15 0:00 ` Mike Stark
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
2 siblings, 4 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Portability of Arithmetic (was: Java vs Ada 95)
1996-10-15 0:00 ` Robert A Duff
@ 1996-10-15 0:00 ` Larry Kilgallen
1996-10-16 0:00 ` Robert A Duff
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Robert Dewar
` (2 subsequent siblings)
3 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-15 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Larry Kilgallen
@ 1996-10-16 0:00 ` Robert A Duff
1996-10-16 0:00 ` Robert Dewar
1996-10-17 0:00 ` Stephen Leake
0 siblings, 2 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-16 0:00 ` Robert A Duff
@ 1996-10-16 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Stephen Leake
1 sibling, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-16 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-16 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Larry Kilgallen
0 siblings, 2 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert A Duff
@ 1996-10-17 0:00 ` Robert Dewar
1996-10-18 0:00 ` Norman H. Cohen
1996-10-18 0:00 ` Larry Kilgallen
1996-10-17 0:00 ` Larry Kilgallen
1 sibling, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert Dewar
@ 1996-10-18 0:00 ` Norman H. Cohen
1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` Larry Kilgallen
1 sibling, 1 reply; 250+ messages in thread
From: Norman H. Cohen @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Norman H. Cohen
@ 1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` Brian R. Hanson
` (2 more replies)
0 siblings, 3 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-18 0:00 UTC (permalink / raw)
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 :-)
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Robert Dewar
@ 1996-10-18 0:00 ` Brian R. Hanson
1996-10-19 0:00 ` Robert Dewar
1996-10-21 0:00 ` Norman H. Cohen
1996-10-21 0:00 ` Lance Kibblewhite
2 siblings, 1 reply; 250+ messages in thread
From: Brian R. Hanson @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Brian R. Hanson
@ 1996-10-19 0:00 ` Robert Dewar
1996-10-19 0:00 ` Larry Kilgallen
1996-10-21 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Norman H. Cohen
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-19 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-19 0:00 ` Robert Dewar
@ 1996-10-19 0:00 ` Larry Kilgallen
1996-10-22 0:00 ` Once again, Ada absent from DoD SBIR solicitation Dale Stanbrough
1996-10-21 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Norman H. Cohen
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-19 0:00 UTC (permalink / raw)
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.)
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Once again, Ada absent from DoD SBIR solicitation
1996-10-19 0:00 ` Larry Kilgallen
@ 1996-10-22 0:00 ` Dale Stanbrough
1996-10-27 0:00 ` Robert Dewar
0 siblings, 1 reply; 250+ messages in thread
From: Dale Stanbrough @ 1996-10-22 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-19 0:00 ` Robert Dewar
1996-10-19 0:00 ` Larry Kilgallen
@ 1996-10-21 0:00 ` Norman H. Cohen
1996-10-21 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Norman H. Cohen @ 1996-10-21 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` Brian R. Hanson
@ 1996-10-21 0:00 ` Norman H. Cohen
1996-10-21 0:00 ` Robert Dewar
1996-10-21 0:00 ` Lance Kibblewhite
2 siblings, 1 reply; 250+ messages in thread
From: Norman H. Cohen @ 1996-10-21 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-21 0:00 ` Norman H. Cohen
@ 1996-10-21 0:00 ` Robert Dewar
1996-10-22 0:00 ` Larry Kilgallen
1996-10-23 0:00 ` Norman H. Cohen
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-21 0:00 UTC (permalink / raw)
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?)
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-21 0:00 ` Robert Dewar
@ 1996-10-22 0:00 ` Larry Kilgallen
1996-10-23 0:00 ` Robert Dewar
1996-10-23 0:00 ` Norman H. Cohen
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-22 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-22 0:00 ` Larry Kilgallen
@ 1996-10-23 0:00 ` Robert Dewar
1996-10-23 0:00 ` Larry Kilgallen
0 siblings, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-23 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-23 0:00 ` Robert Dewar
@ 1996-10-23 0:00 ` Larry Kilgallen
0 siblings, 0 replies; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-23 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-21 0:00 ` Robert Dewar
1996-10-22 0:00 ` Larry Kilgallen
@ 1996-10-23 0:00 ` Norman H. Cohen
1 sibling, 0 replies; 250+ messages in thread
From: Norman H. Cohen @ 1996-10-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` Brian R. Hanson
1996-10-21 0:00 ` Norman H. Cohen
@ 1996-10-21 0:00 ` Lance Kibblewhite
2 siblings, 0 replies; 250+ messages in thread
From: Lance Kibblewhite @ 1996-10-21 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert Dewar
1996-10-18 0:00 ` Norman H. Cohen
@ 1996-10-18 0:00 ` Larry Kilgallen
1996-10-18 0:00 ` Robert A Duff
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-18 0:00 ` Larry Kilgallen
@ 1996-10-18 0:00 ` Robert A Duff
0 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Larry Kilgallen
1996-10-18 0:00 ` Robert A Duff
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Larry Kilgallen
@ 1996-10-18 0:00 ` Robert A Duff
0 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-16 0:00 ` Robert A Duff
1996-10-16 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Stephen Leake
1996-10-17 0:00 ` Robert A Duff
1 sibling, 1 reply; 250+ messages in thread
From: Stephen Leake @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Stephen Leake
@ 1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Larry Kilgallen
0 siblings, 2 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert A Duff
@ 1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Larry Kilgallen
1 sibling, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Larry Kilgallen
1996-10-18 0:00 ` Robert A Duff
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Portability of Arithmetic (was: Java vs Ada 95)
1996-10-17 0:00 ` Larry Kilgallen
@ 1996-10-18 0:00 ` Robert A Duff
0 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert A Duff
1996-10-15 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Larry Kilgallen
@ 1996-10-15 0:00 ` Robert Dewar
1996-10-17 0:00 ` Alan Brain
1996-10-24 0:00 ` Robert I. Eachus
3 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-15 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert A Duff
1996-10-15 0:00 ` Portability of Arithmetic (was: Java vs Ada 95) Larry Kilgallen
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Robert Dewar
@ 1996-10-17 0:00 ` Alan Brain
1996-10-17 0:00 ` Robert Dewar
` (2 more replies)
1996-10-24 0:00 ` Robert I. Eachus
3 siblings, 3 replies; 250+ messages in thread
From: Alan Brain @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-17 0:00 ` Alan Brain
@ 1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert A Duff
1996-10-18 0:00 ` Keith Thompson
2 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-17 0:00 ` Alan Brain
1996-10-17 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Robert A Duff
1996-10-18 0:00 ` Keith Thompson
2 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-17 0:00 ` Alan Brain
1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert A Duff
@ 1996-10-18 0:00 ` Keith Thompson
1996-10-20 0:00 ` Alan Brain
2 siblings, 1 reply; 250+ messages in thread
From: Keith Thompson @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-18 0:00 ` Keith Thompson
@ 1996-10-20 0:00 ` Alan Brain
0 siblings, 0 replies; 250+ messages in thread
From: Alan Brain @ 1996-10-20 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert A Duff
` (2 preceding siblings ...)
1996-10-17 0:00 ` Alan Brain
@ 1996-10-24 0:00 ` Robert I. Eachus
3 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-10-24 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Brian Rogoff
1996-10-15 0:00 ` Robert A Duff
@ 1996-10-15 0:00 ` Mike Stark
1996-10-15 0:00 ` Robert Dewar
1996-10-17 0:00 ` Why no Propagates? Matthew Heaney
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
2 siblings, 2 replies; 250+ messages in thread
From: Mike Stark @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Mike Stark
@ 1996-10-15 0:00 ` Robert Dewar
1996-10-16 0:00 ` Mike Stark
1996-10-17 0:00 ` Why no Propagates? Matthew Heaney
1 sibling, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-15 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert Dewar
@ 1996-10-16 0:00 ` Mike Stark
1996-10-17 0:00 ` Robert A Duff
0 siblings, 1 reply; 250+ messages in thread
From: Mike Stark @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Mike Stark
@ 1996-10-17 0:00 ` Robert A Duff
0 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Why no Propagates?
1996-10-15 0:00 ` Mike Stark
1996-10-15 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
` (2 more replies)
1 sibling, 3 replies; 250+ messages in thread
From: Matthew Heaney @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Why no Propagates?
1996-10-17 0:00 ` Why no Propagates? Matthew Heaney
@ 1996-10-18 0:00 ` Robert A Duff
1996-10-18 0:00 ` Norman H. Cohen
1996-10-18 0:00 ` Robert Dewar
2 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Why no Propagates?
1996-10-17 0:00 ` Why no Propagates? Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
@ 1996-10-18 0:00 ` Norman H. Cohen
1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` Robert Dewar
2 siblings, 1 reply; 250+ messages in thread
From: Norman H. Cohen @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Why no Propagates?
1996-10-17 0:00 ` Why no Propagates? Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
1996-10-18 0:00 ` Norman H. Cohen
@ 1996-10-18 0:00 ` Robert Dewar
2 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-18 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Brian Rogoff
1996-10-15 0:00 ` Robert A Duff
1996-10-15 0:00 ` Mike Stark
@ 1996-10-15 0:00 ` Mitch Gart
1996-10-15 0:00 ` Larry Kilgallen
` (2 more replies)
2 siblings, 3 replies; 250+ messages in thread
From: Mitch Gart @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
@ 1996-10-15 0:00 ` Larry Kilgallen
1996-10-15 0:00 ` Mark A Biggar
1996-10-16 0:00 ` Brian Rogoff
1996-10-28 0:00 ` Kenneth Almquist
2 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Larry Kilgallen
@ 1996-10-15 0:00 ` Mark A Biggar
0 siblings, 0 replies; 250+ messages in thread
From: Mark A Biggar @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
1996-10-15 0:00 ` Larry Kilgallen
@ 1996-10-16 0:00 ` Brian Rogoff
1996-10-28 0:00 ` Kenneth Almquist
2 siblings, 0 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Mitch Gart
1996-10-15 0:00 ` Larry Kilgallen
1996-10-16 0:00 ` Brian Rogoff
@ 1996-10-28 0:00 ` Kenneth Almquist
1996-10-29 0:00 ` Invoking parental methods (was: Java vs Ada 95) Larry Kilgallen
2 siblings, 1 reply; 250+ messages in thread
From: Kenneth Almquist @ 1996-10-28 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 250+ messages in thread* Invoking parental methods (was: Java vs Ada 95)
1996-10-28 0:00 ` Kenneth Almquist
@ 1996-10-29 0:00 ` Larry Kilgallen
1996-10-31 0:00 ` Kenneth Almquist
0 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-29 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Invoking parental methods (was: Java vs Ada 95)
1996-10-29 0:00 ` Invoking parental methods (was: Java vs Ada 95) Larry Kilgallen
@ 1996-10-31 0:00 ` Kenneth Almquist
1996-10-31 0:00 ` Larry Kilgallen
0 siblings, 1 reply; 250+ messages in thread
From: Kenneth Almquist @ 1996-10-31 0:00 UTC (permalink / raw)
> 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;
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-10-31 0:00 ` Kenneth Almquist
@ 1996-10-31 0:00 ` Larry Kilgallen
1996-11-05 0:00 ` Mitch Gart
0 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-31 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-10-31 0:00 ` Larry Kilgallen
@ 1996-11-05 0:00 ` Mitch Gart
1996-11-05 0:00 ` Tucker Taft
1996-11-05 0:00 ` Larry Kilgallen
0 siblings, 2 replies; 250+ messages in thread
From: Mitch Gart @ 1996-11-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Mitch Gart
@ 1996-11-05 0:00 ` Tucker Taft
1996-11-05 0:00 ` Larry Kilgallen
` (4 more replies)
1996-11-05 0:00 ` Larry Kilgallen
1 sibling, 5 replies; 250+ messages in thread
From: Tucker Taft @ 1996-11-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Tucker Taft
@ 1996-11-05 0:00 ` Larry Kilgallen
1996-11-06 0:00 ` Robert A Duff
1996-11-06 0:00 ` Robert I. Eachus
` (3 subsequent siblings)
4 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-11-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Larry Kilgallen
@ 1996-11-06 0:00 ` Robert A Duff
1996-11-06 0:00 ` Larry Kilgallen
0 siblings, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-06 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-06 0:00 ` Robert A Duff
@ 1996-11-06 0:00 ` Larry Kilgallen
0 siblings, 0 replies; 250+ messages in thread
From: Larry Kilgallen @ 1996-11-06 0:00 UTC (permalink / raw)
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 !
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Tucker Taft
1996-11-05 0:00 ` Larry Kilgallen
@ 1996-11-06 0:00 ` Robert I. Eachus
1996-11-07 0:00 ` David Wheeler
1996-11-06 0:00 ` Mitch Gart
` (2 subsequent siblings)
4 siblings, 1 reply; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-06 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-06 0:00 ` Robert I. Eachus
@ 1996-11-07 0:00 ` David Wheeler
0 siblings, 0 replies; 250+ messages in thread
From: David Wheeler @ 1996-11-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Tucker Taft
1996-11-05 0:00 ` Larry Kilgallen
1996-11-06 0:00 ` Robert I. Eachus
@ 1996-11-06 0:00 ` Mitch Gart
1996-11-08 0:00 ` Jon S Anthony
1996-11-08 0:00 ` Robert I. Eachus
4 siblings, 0 replies; 250+ messages in thread
From: Mitch Gart @ 1996-11-06 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Tucker Taft
` (2 preceding siblings ...)
1996-11-06 0:00 ` Mitch Gart
@ 1996-11-08 0:00 ` Jon S Anthony
1996-11-08 0:00 ` Robert I. Eachus
4 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-11-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Tucker Taft
` (3 preceding siblings ...)
1996-11-08 0:00 ` Jon S Anthony
@ 1996-11-08 0:00 ` Robert I. Eachus
4 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-08 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Mitch Gart
1996-11-05 0:00 ` Tucker Taft
@ 1996-11-05 0:00 ` Larry Kilgallen
1996-11-09 0:00 ` Joel VanLaven
1 sibling, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-11-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Invoking parental methods (was: Java vs Ada 95)
1996-11-05 0:00 ` Larry Kilgallen
@ 1996-11-09 0:00 ` Joel VanLaven
0 siblings, 0 replies; 250+ messages in thread
From: Joel VanLaven @ 1996-11-09 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Tucker Taft
1996-10-14 0:00 ` Brian Rogoff
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-16 0:00 ` Brian Rogoff
1996-10-16 0:00 ` Brian Rogoff
3 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Tucker Taft
1996-10-14 0:00 ` Brian Rogoff
1996-10-16 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Jon S Anthony
@ 1996-10-16 0:00 ` Brian Rogoff
1996-10-16 0:00 ` Brian Rogoff
3 siblings, 0 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Tucker Taft
` (2 preceding siblings ...)
1996-10-16 0:00 ` Brian Rogoff
@ 1996-10-16 0:00 ` Brian Rogoff
1996-10-16 0:00 ` Robert Dewar
3 siblings, 1 reply; 250+ messages in thread
From: Brian Rogoff @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Brian Rogoff
@ 1996-10-16 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert A Duff
1996-11-22 0:00 ` Van Snyder
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-16 0:00 UTC (permalink / raw)
"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!
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Robert A Duff
1996-10-17 0:00 ` Robert Dewar
1996-11-22 0:00 ` Van Snyder
1 sibling, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-17 0:00 ` Robert A Duff
@ 1996-10-17 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert A Duff
@ 1996-11-22 0:00 ` Van Snyder
1996-11-25 0:00 ` Java vs Ada vs Inferno, floating point arithmetic Anssi Porttikivi
1 sibling, 1 reply; 250+ messages in thread
From: Van Snyder @ 1996-11-22 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Why no Propagates?
1996-10-10 0:00 ` Dave
` (2 preceding siblings ...)
1996-10-11 0:00 ` Tucker Taft
@ 1996-10-18 0:00 ` Michel Gauthier
1996-10-22 0:00 ` Richard A. O'Keefe
1996-10-23 0:00 ` Michel Gauthier
4 siblings, 1 reply; 250+ messages in thread
From: Michel Gauthier @ 1996-10-18 0:00 UTC (permalink / raw)
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
---------- ---------- ---------- ----------
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Why no Propagates?
1996-10-18 0:00 ` Why no Propagates? Michel Gauthier
@ 1996-10-22 0:00 ` Richard A. O'Keefe
0 siblings, 0 replies; 250+ messages in thread
From: Richard A. O'Keefe @ 1996-10-22 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Why no Propagates?
1996-10-10 0:00 ` Dave
` (3 preceding siblings ...)
1996-10-18 0:00 ` Why no Propagates? Michel Gauthier
@ 1996-10-23 0:00 ` Michel Gauthier
4 siblings, 0 replies; 250+ messages in thread
From: Michel Gauthier @ 1996-10-23 0:00 UTC (permalink / raw)
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
---------- ---------- ---------- ----------
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Brian Rogoff
1996-10-10 0:00 ` Dave
@ 1996-10-11 0:00 ` Mitch Gart
1 sibling, 0 replies; 250+ messages in thread
From: Mitch Gart @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
1996-10-10 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Brian Rogoff
@ 1996-10-11 0:00 ` Jon S Anthony
1996-10-11 0:00 ` Jon S Anthony
` (25 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
1996-10-10 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Brian Rogoff
1996-10-11 0:00 ` Jon S Anthony
@ 1996-10-11 0:00 ` Jon S Anthony
1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Keith Thompson
1996-10-12 0:00 ` davedave
` (24 subsequent siblings)
27 siblings, 2 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Jon S Anthony
@ 1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Mitch Gart
1996-10-14 0:00 ` Brian R. Hanson
1996-10-14 0:00 ` Keith Thompson
1 sibling, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-12 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Robert Dewar
@ 1996-10-14 0:00 ` Mitch Gart
1996-10-14 0:00 ` Brian R. Hanson
1 sibling, 0 replies; 250+ messages in thread
From: Mitch Gart @ 1996-10-14 0:00 UTC (permalink / raw)
: 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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Mitch Gart
@ 1996-10-14 0:00 ` Brian R. Hanson
1 sibling, 0 replies; 250+ messages in thread
From: Brian R. Hanson @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-11 0:00 ` Jon S Anthony
1996-10-12 0:00 ` Robert Dewar
@ 1996-10-14 0:00 ` Keith Thompson
1996-10-15 0:00 ` Dale Stanbrough
1996-10-20 0:00 ` nasser
1 sibling, 2 replies; 250+ messages in thread
From: Keith Thompson @ 1996-10-14 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Keith Thompson
@ 1996-10-15 0:00 ` Dale Stanbrough
1996-10-15 0:00 ` Brian R. Hanson
1996-10-20 0:00 ` nasser
1 sibling, 1 reply; 250+ messages in thread
From: Dale Stanbrough @ 1996-10-15 0:00 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Dale Stanbrough
@ 1996-10-15 0:00 ` Brian R. Hanson
0 siblings, 0 replies; 250+ messages in thread
From: Brian R. Hanson @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Keith Thompson
1996-10-15 0:00 ` Dale Stanbrough
@ 1996-10-20 0:00 ` nasser
1 sibling, 0 replies; 250+ messages in thread
From: nasser @ 1996-10-20 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (2 preceding siblings ...)
1996-10-11 0:00 ` Jon S Anthony
@ 1996-10-12 0:00 ` davedave
1996-10-12 0:00 ` Robert Dewar
1996-10-14 0:00 ` Brian Rogoff
` (23 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: davedave @ 1996-10-12 0:00 UTC (permalink / raw)
Cc: 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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` davedave
@ 1996-10-12 0:00 ` Robert Dewar
1996-10-16 0:00 ` Jon S Anthony
1996-10-16 0:00 ` Jon S Anthony
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-12 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Robert Dewar
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-16 0:00 ` Jon S Anthony
1 sibling, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-12 0:00 ` Robert Dewar
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-16 0:00 ` Jon S Anthony
1 sibling, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (3 preceding siblings ...)
1996-10-12 0:00 ` davedave
@ 1996-10-14 0:00 ` Brian Rogoff
1996-10-14 0:00 ` Jon S Anthony
` (22 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (4 preceding siblings ...)
1996-10-14 0:00 ` Brian Rogoff
@ 1996-10-14 0:00 ` Jon S Anthony
1996-10-14 0:00 ` Jon S Anthony
` (21 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (5 preceding siblings ...)
1996-10-14 0:00 ` Jon S Anthony
@ 1996-10-14 0:00 ` Jon S Anthony
1996-10-14 0:00 ` Robert Dewar
1996-10-14 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Jon S Anthony
` (20 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: Jon S Anthony @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Jon S Anthony
@ 1996-10-14 0:00 ` Robert Dewar
1996-10-15 0:00 ` Robert A Duff
1996-10-17 0:00 ` Why no Free? Matthew Heaney
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-14 0:00 ` Robert Dewar
@ 1996-10-15 0:00 ` Robert A Duff
1996-10-15 0:00 ` Larry Kilgallen
1996-10-17 0:00 ` Why no Free? Matthew Heaney
1 sibling, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert A Duff
@ 1996-10-15 0:00 ` Larry Kilgallen
1996-10-16 0:00 ` Lars Farm
0 siblings, 1 reply; 250+ messages in thread
From: Larry Kilgallen @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Larry Kilgallen
@ 1996-10-16 0:00 ` Lars Farm
1996-10-16 0:00 ` Robert Dewar
0 siblings, 1 reply; 250+ messages in thread
From: Lars Farm @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Lars Farm
@ 1996-10-16 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-16 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Why no Free?
1996-10-14 0:00 ` Robert Dewar
1996-10-15 0:00 ` Robert A Duff
@ 1996-10-17 0:00 ` Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
` (2 more replies)
1 sibling, 3 replies; 250+ messages in thread
From: Matthew Heaney @ 1996-10-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Why no Free?
1996-10-17 0:00 ` Why no Free? Matthew Heaney
@ 1996-10-18 0:00 ` Robert A Duff
1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` John Herro
2 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Why no Free?
1996-10-17 0:00 ` Why no Free? Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
@ 1996-10-18 0:00 ` Robert Dewar
1996-10-18 0:00 ` John Herro
2 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-18 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Why no Free?
1996-10-17 0:00 ` Why no Free? Matthew Heaney
1996-10-18 0:00 ` Robert A Duff
1996-10-18 0:00 ` Robert Dewar
@ 1996-10-18 0:00 ` John Herro
1996-10-19 0:00 ` John Herro
2 siblings, 1 reply; 250+ messages in thread
From: John Herro @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (6 preceding siblings ...)
1996-10-14 0:00 ` Jon S Anthony
@ 1996-10-14 0:00 ` Jon S Anthony
1996-10-14 0:00 ` Jon S Anthony
` (19 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (7 preceding siblings ...)
1996-10-14 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Jon S Anthony
@ 1996-10-14 0:00 ` Jon S Anthony
1996-10-15 0:00 ` Robert I. Eachus
` (18 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (8 preceding siblings ...)
1996-10-14 0:00 ` Jon S Anthony
@ 1996-10-15 0:00 ` Robert I. Eachus
1996-10-15 0:00 ` Robert Dewar
1996-10-15 0:00 ` Brian Rogoff
` (17 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: Robert I. Eachus @ 1996-10-15 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-15 0:00 ` Robert I. Eachus
@ 1996-10-15 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-15 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (9 preceding siblings ...)
1996-10-15 0:00 ` Robert I. Eachus
@ 1996-10-15 0:00 ` Brian Rogoff
1996-10-15 0:00 ` Robert I. Eachus
` (16 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Brian Rogoff @ 1996-10-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (10 preceding siblings ...)
1996-10-15 0:00 ` Brian Rogoff
@ 1996-10-15 0:00 ` Robert I. Eachus
1996-10-16 0:00 ` Jon S Anthony
` (15 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-10-15 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (11 preceding siblings ...)
1996-10-15 0:00 ` Robert I. Eachus
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-16 0:00 ` Jon S Anthony
` (14 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (12 preceding siblings ...)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-16 0:00 ` Samuel T. Harris
` (13 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (13 preceding siblings ...)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-16 0:00 ` Samuel T. Harris
1996-10-16 0:00 ` Jon S Anthony
` (12 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Samuel T. Harris @ 1996-10-16 0:00 UTC (permalink / raw)
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!"
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (14 preceding siblings ...)
1996-10-16 0:00 ` Samuel T. Harris
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-18 0:00 ` Keith Thompson
1996-10-16 0:00 ` Jon S Anthony
` (11 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-18 0:00 ` Keith Thompson
0 siblings, 0 replies; 250+ messages in thread
From: Keith Thompson @ 1996-10-18 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (15 preceding siblings ...)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert Dewar
1996-10-16 0:00 ` Jon S Anthony
` (10 subsequent siblings)
27 siblings, 2 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-17 0:00 ` Robert Dewar
1996-10-17 0:00 ` Robert Dewar
1 sibling, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-16 0:00 ` Jon S Anthony
1996-10-17 0:00 ` Robert Dewar
@ 1996-10-17 0:00 ` Robert Dewar
1 sibling, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-10-17 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (16 preceding siblings ...)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-16 0:00 ` Jon S Anthony
1996-10-18 0:00 ` Jon S Anthony
` (9 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (17 preceding siblings ...)
1996-10-16 0:00 ` Jon S Anthony
@ 1996-10-18 0:00 ` Jon S Anthony
1996-10-18 0:00 ` Jon S Anthony
` (8 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (18 preceding siblings ...)
1996-10-18 0:00 ` Jon S Anthony
@ 1996-10-18 0:00 ` Jon S Anthony
1996-10-18 0:00 ` Jon S Anthony
` (7 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (19 preceding siblings ...)
1996-10-18 0:00 ` Jon S Anthony
@ 1996-10-18 0:00 ` Jon S Anthony
1996-10-29 0:00 ` Kenneth Almquist
` (6 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (20 preceding siblings ...)
1996-10-18 0:00 ` Jon S Anthony
@ 1996-10-29 0:00 ` Kenneth Almquist
1996-10-29 0:00 ` Robert Dewar
1996-10-29 0:00 ` Jon S Anthony
` (5 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: Kenneth Almquist @ 1996-10-29 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-29 0:00 ` Kenneth Almquist
@ 1996-10-29 0:00 ` Robert Dewar
1996-10-31 0:00 ` Kenneth Almquist
0 siblings, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-10-29 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-29 0:00 ` Robert Dewar
@ 1996-10-31 0:00 ` Kenneth Almquist
0 siblings, 0 replies; 250+ messages in thread
From: Kenneth Almquist @ 1996-10-31 0:00 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (21 preceding siblings ...)
1996-10-29 0:00 ` Kenneth Almquist
@ 1996-10-29 0:00 ` Jon S Anthony
1996-10-29 0:00 ` Robert I. Eachus
` (4 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-29 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (22 preceding siblings ...)
1996-10-29 0:00 ` Jon S Anthony
@ 1996-10-29 0:00 ` Robert I. Eachus
1996-10-30 0:00 ` Stephen Leake
` (3 subsequent siblings)
27 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-10-29 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (23 preceding siblings ...)
1996-10-29 0:00 ` Robert I. Eachus
@ 1996-10-30 0:00 ` Stephen Leake
1996-10-31 0:00 ` Lars Farm
1996-10-31 0:00 ` Kenneth Almquist
` (2 subsequent siblings)
27 siblings, 1 reply; 250+ messages in thread
From: Stephen Leake @ 1996-10-30 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-30 0:00 ` Stephen Leake
@ 1996-10-31 0:00 ` Lars Farm
0 siblings, 0 replies; 250+ messages in thread
From: Lars Farm @ 1996-10-31 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (24 preceding siblings ...)
1996-10-30 0:00 ` Stephen Leake
@ 1996-10-31 0:00 ` Kenneth Almquist
1996-10-31 0:00 ` Jon S Anthony
1996-11-01 0:00 ` Robert I. Eachus
27 siblings, 0 replies; 250+ messages in thread
From: Kenneth Almquist @ 1996-10-31 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (25 preceding siblings ...)
1996-10-31 0:00 ` Kenneth Almquist
@ 1996-10-31 0:00 ` Jon S Anthony
1996-11-01 0:00 ` Robert I. Eachus
27 siblings, 0 replies; 250+ messages in thread
From: Jon S Anthony @ 1996-10-31 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-10-10 0:00 ` Once again, Ada absent from DoD SBIR solicitation Mitch Gart
` (26 preceding siblings ...)
1996-10-31 0:00 ` Jon S Anthony
@ 1996-11-01 0:00 ` Robert I. Eachus
1996-11-01 0:00 ` Robert A Duff
` (3 more replies)
27 siblings, 4 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-01 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-01 0:00 ` Robert I. Eachus
@ 1996-11-01 0:00 ` Robert A Duff
[not found] ` <55gkch$gg6@fozzie.sun3.iaf.nl>
1996-11-02 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Robert Dewar
` (2 subsequent siblings)
3 siblings, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-01 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-01 0:00 ` Robert I. Eachus
1996-11-01 0:00 ` Robert A Duff
@ 1996-11-02 0:00 ` Robert Dewar
1996-11-04 0:00 ` Robert I. Eachus
1996-11-06 0:00 ` Robert I. Eachus
3 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-01 0:00 ` Robert I. Eachus
1996-11-01 0:00 ` Robert A Duff
1996-11-02 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Robert Dewar
@ 1996-11-04 0:00 ` Robert I. Eachus
1996-11-05 0:00 ` Larry Kilgallen
1996-11-14 0:00 ` Robert Dewar
1996-11-06 0:00 ` Robert I. Eachus
3 siblings, 2 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-04 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-04 0:00 ` Robert I. Eachus
@ 1996-11-05 0:00 ` Larry Kilgallen
1996-11-14 0:00 ` Robert Dewar
1 sibling, 0 replies; 250+ messages in thread
From: Larry Kilgallen @ 1996-11-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-04 0:00 ` Robert I. Eachus
1996-11-05 0:00 ` Larry Kilgallen
@ 1996-11-14 0:00 ` Robert Dewar
1996-11-16 0:00 ` Robert A Duff
1996-11-16 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Geert Bosch
1 sibling, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-14 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-14 0:00 ` Robert Dewar
@ 1996-11-16 0:00 ` Robert A Duff
1996-11-16 0:00 ` Robert Dewar
1996-11-16 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Geert Bosch
1 sibling, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-16 0:00 ` Robert A Duff
@ 1996-11-16 0:00 ` Robert Dewar
1996-11-17 0:00 ` Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Robert A Duff
1996-11-20 0:00 ` Jon S Anthony
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-16 0:00 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-16 0:00 ` Robert Dewar
@ 1996-11-17 0:00 ` Robert A Duff
1996-11-18 0:00 ` Robert Dewar
` (2 more replies)
1996-11-20 0:00 ` Jon S Anthony
1 sibling, 3 replies; 250+ messages in thread
From: Robert A Duff @ 1996-11-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-17 0:00 ` Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Robert A Duff
@ 1996-11-18 0:00 ` Robert Dewar
1996-11-19 0:00 ` Joel VanLaven
1996-11-19 0:00 ` Robert A Duff
1996-11-21 0:00 ` Robert I. Eachus
1996-11-25 0:00 ` Robert I. Eachus
2 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-18 0:00 ` Robert Dewar
@ 1996-11-19 0:00 ` Joel VanLaven
1996-11-23 0:00 ` Robert Dewar
1996-11-19 0:00 ` Robert A Duff
1 sibling, 1 reply; 250+ messages in thread
From: Joel VanLaven @ 1996-11-19 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-19 0:00 ` Joel VanLaven
@ 1996-11-23 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-23 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-18 0:00 ` Robert Dewar
1996-11-19 0:00 ` Joel VanLaven
@ 1996-11-19 0:00 ` Robert A Duff
1996-11-23 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-19 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-19 0:00 ` Robert A Duff
@ 1996-11-23 0:00 ` Robert Dewar
1996-11-24 0:00 ` Robert A Duff
1996-11-25 0:00 ` Norman H. Cohen
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-23 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-23 0:00 ` Robert Dewar
@ 1996-11-24 0:00 ` Robert A Duff
1996-11-25 0:00 ` Norman H. Cohen
1 sibling, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-11-24 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-23 0:00 ` Robert Dewar
1996-11-24 0:00 ` Robert A Duff
@ 1996-11-25 0:00 ` Norman H. Cohen
1996-11-27 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Norman H. Cohen @ 1996-11-25 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-25 0:00 ` Norman H. Cohen
@ 1996-11-27 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-27 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-17 0:00 ` Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Robert A Duff
1996-11-18 0:00 ` Robert Dewar
@ 1996-11-21 0:00 ` Robert I. Eachus
1996-11-24 0:00 ` Robert Dewar
1996-11-25 0:00 ` Robert I. Eachus
2 siblings, 1 reply; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-21 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-21 0:00 ` Robert I. Eachus
@ 1996-11-24 0:00 ` Robert Dewar
1996-11-24 0:00 ` Fergus Henderson
1996-11-25 0:00 ` Kevin D. Heatwole
0 siblings, 2 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-24 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-24 0:00 ` Robert Dewar
@ 1996-11-24 0:00 ` Fergus Henderson
1996-11-24 0:00 ` Robert Dewar
1996-11-25 0:00 ` Kevin D. Heatwole
1 sibling, 1 reply; 250+ messages in thread
From: Fergus Henderson @ 1996-11-24 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-24 0:00 ` Fergus Henderson
@ 1996-11-24 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-24 0:00 UTC (permalink / raw)
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 :-)
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-24 0:00 ` Robert Dewar
1996-11-24 0:00 ` Fergus Henderson
@ 1996-11-25 0:00 ` Kevin D. Heatwole
1996-11-25 0:00 ` Robert A Duff
1996-11-26 0:00 ` Geert Bosch
1 sibling, 2 replies; 250+ messages in thread
From: Kevin D. Heatwole @ 1996-11-25 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-25 0:00 ` Kevin D. Heatwole
@ 1996-11-25 0:00 ` Robert A Duff
1996-11-26 0:00 ` Kevin D. Heatwole
1996-11-26 0:00 ` Geert Bosch
1 sibling, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-25 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-25 0:00 ` Robert A Duff
@ 1996-11-26 0:00 ` Kevin D. Heatwole
1996-11-26 0:00 ` Robert A Duff
0 siblings, 1 reply; 250+ messages in thread
From: Kevin D. Heatwole @ 1996-11-26 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-26 0:00 ` Kevin D. Heatwole
@ 1996-11-26 0:00 ` Robert A Duff
1996-11-26 0:00 ` Larry Kilgallen
` (2 more replies)
0 siblings, 3 replies; 250+ messages in thread
From: Robert A Duff @ 1996-11-26 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-26 0:00 ` Robert A Duff
@ 1996-11-26 0:00 ` Larry Kilgallen
1996-11-27 0:00 ` Norman H. Cohen
1996-11-27 0:00 ` Robert Dewar
2 siblings, 0 replies; 250+ messages in thread
From: Larry Kilgallen @ 1996-11-26 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-26 0:00 ` Robert A Duff
1996-11-26 0:00 ` Larry Kilgallen
@ 1996-11-27 0:00 ` Norman H. Cohen
1996-11-29 0:00 ` Fergus Henderson
1996-11-29 0:00 ` Robert A Duff
1996-11-27 0:00 ` Robert Dewar
2 siblings, 2 replies; 250+ messages in thread
From: Norman H. Cohen @ 1996-11-27 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-27 0:00 ` Norman H. Cohen
@ 1996-11-29 0:00 ` Fergus Henderson
1996-11-29 0:00 ` Robert A Duff
1 sibling, 0 replies; 250+ messages in thread
From: Fergus Henderson @ 1996-11-29 0:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-27 0:00 ` Norman H. Cohen
1996-11-29 0:00 ` Fergus Henderson
@ 1996-11-29 0:00 ` Robert A Duff
1 sibling, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-11-29 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-26 0:00 ` Robert A Duff
1996-11-26 0:00 ` Larry Kilgallen
1996-11-27 0:00 ` Norman H. Cohen
@ 1996-11-27 0:00 ` Robert Dewar
2 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-27 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-25 0:00 ` Kevin D. Heatwole
1996-11-25 0:00 ` Robert A Duff
@ 1996-11-26 0:00 ` Geert Bosch
1996-11-26 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Geert Bosch @ 1996-11-26 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-26 0:00 ` Geert Bosch
@ 1996-11-26 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-26 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-17 0:00 ` Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Robert A Duff
1996-11-18 0:00 ` Robert Dewar
1996-11-21 0:00 ` Robert I. Eachus
@ 1996-11-25 0:00 ` Robert I. Eachus
2 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-25 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-16 0:00 ` Robert Dewar
1996-11-17 0:00 ` Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Robert A Duff
@ 1996-11-20 0:00 ` Jon S Anthony
1996-11-24 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Jon S Anthony @ 1996-11-20 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))
1996-11-20 0:00 ` Jon S Anthony
@ 1996-11-24 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-24 0:00 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-14 0:00 ` Robert Dewar
1996-11-16 0:00 ` Robert A Duff
@ 1996-11-16 0:00 ` Geert Bosch
1996-11-17 0:00 ` Robert Dewar
1 sibling, 1 reply; 250+ messages in thread
From: Geert Bosch @ 1996-11-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-16 0:00 ` Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Geert Bosch
@ 1996-11-17 0:00 ` Robert Dewar
1996-11-17 0:00 ` Robert A Duff
` (2 more replies)
0 siblings, 3 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-17 0:00 ` Robert Dewar
@ 1996-11-17 0:00 ` Robert A Duff
1996-11-18 0:00 ` Robert Dewar
1996-11-18 0:00 ` Geert Bosch
1996-11-18 0:00 ` Norman H. Cohen
2 siblings, 1 reply; 250+ messages in thread
From: Robert A Duff @ 1996-11-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-17 0:00 ` Robert A Duff
@ 1996-11-18 0:00 ` Robert Dewar
1996-11-19 0:00 ` Robert A Duff
0 siblings, 1 reply; 250+ messages in thread
From: Robert Dewar @ 1996-11-18 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-18 0:00 ` Robert Dewar
@ 1996-11-19 0:00 ` Robert A Duff
0 siblings, 0 replies; 250+ messages in thread
From: Robert A Duff @ 1996-11-19 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-17 0:00 ` Robert Dewar
1996-11-17 0:00 ` Robert A Duff
@ 1996-11-18 0:00 ` Geert Bosch
1996-11-22 0:00 ` Robert Dewar
1996-11-18 0:00 ` Norman H. Cohen
2 siblings, 1 reply; 250+ messages in thread
From: Geert Bosch @ 1996-11-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 250+ messages in thread* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-18 0:00 ` Geert Bosch
@ 1996-11-22 0:00 ` Robert Dewar
0 siblings, 0 replies; 250+ messages in thread
From: Robert Dewar @ 1996-11-22 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-17 0:00 ` Robert Dewar
1996-11-17 0:00 ` Robert A Duff
1996-11-18 0:00 ` Geert Bosch
@ 1996-11-18 0:00 ` Norman H. Cohen
2 siblings, 0 replies; 250+ messages in thread
From: Norman H. Cohen @ 1996-11-18 0:00 UTC (permalink / raw)
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...
|
+-----------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 250+ messages in thread
* Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)
1996-11-01 0:00 ` Robert I. Eachus
` (2 preceding siblings ...)
1996-11-04 0:00 ` Robert I. Eachus
@ 1996-11-06 0:00 ` Robert I. Eachus
3 siblings, 0 replies; 250+ messages in thread
From: Robert I. Eachus @ 1996-11-06 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 250+ messages in thread