* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
@ 1996-09-04 0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-09-06 0:00 ` Robert I. Eachus
0 siblings, 1 reply; 21+ messages in thread
From: Marin David Condic, 407.796.8997, M/S 731-93 @ 1996-09-04 0:00 UTC (permalink / raw)
++ robin <rav@GOANNA.CS.RMIT.EDU.AU> writes:
> >> ---Not really, when people have to ask how to do
> >> a square root [in Ada].
>
> > No serious Ada programmer has to ask such a question.
>
>---In Fortran, BASIC, Pascal, Algol, PL/I, you just
>use it [SQRT]. Nothing special needed.
>
I don't speak PL/I. Is the name of the function for computing a
square root named SQRT, sqrt (case sensitive), SQT, SQUARE_ROOT,
etc.? And what parameter(s) does it take? Real? Double Precision?
Integer? Complex? All of the above? Are they passed by value, or
do I have to get a pointer to the parameters? And what's the
calling syntax, anyway? Some version of assignment from a function
or a procedure with an input and an output parameter? Is the SQRT
function a "language primitive" or does it live in the PL/I
equivalent of a #include file? And when you get the PL/I manual
out, is it emblazoned in bold-faced, 72 point type on Page 1 that
the function is called <whatever> and is used in <whatever>
manner? Boy, this PL/I language must _REALLY SUCK_ because it's
not intuitively obvious to even the most casual observer how to
compute a square root and I'm obviously a victim of bad language
design - not simply too stoopit to R.T.F.M.
In *ANY* language, you can whine about the syntax of this or that
feature being "less convenient" than in some other language. I'll
bet some Apl programmers think that PL/I _SUCKS_ because the
commands are so bleeding long in comparison to what they're used
to? I'll bet there are Basic programmers who hate that you
actually have to declare variables in PL/I (I presume) instead of
simply making them up as you go along? And the fact that you have
to R.T.F.M. before you can use PL/I (or any language) is hardly a
sign of bad language design.
Get over it! Find something *real* to criticize about Ada95.
MDC
Marin David Condic, Senior Computer Engineer ATT: 407.796.8997
M/S 731-96 Technet: 796.8997
Pratt & Whitney, GESP Fax: 407.796.4669
P.O. Box 109600 Internet: CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM
===============================================================================
"That which belongs to another."
-- Diogenes, when asked what wine he liked to drink.
===============================================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-04 0:00 Ada versus PL/I (was: Re: Ariane 5 - not an exception?) Marin David Condic, 407.796.8997, M/S 731-93
@ 1996-09-06 0:00 ` Robert I. Eachus
0 siblings, 0 replies; 21+ messages in thread
From: Robert I. Eachus @ 1996-09-06 0:00 UTC (permalink / raw)
In article <96090415425634@psavax.pwfl.com> "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:
> I'll bet some Apl programmers think that PL/I _SUCKS_ because the
> commands are so bleeding long in comparison to what they're used
> to?
No, real APL programmers complain because primitive operations
like outer products and incomplete beta functions aren't provided. ;-)
I've actually thought about creating an Ada package whch provides
the "missing" functionality. The outer products are the pain. To
implement them by providing generics is possible, but you have to have
a generic formal type which has a first discriminant of number of
dimensions, and a second of scalar element type...
The field where APL is the best programming language available is
limited. But in that domain, nothing else comes close.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
@ 1996-09-05 0:00 Marin David Condic, 407.796.8997, M/S 731-93
0 siblings, 0 replies; 21+ messages in thread
From: Marin David Condic, 407.796.8997, M/S 731-93 @ 1996-09-05 0:00 UTC (permalink / raw)
"J. Kanze" <kanze@GABI-SOFT.FR> writes:
>> ---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
>> use it [SQRT]. Nothing special needed.
>
>This isn't true for C (and thus Turbo C), of course. You have to
>include math.h. While it is a built in in older lanugages like Fortran
>or Basic, most modern languages will require a declaration for the
>function somewhere. (I'm tempted to say that a language that doesn't
>require a declaration for a function is somewhat deficient, but SQRT is
>a special case.)
>
Well here's a point that ought to be considered before deciding if
SQRT should be intrinsic or declared somewhere:
Ada was (and still is) intended to serve the needs of embedded
programming. (Yes! yes! yes! You can *still* use it to print
paychecks and it works just fine!) In embedded systems, you are
frequently limited in the amount of memory you have available and
so you don't like to drag along lots of extra functions &
procedures which will never be called. I've built or seen *LOTS* of
embedded software which *NEVER* does any arithmetic more
complicated than +, -, * and /. Hence you'd like to exclude things
like SQRT, LOG, SIN, etc. as well as any other code that might be
"intrinsic" in some other language. Making those routines live in
a "with'ed" package has got to make this job a lot easier.
I'm not really up on the latest "Linker" theory, but I'd be
willing to bet that it is a lot simpler to never include an unused
math package than it is to get a linker to find unused "intrinsic"
functions built into the RTK and remove them as "dead code".
Perhaps someone out there a little bit smarter than me can shed
some light on it? Is it theoretically possible for a linker to
find *all* unused code and eliminate it? Are most language
compiler/linker combinations in use today going through
appropriate gyrations to do this? (A plausible argument for not
building packages with a bazillion functions in them?)
MDC
Marin David Condic, Senior Computer Engineer ATT: 407.796.8997
M/S 731-96 Technet: 796.8997
Pratt & Whitney, GESP Fax: 407.796.4669
P.O. Box 109600 Internet: CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM
===============================================================================
"Thanks to the Interstate Highway System, it is now possible
to travel across the country from coast to coast without
seeing anything."
-- Charles Kuralt
===============================================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
@ 1996-09-04 0:00 Marin David Condic, 407.796.8997, M/S 731-93
0 siblings, 0 replies; 21+ messages in thread
From: Marin David Condic, 407.796.8997, M/S 731-93 @ 1996-09-04 0:00 UTC (permalink / raw)
++ robin <rav@GOANNA.CS.RMIT.EDU.AU> writes:
> >> > On the other hand, I would rather see people using PL/I for
> >> > a serious project than C. And I have heard there is an effo
> >> > to release an Object-oriented version of PL/I in the near
> >> > future. That might actually make PL/I a viable alternative
> >> > to C++.
> >>
> >> ---It already is.
>
> > Not unless if does not explicitly support object-oriented
> > programming. And OOP kludges do not count.
>
>---we'll have to agree to disagree on that.
>
If by this you mean that PL/I is alread a viable alternative to
C++, you may be right. If you mean that OOP can be done in PL/I
without the usual requisite encapsulation, polymorphism,
inheritance, and other popular buzzwords and that this makes PL/I
"object oriented" then there's a problem: By that standard, you
could call an assembly language "object oriented" - in which case
the term doesn't mean much.
Object Oriented Programming can be done in any language - this is
true. But that hardly makes PL/I (or Basic, or assembly language,
or whatever) a good, or even adequate choice in which to do so.
Heck! Even Ada83 was a pretty weak choice for OOP given that you
had to pull some pretty ugly stunts to get some of those buzzwords
to work as intended.
MDC
Marin David Condic, Senior Computer Engineer ATT: 407.796.8997
M/S 731-96 Technet: 796.8997
Pratt & Whitney, GESP Fax: 407.796.4669
P.O. Box 109600 Internet: CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM
===============================================================================
"That which belongs to another."
-- Diogenes, when asked what wine he liked to drink.
===============================================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Ariane 5 - not an exception?
@ 1996-07-25 0:00 Simon Bluck
1996-07-25 0:00 ` Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?) Kirk Beitz
0 siblings, 1 reply; 21+ messages in thread
From: Simon Bluck @ 1996-07-25 0:00 UTC (permalink / raw)
The Ariane 501 flight failure was due to the raising of an unexpected
Ada exception, which was handled by switching off the computer. The
report on this:
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
is clear and hard-hitting: it will result in much improved software.
But does it get right to the bottom of the issues, and does the
software community appreciate that there are fundamental software
control problems which can directly give rise to such enormous
failures, in this particular case thankfully without loss of life?
It is most unfortunate, but must be accepted as true, that if the
Ariane software had been written in a less powerful language the
numeric overflow might have gone unnoticed, the computers would have
remained switched on, and the rocket would have continued its upward
flight.
Exceptions and assertions are both used, in Ada and C/C++, to detect
software/hardware anomalies. When one of these trips, it is
frequently very difficult for the designer to know how best to handle
the problem. To continue may result in corrupt data; to abort is
drastic but eliminates the possibility that further processing will
compound the problem.
The more checks you have, the more likely it is that one of them will
trip. If you can't think of good ways of handling these checks, the
end result, for the user, may well be very much worse than if the
check had never been performed in the first place.
Of the two handling options, neither is really acceptable. However,
there is a third option which ought to be considered: to continue but
mark the processed data as suspect.
I.e. each data item would have a truth value of 1.0 for good data,
0.0 for absolutely rotten data, utilising values in between if you
have some idea how good the data is. If you have numeric overflow,
you could set the data to the largest value available, and mark it as
suspect.
Any data further derived from suspect data must also be marked as
suspect.
Taking a probabilistic attitude to data would bring a lot of software
into the real world where failures can happen at all levels. Using
this approach would made complex mission-critical software like the
failing Ariane software much easier to understand and control. Data
would be processed along the same path regardless of whether it is
suspect or entirely valid. Only the end-users of the data would be
affected, and where duplication of systems provides redundancy, the
algorithm would be to switch to the backup on receiving suspect data,
and switch back to the main source if the backup was suspect. If
both sources are suspect, then take the least suspect source. This
is simple and you don't lose your vital input data. The data truth
values would be passed on from system to system along with the data.
You _never_ switch off a computer, but you may have cause to mark all
data emanating from it as suspect. Leave it up to the users of the
data to decide if they want to use it or not - they may have no
choice.
Along with the data truth attribute, you need a data type attribute.
This is tending to be relatively standard stuff now that objects are
around and need to know what kind of object they are. But adding a
data type field is still something that designers skimp on if not
supplied by the language, relying instead on implicit coding of type
information in the senders and receivers of data.
Lack of type information accounts for why the Ariane flight control
was able to interpret diagnostic data as attitude data, virtually
guaranteeing catastrophic failure. At least if attitude data had
been cut short it could have continued in a straight line.
Well, those are what I think are the important lessons to be learned.
The main reasons cited for Ariane 501's failure are typical human
ones which will be made again on the next big project. I.e.
inadequate testing, particularly of the complete system in its
(simulated) environment. Surprise, surprise, this turns out to be
too difficult and too costly to achieve thoroughly. And small system
mistakes which stress the adequate functioning of the system as a
whole (like thinking that the Ariane 4 alignment process didn't need
changing for Ariane 5). These will happen time and again, we're only
human. But with more realistic data processing the system as a whole
would stand a better chance of survival.
SimonB
[All my own opinions, of course.]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-07-25 0:00 Ariane 5 - not an exception? Simon Bluck
@ 1996-07-25 0:00 ` Kirk Beitz
1996-07-26 0:00 ` ++ robin
0 siblings, 1 reply; 21+ messages in thread
From: Kirk Beitz @ 1996-07-25 0:00 UTC (permalink / raw)
after reading the failure analysis, it seems a little irresponsible to even
hint about the failure of the rocket being based solely on the lack of proper
exception handling.
yes, it does seem clear that this was the final straw, and one of the heavy
hands from within the report comes down on the initial specification that
exceptions should be handled in such a manner. but there were several
choices made over the course of a long period of development that helped lead
to the situation.
a set of decisions were made along the way that led to this (i won't rehash
the whole report in detail from the web; it is fairly clear and
self-explanatory):
- the value which caused the exception was on a variable that was
not "guarded" or protected when converted from a generated float
input in the same fashion as a couple of similar variables
(partially in response to a "maximum workload target" for the
system.)
- the alignment software that generated the exception that went
unhandled was running when it didn't need to be after launch,
particularly on ariane 5 which had a different preparation
sequence and thus didn't require the hold to avoid the lengthy
reset of the launcher. the exception occurred within the
window after the software was necessary and before that
particular portion of the software was shutdown.
- the value that triggered the exception was out of range because
ariane 5 has higher horizontal velocity values than ariane 4;
the exception was on a value related to these horizontal vel vals.
- no testing was performed on the software for behavior in the
circumstances of count-down and flight-time sequence and the
trajectory of ariane 5. (the software did not contain this as
a measurement in its functional requirement. the two machines
that shutdown as a result of the unhandled exception were not
present but only simulated in pre-flight simulation testing.
one of the reasons given for this latter was that it was tested
based on use in ariane 4.)
i understand some of the points raised in the initial post, and the final
full report on the ariane 5 failure does address this: that system shutdown
following an unhandled exception was not a sound design decision in this
mission critical software.
it just seems to me that there are many more important lessons to be learned:
- the value of treating an raised or potentially raised exception within
a context that is as local as possible
- the value of understanding the nature of potential exceptions raised from
input
- the value of fully testing the software in the closest environment possible
to the real situation
- the value of making the software conform to the real requirements of a
mission, particularly in mission critical software
- the value of creating requirements specifications that properly fit the
mission at hand.
every single one of these probably should have been done during design;
*any* single one would have probably prevented the failure of ariane 501.
my point: the title of the original post (and much of its flavor) might to
suggest that the single problem that led to ariane 5 failing was the failure
to properly handle an exception. and that is *not* the lesson that should be
taken from this at all.
--kirk beitz
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-07-25 0:00 ` Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?) Kirk Beitz
@ 1996-07-26 0:00 ` ++ robin
1996-08-05 0:00 ` Darren C Davenport
0 siblings, 1 reply; 21+ messages in thread
From: ++ robin @ 1996-07-26 0:00 UTC (permalink / raw)
johndoe@zaphod.nosc.mil (Kirk Beitz) writes:
>after reading the failure analysis, it seems a little irresponsible to even
>hint about the failure of the rocket being based solely on the lack of proper
>exception handling.
---The failure of the project was, as the report stated, "ultimately"
due to the exception handler which shut down the system (in fact, both
the main system and the backup system, since they both experienced the
problem at the same time).
>yes, it does seem clear that this was the final straw, and one of the heavy
>hands from within the report comes down on the initial specification that
>exceptions should be handled in such a manner. but there were several
>choices made over the course of a long period of development that helped lead
>to the situation.
---The basic problem was due to 3 programming errors:
1. Converting from double precision foating-point to integer,
without a magnitude check. The conversion was programmed,
and lacked the check.
2. assuming that a 58-bit value was going to fit into
a 15-bit integer.
3. failure to include an error handler in the immediate routine
to trap trivial errors (such as fixed-point overlow), and
continuing.
The other failures were:
1. failure to simulate the effects of the error arising
(can be done easily with PL/I's SIGNAL statement).
2. failure to OBJECT to the stupid design of the error
handler, which was to shut down the system. An experienced
real-time programmer would have done this. And certainly,
a PL/I programmer would have NOT written an error-handler to shut
down the system in the event of a fixed-point overflow.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-07-26 0:00 ` ++ robin
@ 1996-08-05 0:00 ` Darren C Davenport
1996-08-06 0:00 ` U32872
0 siblings, 1 reply; 21+ messages in thread
From: Darren C Davenport @ 1996-08-05 0:00 UTC (permalink / raw)
++ robin (rav@goanna.cs.rmit.edu.au) wrote:
: 2. failure to OBJECT to the stupid design of the error
: handler, which was to shut down the system. An experienced
: real-time programmer would have done this. And certainly,
: a PL/I programmer would have NOT written an error-handler to shut
: down the system in the event of a fixed-point overflow.
I don't think any language endows a programmer with more intelligence.
Darren
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-05 0:00 ` Darren C Davenport
@ 1996-08-06 0:00 ` U32872
1996-08-07 0:00 ` Robert Dewar
0 siblings, 1 reply; 21+ messages in thread
From: U32872 @ 1996-08-06 0:00 UTC (permalink / raw)
In <4u538f$9q6@hacgate2.hac.com>, ddavenpo@redwood.hac.com (Darren C Davenport) writes:
>I don't think any language endows a programmer with more intelligence.
>
>Darren
That is certainly true but, I think, PL/1 attracts programmers who are already
well endowed with intelligence.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-06 0:00 ` U32872
@ 1996-08-07 0:00 ` Robert Dewar
1996-08-08 0:00 ` Pascal Martin @lone
0 siblings, 1 reply; 21+ messages in thread
From: Robert Dewar @ 1996-08-07 0:00 UTC (permalink / raw)
"That is certainly true but, I think, PL/1 attracts programmers who are already
well endowed with intelligence."
These daily PL/1 jokes are quite entertaining. An interesting reminder that
every language has an ardent band of supporters :-)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-07 0:00 ` Robert Dewar
@ 1996-08-08 0:00 ` Pascal Martin @lone
1996-08-09 0:00 ` Robert Dewar
0 siblings, 1 reply; 21+ messages in thread
From: Pascal Martin @lone @ 1996-08-08 0:00 UTC (permalink / raw)
In article <dewar.839392100@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>
>These daily PL/1 jokes are quite entertaining. An interesting reminder that
>every language has an ardent band of supporters :-)
>
It also remind us that languages don't want to die, even when it is long due.
Just consider COBOL :-)).
BTW, I am in search of an ALGOL68 compiler for Linux/PC. Anyone ?
Pascal.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-08 0:00 ` Pascal Martin @lone
@ 1996-08-09 0:00 ` Robert Dewar
1996-08-10 0:00 ` dwnoon
0 siblings, 1 reply; 21+ messages in thread
From: Robert Dewar @ 1996-08-09 0:00 UTC (permalink / raw)
Pascal Martin said
"It also remind us that languages don't want to die, even when it is long due.
Just consider COBOL :-))."
Actually in the case of COBOL, I think it is only with the advent of Ada 95
that there is a tenable alternative. The lack of fundamental facilities
(arithmetic and edited output) for high precision scaled decimal arithmetic
is a huge handicap in most other potential COBOL replacements.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-09 0:00 ` Robert Dewar
@ 1996-08-10 0:00 ` dwnoon
1996-08-15 0:00 ` Richard Riehle
0 siblings, 1 reply; 21+ messages in thread
From: dwnoon @ 1996-08-10 0:00 UTC (permalink / raw)
In <dewar.839592590@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>Actually in the case of COBOL, I think it is only with the advent of Ada 95
>that there is a tenable alternative. The lack of fundamental facilities
>(arithmetic and edited output) for high precision scaled decimal arithmetic
>is a huge handicap in most other potential COBOL replacements.
You posted this in a PL/I Newsgroup.
What do you think PL/I has been doing these past 30 years?
High-precision decimal arithmetic, with "all the bells and whistles" edit
patterns. It was always a better COBOL than COBOL, and far more
coherently structured.
Combined with being a better FORTRAN than FORTRAN and a better
Pascal than Pascal, I guess it's also a better Ada than Ada.
But only people who know all of these languages fluently are qualified
to comment.
Regards
Dave
<Team PL/I>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-10 0:00 ` dwnoon
@ 1996-08-15 0:00 ` Richard Riehle
1996-08-22 0:00 ` ++ robin
0 siblings, 1 reply; 21+ messages in thread
From: Richard Riehle @ 1996-08-15 0:00 UTC (permalink / raw)
On 10 Aug 1996 dwnoon@ibm.net wrote:
> Combined with being a better FORTRAN than FORTRAN and a better
> Pascal than Pascal, I guess it's also a better Ada than Ada.
I have programmed in PL/I (when it was still PL/1) as well as
Ada. I not the slightest doubt about the improvement of PL/I
over its predecessors. However, Ada is clearly superior to
PL/I as a software engineering language. It is even a better
programming language. I could go into detail about the model
for pointers, or the frailty of the DO WHILE construct, but
"He convinced against his will, is of the same opinion still."
On the other hand, I would rather see people using PL/I for
a serious project than C. And I have heard there is an effort
to release an Object-oriented version of PL/I in the near
future. That might actually make PL/I a viable alternative
to C++.
Richard Riehle
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)
1996-08-15 0:00 ` Richard Riehle
@ 1996-08-22 0:00 ` ++ robin
1996-08-31 0:00 ` Ada versus PL/I " Richard Riehle
0 siblings, 1 reply; 21+ messages in thread
From: ++ robin @ 1996-08-22 0:00 UTC (permalink / raw)
Richard Riehle <rriehle@nunic.nu.edu> writes:
>On 10 Aug 1996 dwnoon@ibm.net wrote:
>> Combined with being a better FORTRAN than FORTRAN and a better
>> Pascal than Pascal, I guess it's also a better Ada than Ada.
> I have programmed in PL/I (when it was still PL/1)
---PL/I has always been "PL/I". From the first
implementation to the introduction of the standard, to now.
>as well as
> Ada. I not the slightest doubt about the improvement of PL/I
> over its predecessors. However, Ada is clearly superior to
> PL/I as a software engineering language. It is even a better
> programming language.
---Not really, when people have to ask how to do
a square root [in Ada].
> I could go into detail about the model
> for pointers,
---You seem not to be aware of the DEFINE STRUCTURE
statement and the strongly-typed pointer facilities of
PL/I for Windows 95/NT, OS/2 and AIX.
> or the frailty of the DO WHILE construct, but
---DO WHILE is one of the structured constructs.
> On the other hand, I would rather see people using PL/I for
> a serious project than C. And I have heard there is an effort
> to release an Object-oriented version of PL/I in the near
> future. That might actually make PL/I a viable alternative
> to C++.
---It already is.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-08-22 0:00 ` ++ robin
@ 1996-08-31 0:00 ` Richard Riehle
1996-09-02 0:00 ` ++ robin
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Richard Riehle @ 1996-08-31 0:00 UTC (permalink / raw)
On 22 Aug 1996, ++ robin wrote:
> Richard Riehle wrote:
>
> > I have programmed in PL/I (when it was still PL/1)
> ---PL/I has always been "PL/I". From the first
> implementation to the introduction of the standard, to now.
Though I do not have them at hand, I recall some early IBM
documents which referred to PL/1 after it changed its name
from NPL.
>
> >as well as
> > Ada. I not the slightest doubt about the improvement of PL/I
> > over its predecessors. However, Ada is clearly superior to
> > PL/I as a software engineering language. It is even a better
> > programming language.
>
> ---Not really, when people have to ask how to do
> a square root [in Ada].
No serious Ada programmer has to ask such a question.
>
> > I could go into detail about the model
> > for pointers,
>
> ---You seem not to be aware of the DEFINE STRUCTURE
> statement and the strongly-typed pointer facilities of
> PL/I for Windows 95/NT, OS/2 and AIX.
I used PL/I long before Bill Gates heard of a computer. The
PL/I I remember supported some rather scary notions of type
flexibility, not appropriate for safety-critical systems. For
example, implicit type conversions, etc.
> > or the frailty of the DO WHILE construct, but
>
> ---DO WHILE is one of the structured constructs.
Yes it is. Too bad it also permits assignment to the loop
control variable, among other things.
> > On the other hand, I would rather see people using PL/I for
> > a serious project than C. And I have heard there is an effort
> > to release an Object-oriented version of PL/I in the near
> > future. That might actually make PL/I a viable alternative
> > to C++.
>
> ---It already is.
Not unless if does not explicitly support object-oriented
programming. And OOP kludges do not count.
Richard Riehle
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-08-31 0:00 ` Ada versus PL/I " Richard Riehle
@ 1996-09-02 0:00 ` ++ robin
1996-09-02 0:00 ` Richard A. O'Keefe
1996-09-03 0:00 ` J. Kanze
1996-09-03 0:00 ` ++ robin
2 siblings, 1 reply; 21+ messages in thread
From: ++ robin @ 1996-09-02 0:00 UTC (permalink / raw)
Richard Riehle <rriehle@nunic.nu.edu> writes:
>On 22 Aug 1996, ++ robin wrote:
>> Richard Riehle wrote:
>>
>> > I have programmed in PL/I (when it was still PL/1)
>> ---PL/I has always been "PL/I". From the first
>> implementation to the introduction of the standard, to now.
> Though I do not have them at hand, I recall some early IBM
> documents which referred to PL/1 after it changed its name
> from NPL.
---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I".
>> >as well as
>> > Ada. I not the slightest doubt about the improvement of PL/I
>> > over its predecessors. However, Ada is clearly superior to
>> > PL/I as a software engineering language. It is even a better
>> > programming language.
>>
>> ---Not really, when people have to ask how to do
>> a square root [in Ada].
> No serious Ada programmer has to ask such a question.
---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
use it [SQRT]. Nothing special needed.
>> ---You seem not to be aware of the DEFINE STRUCTURE
>> statement and the strongly-typed pointer facilities of
>> PL/I for Windows 95/NT, OS/2 and AIX.
> I used PL/I long before Bill Gates heard of a computer. The
> PL/I I remember supported some rather scary notions of type
> flexibility, not appropriate for safety-critical systems. For
> example, implicit type conversions, etc.
---There have been some changes since then . . .
>> > or the frailty of the DO WHILE construct, but
>>
>> ---DO WHILE is one of the structured constructs.
> Yes it is. Too bad it also permits assignment to the loop
> control variable, among other things.
A DO WHILE construct doesn't have a control variable.
>> > On the other hand, I would rather see people using PL/I for
>> > a serious project than C. And I have heard there is an effort
>> > to release an Object-oriented version of PL/I in the near
>> > future. That might actually make PL/I a viable alternative
>> > to C++.
>>
>> ---It already is.
> Not unless if does not explicitly support object-oriented
> programming. And OOP kludges do not count.
---we'll have to agree to disagree on that.
> Richard Riehle
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-02 0:00 ` ++ robin
@ 1996-09-02 0:00 ` Richard A. O'Keefe
1996-09-03 0:00 ` ++ robin
0 siblings, 1 reply; 21+ messages in thread
From: Richard A. O'Keefe @ 1996-09-02 0:00 UTC (permalink / raw)
rav@goanna.cs.rmit.edu.au (++ robin) writes:
> Richard Riehle <rriehle@nunic.nu.edu> writes:
> > Though I do not have them at hand, I recall some early IBM
> > documents which referred to PL/1 after it changed its name
> > from NPL.
>---The first edition c. 1966 of IBM's PL/I Reference Manual
>for the S/360 (PL/I-F compiler) called it "PL/I".
That may be true, but all Riehle claimed is that PL/I was once
called NPL.
He's right.
Years ago I read the proceedings of a SHARE conference
where they talked about the "New Programming Language".
There was some discussion of requirements and examples.
> > No serious Ada programmer has to ask such a question.
>---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
>use it [SQRT]. Nothing special needed.
With respect to Fortran, Basic, Pascal, Algol, and PL/I: true.
With respect to C (including Turbo C) and C++: totally false.
--
Australian citizen since 14 August 1996. *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-02 0:00 ` Richard A. O'Keefe
@ 1996-09-03 0:00 ` ++ robin
1996-09-03 0:00 ` Robb Nebbe
1996-09-17 0:00 ` shmuel
0 siblings, 2 replies; 21+ messages in thread
From: ++ robin @ 1996-09-03 0:00 UTC (permalink / raw)
ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>rav@goanna.cs.rmit.edu.au (++ robin) writes:
>> Richard Riehle <rriehle@nunic.nu.edu> writes:
>> > Though I do not have them at hand, I recall some early IBM
>> > documents which referred to PL/1 after it changed its name
>> > from NPL.
>>---The first edition c. 1966 of IBM's PL/I Reference Manual
>>for the S/360 (PL/I-F compiler) called it "PL/I".
>That may be true, but all Riehle claimed is that PL/I was once
>called NPL.
>He's right.
---No, that's not it at all. NPL is not in dispute. It's well
known that the early name of the language was NPL for New Programing
Language.
He was claiming that PL/I was called "PL/1" before it
was called PL/I. I pointed out that the first editions
of IBM's PL/I manuals called it "PL/I".
Richard's previous posting was:
______________________________________________________
> Richard Riehle wrote:
>
> > I have programmed in PL/I (when it was still PL/1)
> ---PL/I has always been "PL/I". From the first
> implementation to the introduction of the standard, to now.
Though I do not have them at hand, I recall some early IBM
documents which referred to PL/1 after it changed its name
from NPL.
____________________________________________________________
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-03 0:00 ` ++ robin
@ 1996-09-03 0:00 ` Robb Nebbe
1996-09-17 0:00 ` shmuel
1 sibling, 0 replies; 21+ messages in thread
From: Robb Nebbe @ 1996-09-03 0:00 UTC (permalink / raw)
> He was claiming that PL/I was called "PL/1" before it
> was called PL/I. I pointed out that the first editions
> of IBM's PL/I manuals called it "PL/I".
>
Isn't this from a Monty Python sketch?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-03 0:00 ` ++ robin
1996-09-03 0:00 ` Robb Nebbe
@ 1996-09-17 0:00 ` shmuel
1996-09-17 0:00 ` Jay McFadyen
1996-09-20 0:00 ` shmuel
1 sibling, 2 replies; 21+ messages in thread
From: shmuel @ 1996-09-17 0:00 UTC (permalink / raw)
In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++ robin) writes:
>
> He was claiming that PL/I was called "PL/1" before it
>was called PL/I. I pointed out that the first editions
>of IBM's PL/I manuals called it "PL/I".
>
Hardly relevant; that manual was printed well after the joint IBM/SHARE report. BTW, do you remember the truly
ugly name that IBM picked between NPL and MPPL?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-17 0:00 ` shmuel
@ 1996-09-17 0:00 ` Jay McFadyen
1996-09-18 0:00 ` John McCabe
1996-09-20 0:00 ` shmuel
1 sibling, 1 reply; 21+ messages in thread
From: Jay McFadyen @ 1996-09-17 0:00 UTC (permalink / raw)
In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++ robin) writes:
>
> He was claiming that PL/I was called "PL/1" before it
>was called PL/I. I pointed out that the first editions
>of IBM's PL/I manuals called it "PL/I".
>
There is an additional issue here. Not is there the question of what it was
called, but also how it was used. In the Multics environment - still
probably the best use of PL/I that anyone knows of - the PL/I compiler
was named pl1. Note, no slash, no uppercase (all Multics commands are lower
case and case sensitive) and no capital "I". As you can see, I am willing
to call the Language PL/I, but I wish I had a nickel for every time I
invoked the compiler:
pl1 fred.pl1
Can we call a halt this fruitless, silly argument?
--
Jay McFadyen
Development Tools and Infrastructure, C2PSD, Ford Motor Company
mcfadyen@cadcam.pd9.ford.com or JMCFADYE
(313) 33-73359
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-17 0:00 ` Jay McFadyen
@ 1996-09-18 0:00 ` John McCabe
0 siblings, 0 replies; 21+ messages in thread
From: John McCabe @ 1996-09-18 0:00 UTC (permalink / raw)
mcfadyen@cc0192.pd9.ford.com (Jay McFadyen) wrote:
>In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++ robin) writes:
>>
>> He was claiming that PL/I was called "PL/1" before it
>>was called PL/I. I pointed out that the first editions
>>of IBM's PL/I manuals called it "PL/I".
>>
>There is an additional issue here. Not is there the question of what it was
>called, but also how it was used. In the Multics environment - still
>probably the best use of PL/I that anyone knows of - the PL/I compiler
>was named pl1. Note, no slash, no uppercase (all Multics commands are lower
>case and case sensitive) and no capital "I". As you can see, I am willing
>to call the Language PL/I, but I wish I had a nickel for every time I
>invoked the compiler:
> pl1 fred.pl1
Does anyone really care?
>Can we call a halt this fruitless, silly argument?
I agree - this is a complete waste of time and my newsreader still
thinks it's relevant to Ariane 5!
Best Regards
John McCabe <john@assen.demon.co.uk>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-17 0:00 ` shmuel
1996-09-17 0:00 ` Jay McFadyen
@ 1996-09-20 0:00 ` shmuel
1 sibling, 0 replies; 21+ messages in thread
From: shmuel @ 1996-09-20 0:00 UTC (permalink / raw)
In <51l0rm$5lq@news1.mnsinc.com>, shmuel@os2bbs.com writes:
>Hardly relevant; that manual was printed well after the joint IBM/SHARE report. BTW, do you remember the truly
>ugly name that IBM picked between NPL and MPPL?
Whoops! I meant to say between NPL and PL/1 and to *not* say MPPL in the
message; my apologies for the "spoiler".
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-08-31 0:00 ` Ada versus PL/I " Richard Riehle
1996-09-02 0:00 ` ++ robin
@ 1996-09-03 0:00 ` J. Kanze
1996-09-07 0:00 ` Robert Dewar
1996-09-03 0:00 ` ++ robin
2 siblings, 1 reply; 21+ messages in thread
From: J. Kanze @ 1996-09-03 0:00 UTC (permalink / raw)
rav@goanna.cs.rmit.edu.au (++ robin) writes:
> ---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
> use it [SQRT]. Nothing special needed.
This isn't true for C (and thus Turbo C), of course. You have to
include math.h. While it is a built in in older lanugages like Fortran
or Basic, most modern languages will require a declaration for the
function somewhere. (I'm tempted to say that a language that doesn't
require a declaration for a function is somewhat deficient, but SQRT is
a special case.)
--
James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-03 0:00 ` J. Kanze
@ 1996-09-07 0:00 ` Robert Dewar
1996-09-09 0:00 ` ++ robin
0 siblings, 1 reply; 21+ messages in thread
From: Robert Dewar @ 1996-09-07 0:00 UTC (permalink / raw)
James Kanze says
"This isn't true for C (and thus Turbo C), of course. You have to
include math.h. While it is a built in in older lanugages like Fortran
or Basic, most modern languages will require a declaration for the
function somewhere. (I'm tempted to say that a language that doesn't
require a declaration for a function is somewhat deficient, but SQRT is
a special case.)"
I would definitely give in to this temptation (and say that a language
that does not require a definition for sqrt is deficient). In the absence
of a commitment to IEEE semantics, the definition of sqrt is not well
defined at the language level, and it is better that it come from a
designated library whose semantics are well defined (note that math.h
does not meet that requirement anyway, but certainly the math libraries
in Ada do meet this requirement).
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-07 0:00 ` Robert Dewar
@ 1996-09-09 0:00 ` ++ robin
1996-09-09 0:00 ` Robert Dewar
0 siblings, 1 reply; 21+ messages in thread
From: ++ robin @ 1996-09-09 0:00 UTC (permalink / raw)
dewar@cs.nyu.edu (Robert Dewar) writes:
>I would definitely give in to this temptation (and say that a language
>that does not require a definition for sqrt is deficient). In the absence
>of a commitment to IEEE semantics, the definition of sqrt is not well
>defined at the language level,
---I wonder what language(s) you are speaking about?
SQRT is well-defined in a range of languages.
It's sufficiently well-used that it be available
with a routine call, definitely facilitated
when it's part of the language, as indeed it should be.
>and it is better that it come from a
>designated library whose semantics are well defined (note that math.h
>does not meet that requirement anyway, but certainly the math libraries
>in Ada do meet this requirement).
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-09 0:00 ` ++ robin
@ 1996-09-09 0:00 ` Robert Dewar
1996-09-09 0:00 ` Ken Garlington
0 siblings, 1 reply; 21+ messages in thread
From: Robert Dewar @ 1996-09-09 0:00 UTC (permalink / raw)
Robin says
" SQRT is well-defined in a range of languages.
It's sufficiently well-used that it be available
with a routine call, definitely facilitated
when it's part of the language, as indeed it should be."
No, sorry that's plain wrong, in languages like Fortran, sqrt is not
well-defined at all, no more than addition (for float) is well defined
in such languages. The last I remember, PL/I did not have any properly
defined floating-point semantics either (the standard was too early
to be significantly influenced by either IEEE or LIAS). I suspect
Robin is not a floating-point expert!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-09 0:00 ` Robert Dewar
@ 1996-09-09 0:00 ` Ken Garlington
0 siblings, 0 replies; 21+ messages in thread
From: Ken Garlington @ 1996-09-09 0:00 UTC (permalink / raw)
Robert Dewar wrote:
>
> Robin says
>
> " SQRT is well-defined in a range of languages.
> It's sufficiently well-used that it be available
> with a routine call, definitely facilitated
> when it's part of the language, as indeed it should be."
>
> No, sorry that's plain wrong, in languages like Fortran, sqrt is not
> well-defined at all, no more than addition (for float) is well defined
> in such languages. The last I remember, PL/I did not have any properly
> defined floating-point semantics either (the standard was too early
> to be significantly influenced by either IEEE or LIAS). I suspect
> Robin is not a floating-point expert!
Keep in mind that Robin's definition of "well-defined" is probably more
along the lines of "it's listed in the index of my vendor's compiler
manual." I don't really see Robin using such terms with much precision
(pun intended).
--
LMTAS - "Our Brand Means Quality"
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-08-31 0:00 ` Ada versus PL/I " Richard Riehle
1996-09-02 0:00 ` ++ robin
1996-09-03 0:00 ` J. Kanze
@ 1996-09-03 0:00 ` ++ robin
1996-09-04 0:00 ` Robert Dewar
2 siblings, 1 reply; 21+ messages in thread
From: ++ robin @ 1996-09-03 0:00 UTC (permalink / raw)
Richard Riehle <rriehle@nunic.nu.edu> writes:
>On 22 Aug 1996, ++ robin wrote:
>> Richard Riehle wrote:
>>
>> > I have programmed in PL/I (when it was still PL/1)
>> ---PL/I has always been "PL/I". From the first
>> implementation to the introduction of the standard, to now.
> Though I do not have them at hand, I recall some early IBM
> documents which referred to PL/1 after it changed its name
> from NPL.
---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I".
>> >as well as
>> > Ada. I not the slightest doubt about the improvement of PL/I
>> > over its predecessors. However, Ada is clearly superior to
>> > PL/I as a software engineering language. It is even a better
>> > programming language.
>>
>> ---Not really, when people have to ask how to do
>> a square root [in Ada].
> No serious Ada programmer has to ask such a question.
---In Fortran, BASIC, Pascal, Algol, PL/I, you just
use it [SQRT]. Nothing special needed.
>> ---You seem not to be aware of the DEFINE STRUCTURE
>> statement and the strongly-typed pointer facilities of
>> PL/I for Windows 95/NT, OS/2 and AIX.
> I used PL/I long before Bill Gates heard of a computer. The
> PL/I I remember supported some rather scary notions of type
> flexibility, not appropriate for safety-critical systems. For
> example, implicit type conversions, etc.
---There have been some changes since then . . .
>> > or the frailty of the DO WHILE construct, but
>>
>> ---DO WHILE is one of the structured constructs.
> Yes it is. Too bad it also permits assignment to the loop
> control variable, among other things.
A DO WHILE construct doesn't have a control variable.
>> > On the other hand, I would rather see people using PL/I for
>> > a serious project than C. And I have heard there is an effort
>> > to release an Object-oriented version of PL/I in the near
>> > future. That might actually make PL/I a viable alternative
>> > to C++.
>>
>> ---It already is.
> Not unless if does not explicitly support object-oriented
> programming. And OOP kludges do not count.
---we'll have to agree to disagree on that.
> Richard Riehle
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-03 0:00 ` ++ robin
@ 1996-09-04 0:00 ` Robert Dewar
1996-09-07 0:00 ` ++ robin
0 siblings, 1 reply; 21+ messages in thread
From: Robert Dewar @ 1996-09-04 0:00 UTC (permalink / raw)
robin said
"---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I"."
Yes, of course that is true. But I assume you are aware of the NPL
papers that preceded this renaming of the language ...
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)
1996-09-04 0:00 ` Robert Dewar
@ 1996-09-07 0:00 ` ++ robin
0 siblings, 0 replies; 21+ messages in thread
From: ++ robin @ 1996-09-07 0:00 UTC (permalink / raw)
dewar@cs.nyu.edu (Robert Dewar) writes:
>robin said
>"---The first edition c. 1966 of IBM's PL/I Reference Manual
>for the S/360 (PL/I-F compiler) called it "PL/I"."
>Yes, of course that is true. But I assume you are aware of the NPL
>papers that preceded this renaming of the language ...
---Indeed. I said so in a previous post in this thread:
"NPL is not in dispute. It's well
known that the early name of the language was NPL for New Programing
Language."
It's also mentioned in the FAQ for comp.lang.pl1, in the history
section.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1996-09-20 0:00 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-09-04 0:00 Ada versus PL/I (was: Re: Ariane 5 - not an exception?) Marin David Condic, 407.796.8997, M/S 731-93
1996-09-06 0:00 ` Robert I. Eachus
-- strict thread matches above, loose matches on Subject: below --
1996-09-05 0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-09-04 0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-07-25 0:00 Ariane 5 - not an exception? Simon Bluck
1996-07-25 0:00 ` Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?) Kirk Beitz
1996-07-26 0:00 ` ++ robin
1996-08-05 0:00 ` Darren C Davenport
1996-08-06 0:00 ` U32872
1996-08-07 0:00 ` Robert Dewar
1996-08-08 0:00 ` Pascal Martin @lone
1996-08-09 0:00 ` Robert Dewar
1996-08-10 0:00 ` dwnoon
1996-08-15 0:00 ` Richard Riehle
1996-08-22 0:00 ` ++ robin
1996-08-31 0:00 ` Ada versus PL/I " Richard Riehle
1996-09-02 0:00 ` ++ robin
1996-09-02 0:00 ` Richard A. O'Keefe
1996-09-03 0:00 ` ++ robin
1996-09-03 0:00 ` Robb Nebbe
1996-09-17 0:00 ` shmuel
1996-09-17 0:00 ` Jay McFadyen
1996-09-18 0:00 ` John McCabe
1996-09-20 0:00 ` shmuel
1996-09-03 0:00 ` J. Kanze
1996-09-07 0:00 ` Robert Dewar
1996-09-09 0:00 ` ++ robin
1996-09-09 0:00 ` Robert Dewar
1996-09-09 0:00 ` Ken Garlington
1996-09-03 0:00 ` ++ robin
1996-09-04 0:00 ` Robert Dewar
1996-09-07 0:00 ` ++ robin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox