Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Mukesh Prasad]

Jon S Anthony wrote:
> > If I were to do heavy-duty graphics, compression, or image
> > processing involving implementation of state-of-the-art algorithms,
> > I would think very carefully before choosing Ada.
> 
> Why?

Well, I must admit that I haven't done anything
in Ada since 1983, and even then it was small programs.

The impression I recall mostly was that it was
highly typed (the word I reflexively thought of was
"regimented", but that is not an accurate
description for language features,) so many of the
things I would do in C/C++ in implemeting a graphics
or compression algorithm would be cumbersome
or difficult to do efficiently.

But assuming you are current in Ada, and
if you wish to dispel the notion that
such work is easier in C/C++, perhaps
you (or anybody else volunteering)
could post a brief segment on how one
would scan-convert a triangle and set up
the bits on a CGA (without taking advantage
of graphics libraries from vendors -- since
in C/C++ much of such work happens even before
vendor libraries are in place.)  Let us say
the platform is basic MSDOS (where C was
actually used heavily in 80s
for much low-level graphics work).

Actually, a rectangle would be a better
test of Ada's capabilities.  A triangle would
require you to pick up Breshenham or DDA or
something, which is not relevant to language
capabilities as such.  The CGA part, on the
other hand, is important -- since it shows
how Ada deals with abnormal programming
situations.  As long as everything
was done from first principles, I think 
this would provide a good test.

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Steve Jones - JON]

Mukesh Prasad <prasadm@polaroid.com> writes:

> 
> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
[snip]
> 
> Actually, a rectangle would be a better
> test of Ada's capabilities.  A triangle would
> require you to pick up Breshenham or DDA or
> something, which is not relevant to language
> capabilities as such.  The CGA part, on the
> other hand, is important -- since it shows
> how Ada deals with abnormal programming
> situations.  As long as everything
> was done from first principles, I think 
> this would provide a good test.

This seems a very strange test, for a very paticular enviroment, using
Ada OpenGL bindings I could do it quickly without having to worry about
any coding errors.  There is no implicit speed difference that I have
ever come across in any Ada work I have ever done, certainly the direct
to hardware things I have done or had to interface with have been much
cleaner when done in Ada as opposed to C.

In the area I work (ATC systems) the simulator I currently work on uses
Ada in its entirety, this involves X and PEX work and the displaying of
100s of real time tracks.  This certainly requires alot of processing and
it would not have been quicker in C, I know this as I previously implemented
a system in C using X and PEX.  The difference in timings between the
two systems have nothing to do with the language of implementation but
with the different design aims of those systems.  On basic test programs
C and Ada match each other pound for pound.




-- 
|Un Loup en France  | Wolverhampton Wanderers, out of darkness cometh Bully|
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song------------|
|----The above opinions rarely reflect my own and never my employers'------|
|Do not add me to mailing lists violations will be billed for time.        |

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Mukesh Prasad]

Steve Jones - JON wrote:

> Mukesh Prasad <prasadm@polaroid.com> writes:
>
> >
> > Jon S Anthony wrote:
> > > > If I were to do heavy-duty graphics, compression, or image
> > > > processing involving implementation of state-of-the-art
> algorithms,
> > > > I would think very carefully before choosing Ada.
> > >
> > > Why?
> [snip]
> >
> > Actually, a rectangle would be a better
> > test of Ada's capabilities.  A triangle would
> > require you to pick up Breshenham or DDA or
> > something, which is not relevant to language
> > capabilities as such.  The CGA part, on the
> > other hand, is important -- since it shows
> > how Ada deals with abnormal programming
> > situations.  As long as everything
> > was done from first principles, I think
> > this would provide a good test.
>
> This seems a very strange test, for a very paticular enviroment, using
>
> Ada OpenGL bindings I could do it quickly without having to worry
> about
> any coding errors.  There is no implicit speed difference that I have

The point was -- if I am implementing OpenGL and I want
to do it in Ada, what are the pluses and minuses?  OpenGL
can be implemented relatively straight-forwadly in C and
most probably was.  Should OpenGL developers have considered
Ada for this task?  (Notice the original comment was that
if you are doing this type of task, you should think carefully
before picking Ada.)

If the basic assumption is that all the "low level" work has been done
by third parties and all that's needed is some glue code, then
maybe the advantages of Ada stand up without needing
more considerations in the metric.  But in that case, perhaps
you need to show how Ada relates to Visual Basic -- C
or C++ would be wrong languages for this particular comparison.

Re: Is Ada as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <33A9338D.10BB@polaroid.com> Mukesh Prasad <prasadm@polaroid.com> writes:

> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
> 
> Well, I must admit that I haven't done anything
> in Ada since 1983, and even then it was small programs.

Well, that isn't even Ada anymore.  ISO Ada => Ada95 since Jan'95, as
implemented in Gnu Ada (GNAT), ObjectAda, etc.


> The impression I recall mostly was that it was
> highly typed (the word I reflexively thought of was
..
> things I would do in C/C++ in implemeting a graphics
> or compression algorithm would be cumbersome
> or difficult to do efficiently.

Nah.  You can actually adopt the same sloppy style if that is what you
want - right down to using the exact same "documentation" for C libs
like X/Motif/Win32/etc.


> you (or anybody else volunteering)
> could post a brief segment on how one
> would scan-convert a triangle and set up
> the bits on a CGA (without taking advantage
> of graphics libraries from vendors -- since

Why?  As I pointed out, it is simple to take advantage of such
graphics libs or any other for that matter.  I'm not a real UI type,
and have only written interfaces with Ada using X/Motif and Java AWT
(yes, you can directly write Java apps in Ada and use the various AWT
commercial packages out there).


> vendor libraries are in place.)  Let us say
> the platform is basic MSDOS (where C was

Other people have certainly done this.  There is even a free package
that comes with the DOS version of GNAT.  But, to be fair, I have
never really done any DOS programming.


Tell you what - since I'm not a real graphics whiz, it would be much
simpler if you were to post some code showing the so called "difficult
bits" so that it can be translated and shown to be about the same in
Ada.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Robert Dewar]

Mukesh says

<<But assuming you are current in Ada, and
if you wish to dispel the notion that
such work is easier in C/C++, perhaps
you (or anybody else volunteering)
could post a brief segment on how one
would scan-convert a triangle and set up
the bits on a CGA (without taking advantage
of graphics libraries from vendors -- since
in C/C++ much of such work happens even before
vendor libraries are in place.)  Let us say
the platform is basic MSDOS (where C was
actually used heavily in 80s
for much low-level graphics work).>>


This sounds trivially easy to do in Ada, so perhaps we are missing something.
To make sure we are not, post the C code that represents what you are trying
to do (or rather see how Ada could do).

If you have not used Ada since 1983, then that's a bit like saying you
have not voted since you were 18, since 1983 was the year that the Ada
language was standardized, and it took many years before really capable
compilers were available, so your experience provides no clue at all really.

Re: Is ADA as good for graphics programming as C? (WAS: Re:

[Jerry van Dijk]

I seems I didn't get the original posting...

>Mukesh says
>
><<But assuming you are current in Ada, and
>if you wish to dispel the notion that
>such work is easier in C/C++, perhaps
>you (or anybody else volunteering)
>could post a brief segment on how one
>would scan-convert a triangle and set up
>the bits on a CGA (without taking advantage
>of graphics libraries from vendors -- since
>in C/C++ much of such work happens even before
>vendor libraries are in place.)  Let us say
>the platform is basic MSDOS (where C was
>actually used heavily in 80s
>for much low-level graphics work).>>

As an example, take a look at the source code
of my VGA package (VGAPCK06) that comes with
EZ2LOAD (follow download pointers from
www.gnat.com).

This is a 640x480x16 graphics library for DOS
written exclusively in Ada (95) without any
use of any graphics library.

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Tim Harrison]

In article <33A9338D.10BB@polaroid.com>, prasadm@polaroid.com wrote:

> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
> 
> Well, I must admit that I haven't done anything
> in Ada since 1983, and even then it was small programs.

Enough said...Perhaps someone with Ada experience would be better suited
to answer this question.
-- Tim Harrison <harrison@acm.org>

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Kaz Kylheku]

In article <harrison-2106970827440001@apm1-87.realtime.net>,
Tim Harrison <harrison@acm.org> wrote:
>> Well, I must admit that I haven't done anything
>> in Ada since 1983, and even then it was small programs.
>
>Enough said...Perhaps someone with Ada experience would be better suited
>to answer this question.
>-- Tim Harrison <harrison@acm.org>

According to some of the material I have read via the adahome WWW page,
Ada allegedly had a ``bad'' reputation for poor performance due to an early
batch of compilers that didn't generate very good code. But that was fifteen
years ago.

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[John Goodsen]

Tim Harrison wrote:
> 
> In article <33A9338D.10BB@polaroid.com>, prasadm@polaroid.com wrote:
> 
> > Jon S Anthony wrote:
> > > > If I were to do heavy-duty graphics, compression, or image
> > > > processing involving implementation of state-of-the-art algorithms,
> > > > I would think very carefully before choosing Ada.
> > >
> > > Why?
> >
> > Well, I must admit that I haven't done anything
> > in Ada since 1983, and even then it was small programs.
> 
> Enough said...Perhaps someone with Ada experience would be better suited
> to answer this question.
> -- Tim Harrison <harrison@acm.org>

I would point you to probably one of the most powerful CAD products on
the market today, called CADWIN, developed by a Paris company,
Strategies.  
This product excels at high-performance 3D CAD applications and is
written
entirely in Ada.  Strategies chose Ada some 10 years ago as a strategic
decision and that choice now pays off.  From a performance and usability
standpoint, CADWIN wins hands down against older, archaic graphics
products
like AutoCAD, etc...  I know - I've compared them and watched many users
make the choice ... you haven't heard of CADWIN because they don't try
to compete in the highly competetive, pile-o-marketing-lies CAD market,
but rather, we use this technology to provide custom solutions for
clients,
with more work than we can already handle via referrals ...

Furthermore, the Ada Graphics Toolkit used to develop the CADWIN family
of products is also available for license to customers who need
powerful,
high performance graphics.  This toolkit, called Heragraph, also
provides
cross platform GUI components (lists, tabs, fields, comboboxes, etc.) so
you build your graphics application one time and it recompiles and runs
on other platforms (most Unix/X flavors, Windows, Windows95, WindowsNT).

Semd email directly to me if you would like more information on
Heragraph
and the CADWIN family of Ada based graphics products, in the U.S.
market.

-- 
John Goodsen              Saguaro Software, Inc. 
jgoodsen@saguarosoft.com     User Centered Object-Oriented Design
Specialists
http://www.saguarosoft.com   Object-Oriented S/W Architecture, Process,
Methods
602.706.1056                 Software Engineering Tools and Training

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Michael Levasseur]

Hello,

If by the term "Graphics" you mean making up commands to draw
Graphical Primitive objects on a screen, i.e. Lines, Points or
Polyline; then Ada is as good as C. Depending on the "Graphics
Engine" and the command language used. I've used Graphics Engines
the used GKS or PEX commands to control the Graphics Engine.

Most of the Graphics Engines I've used were written in C or Assembly
language inorder to gain the most speed that the hardware can supply.
I don't know of any Graphics Engines that were written in Ada.
This is probably due to the fact that EVEN DoD companies, usually
buy a commercial Graphical Engine rather that creating their own.

If by "Graphics" you are refering to "Graphical User Interface",
then I've seen numerous very good GUIs that were written in Ada.
It's not quite as easy to write a GUI in Ada 83 as it is to
write the same GUI in C++. The Ada GUI though will probably be
smaller in code size than the C++ GUI.

My choices on the three would be:

Graphical Engine Code written in C for maintainability and speed.

Graphical Application written in Ada 83 or Ada 95 for maintainability,
reliability, and to keep my customers happy (DoD).

GUI written in C++ for easy of developing. 
(As long as my Code Size creap doesn't kill me :-) )

This is all just my $0.02.....

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Chris Brand]

Michael Levasseur wrote:
> 
[snip]
> 
> Most of the Graphics Engines I've used were written in C or Assembly
> language inorder to gain the most speed that the hardware can supply.
> I don't know of any Graphics Engines that were written in Ada.
> This is probably due to the fact that EVEN DoD companies, usually
> buy a commercial Graphical Engine rather that creating their own.
> 
[snip]

One project I worked on briefly considered an implementation of Xwindows
in Ada (by a French company, IIRC). We never got as far as evaluating
it, though, so I can't comment on the speed.

It's also possible that it was just the client software, not the X
server itself. I can't remember.

-- 
Chris
Stating my own opinions, not those of my company.

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <33B16CBB.417A@gdesystems.com>, Michael Levasseur
<levass@gdesystems.com> wrote:


>My choices on the three would be:
>
>Graphical Engine Code written in C for maintainability and speed.
>
>Graphical Application written in Ada 83 or Ada 95 for maintainability,
>reliability, and to keep my customers happy (DoD).
>
>GUI written in C++ for easy of developing. 
>(As long as my Code Size creap doesn't kill me :-) )

I'm curious: on what basis would you consider C superior to Ada for
"maintainability and speed"?  What about Ada do you think is responsible
for its being not as fast as C?  Have you benchmarked some code in order to
make a comparison?

It is my understanding that because of Cs aggressive use of type-casting,
optimizations are actually more difficult to make than in Ada, where more
semantic information is given to the compiler (because of the richness of
its type system), thus allowing better optimization than is possible for C.

In Ada, the type system is merely a tool, and of course the programmer can
use it or not use it as is his desire; most _choose_ to turn on  strong
typing, though certainly that isn't required by the language.  It would be
very simple to just use the numeric types that come predefined in Ada, thus
allowing you to do the same sort of loosely-typed programming that one does
in C.

And I've fallen into the little trap there of assuming the stronger typing
is somehow less efficient.  Yes,  there are checks to make sure that I
don't dereference an item beyond the end of an array, for example, but for
the most part programmers feel these checks are beneficial, and are quite
happy about not being able to clobber memory accidently.

Note too that these range checks occur only when the compiler is unable to
determine that the range of the index object lies within the range of the
array index subtype.  When the index object is more strongly typed, this
gives the compiler the information it needs to turn array index checks off! 
Thus the idea that strong typing is less efficient is largely a myth.

And even then, in spite of a strongly-typed infrastructure, the Ada
programmer has an escape hatch called Unchecked_Conversion, to allow him
the freedom to convert any kind of type into any other kind, with the same
semantics as in C using type casts.

That C is more maintainable than Ada: again, on what basis?  Better
maintainability would imply that one can more easily understand the code,
by being able to focus on a small part at a time.  This a made possible by
Ada (and other languages) by providing a facility to create
programmer-defined abstractions, a facility largely missing in C (when
compared to other langauges).

So I'm confused by the argument that C is "faster" and "more maintainable"
than Ada.  Perhaps you would care to eludicate your reasons for believing
so.  Do you have a (small) code example in C that demonstrates why you feel
C is superior to Ada for writing a graphical engine?  Perhaps we could then
come up with an equivalent Ada example to show that Ada is not any less
efficient or less maintainable.  We might even be able to show that the Ada
example is faster, and more  
maintainable.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Donovan Baarda]

On Wed, 02 Jul 1997 21:42:31 -0800, Matthew Heaney <mheaney@ni.net> wrote:
>In article <33B16CBB.417A@gdesystems.com>, Michael Levasseur
><levass@gdesystems.com> wrote:
>
>
>>My choices on the three would be:
>>
>>Graphical Engine Code written in C for maintainability and speed.
>>
[snip]
>I'm curious: on what basis would you consider C superior to Ada for
>"maintainability and speed"?  What about Ada do you think is responsible
>for its being not as fast as C?  Have you benchmarked some code in order to
>make a comparison?
>
>It is my understanding that because of Cs aggressive use of type-casting,
>optimizations are actually more difficult to make than in Ada, where more
>semantic information is given to the compiler (because of the richness of
>its type system), thus allowing better optimization than is possible for C.
>
True. It is not just C's loose typing that makes it hard to optimize.
However, Ada is not such an easy language to optimize either.

[snip]
>That C is more maintainable than Ada: again, on what basis?  Better
>maintainability would imply that one can more easily understand the code,
>by being able to focus on a small part at a time.  This a made possible by
>Ada (and other languages) by providing a facility to create
>programmer-defined abstractions, a facility largely missing in C (when
>compared to other langauges).
>
I would probably agree that Ada is slightly more readable than C, and
definitly more mantainable. Readability and mantainability are IMHO not
the same thing. Readability is how easy it is to understand a program from
the source code. Mantainability is how easy it is to safely modify and
update a program during its life time.

>So I'm confused by the argument that C is "faster" and "more maintainable"
>than Ada.  Perhaps you would care to eludicate your reasons for believing
>so.  Do you have a (small) code example in C that demonstrates why you feel
>C is superior to Ada for writing a graphical engine?  Perhaps we could then
>come up with an equivalent Ada example to show that Ada is not any less
>efficient or less maintainable.  We might even be able to show that the Ada
>example is faster, and more  
>maintainable.
>

One of the things that can make Ada pretty inefficient is its pass by copy
mechanism. This means that 'in out' parameters have to be copied twice,
once on calling the procedure, and once again on return. I believe that it
can add extra overheads even for 'in' and 'out' parameters. For large
array parameters, this can be a killer.

The biggest problem with Ada compared to C, is the language is so complex.
The compiler writers have such a hard time just getting it to work that
they hardly get around to putting in optimisation. C is so small that
compiling it is easy, so more effort gets spent on optimization. 

I find it hard to believe that there are people who advocate Ada purely on
language merits. As a language, Ada sucks. It is probably better for
large projects than C, but then C is only a small step above assembler. In
just about any application you can think of, there are languages better
than Ada for the task.

Where Ada wins is in a combination of language merits, available 
compilers, supporting tools, and market penetration and demand (DOD).
Mainly $$$ for programmers :-)

ABO

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
abo@minkirri.apana.org.au (Donovan Baarda) wrote:

>One of the things that can make Ada pretty inefficient is its pass by copy
>mechanism. This means that 'in out' parameters have to be copied twice,
>once on calling the procedure, and once again on return. I believe that it
>can add extra overheads even for 'in' and 'out' parameters. For large
>array parameters, this can be a killer.

I think there's a misunderstanding here.  The language only mandates that
scalar types and access types be passed by copy, and the RM makes it clear
that the implementation is free to choose the mechanism (ie by reference)
for arrays and records.

>The biggest problem with Ada compared to C, is the language is so complex.
>The compiler writers have such a hard time just getting it to work that
>they hardly get around to putting in optimisation. C is so small that
>compiling it is easy, so more effort gets spent on optimization. 

I asked Robert Dewar, the principal developer responsible for GNAT (a free
Ada compiler that targets the gcc), a similar question about Ada's putative
complexity, and he responded that it wasn't the front end that was the hard
part, it was the back end.

So it would appear that at least one compiler vendor _does_ spend a lot of
time on optimization.

Also, at least a couple of other compiler vendors in the real-time market
have purchased Intermetric's Ada-Magic front end, so that they too can
spend their time on optimization, because they were able to buy the front
end off the shelf.

So again, I am confused by the comment that "compiler writers don't have
time to optimize the code," because there is ample evidence to the
contrary.  For which compiler writers specifically is this the case?

>I find it hard to believe that there are people who advocate Ada purely on
>language merits. As a language, Ada sucks. It is probably better for
>large projects than C, but then C is only a small step above assembler. In
>just about any application you can think of, there are languages better
>than Ada for the task.

Having programmed in C, Fortran, and Ada, my personal experience with Ada
has been quite positive.  In Ada, I am able to specify records for external
device I/O with a precisely defined layout, am able to write date
structures that I can use for any assignable type, have multi-threading
built into the language, etc, none of which I can do in C.

Don't get me wrong, I like C, but my experience is that Ada is a much more
expressive language, and I am much more productive as a result.

Perhaps you could provide an small code example of why you think that Ada
"sucks."  On what specific basis are you making this statement?

I ask because I am interested in learning more about C and other languages,
and so maybe there is some feature that these other languages have that Ada
doesn't have, that I am unaware of.

One application I can think of, and which I've had a some experience with,
is with real-time embedded applications.  I can say that having done it
both in C and Ada, my  preference is for Ada.

Another application is in safety-critical applications such as railroad
control and air traffic control, for which Ada is very highly suited.  In
fact, Ada is the language of choice for such systems.  (Visit the Ada home
page, <http://www.adahome.com> , for a list of many companies writing Ada
software for this domain.)

Another application is in information systems, for which Ada 95 and support
for the Information Systems annex would seem to be a very good language.

So again, I am confused about by the comment that "in any application you
can think of, there are better languages than Ada," because there are
applications for which Ada seems like the ideal choice.  Perhaps you can
list a few applications (AI?) for which there are better languages than
Ada, and provide specific reasons why you feel those other languages are
more suitable.

I wish to improve myself as a software engineer, and would like to learn
what you know about domains and applications for which Ada is not the
preferred language.

>Where Ada wins is in a combination of language merits, available 
>compilers, supporting tools, and market penetration and demand (DOD).
>Mainly $$$ for programmers :-)

I think the DOD would prefer you use Ada, but the DOD does not mandate
Ada's use.  As a contractor to the government, you are free to use whatever
language you feel is most appropriate (in the context of a systems
engineering analysis).  That there is no mandate for the use of Ada should
be interpreted to mean that Ada is a strong enough language that it doesn't
require a mandate.

Note too that the idea that Ada is "used for military applications only" is
a myth.  There many safety-critical systems - not military in any way -
written in Ada.  For example, the Boeing 777 is an all-Ada system.  

What language do you feel is better than Ada for safety-critical systems? 
Can you explain what features that language has that makes it so?  I would
like to learn what you know about safety-critical applications.

Also, I'm not sure what you mean by the comment that Ada is good because it
means "more money for programmers."  As a consultant, my fee is the same
for Ada, C, C++, Java, or whatever other language you ask me to use.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Donovan Baarda]

On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
>In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
>abo@minkirri.apana.org.au (Donovan Baarda) wrote:
>
whoa, I never intended to spark another language war, but I guess I asked
for it with that last paragraph :-)

>>One of the things that can make Ada pretty inefficient is its pass by copy
[snip]
>I think there's a misunderstanding here.  The language only mandates that
>scalar types and access types be passed by copy, and the RM makes it clear
>that the implementation is free to choose the mechanism (ie by reference)
>for arrays and records.
>
You are right. However, IMHO, this raises another hairy issue of the
language behavior being undefined since pass by copy and pass by reference
are semanticly different when parameter aliasing kicks in. For example;

procedure mung(R:in out matrix;A:in matrix) is
begin
  R(1,1):=R(1,1) + A(1,1);
  R(1,1):=R(1,1) + A(1,1);
end mung;

mung(M,M);

the book I've got says that programs that depend on the mechanism used are
erroneous. I would take a bloody good compiler to raise an error on a
program that does it.

>>The biggest problem with Ada compared to C, is the language is so complex.
>>The compiler writers have such a hard time just getting it to work that
>>they hardly get around to putting in optimisation. C is so small that
>>compiling it is easy, so more effort gets spent on optimization. 
>
>I asked Robert Dewar, the principal developer responsible for GNAT (a free
>Ada compiler that targets the gcc), a similar question about Ada's putative
>complexity, and he responded that it wasn't the front end that was the hard
>part, it was the back end.
>
But the language complexity doesn't just impact the front end, it also
makes the back end harder as well. In the case of GNAT, I belive they
started with the gcc backend, but had to modify it to meet Ada's specific
requirements. Many other compilers for more compact languages manage to
use the gcc back end unchanged.

>So it would appear that at least one compiler vendor _does_ spend a lot of
>time on optimization.
>
I'd be interested in knowing if the effort spent on the back end was
actualy improving optimization, or just trying to shoe-horn Ada into it.
The gcc back end already has pretty impressive optimisation.

>Also, at least a couple of other compiler vendors in the real-time market
>have purchased Intermetric's Ada-Magic front end, so that they too can
>spend their time on optimization, because they were able to buy the front
>end off the shelf.
>
what this also means is the front end is non-trivial, and they were better
off paying someone else a fortune for it than developing their own.

>So again, I am confused by the comment that "compiler writers don't have
>time to optimize the code," because there is ample evidence to the
>contrary.  For which compiler writers specifically is this the case?
>
What I should have said is; given equivalent time and resources, people
developing compilers for simpler languages will be able to put more work
into optimization than people developing Ada.

This statement clearly points to the fact that in the end, Ada will
probably do optimisation at least as good as any other language because
there is more time and resources being put into Ada compiler development.

>>I find it hard to believe that there are people who advocate Ada purely on
>>language merits. As a language, Ada sucks. It is probably better for
>>large projects than C, but then C is only a small step above assembler. In
>>just about any application you can think of, there are languages better
>>than Ada for the task.
>
>Having programmed in C, Fortran, and Ada, my personal experience with Ada
>has been quite positive.  In Ada, I am able to specify records for external
>device I/O with a precisely defined layout, am able to write date
>structures that I can use for any assignable type, have multi-threading
>built into the language, etc, none of which I can do in C.
>
>Don't get me wrong, I like C, but my experience is that Ada is a much more
>expressive language, and I am much more productive as a result.
>
>Perhaps you could provide an small code example of why you think that Ada
>"sucks."  On what specific basis are you making this statement?
>
Granted, Ada is better than C or Fortran for most applications. But there
are other languages that do it better. However, before I get into a
your-gol vs my-gol discussion, I should point out that it is easy to
invent a new language that is "better" than any other language for a
variety of reasons (especialy with the benefit of hindsite). It is much
harder, and more significant, to get that language into widespread use.

My original point was that arguing for your-gol based on language merits
alone is asking for trouble, because sure as chips there's going to be
some-gol out there that does it better. Particularly with a language as
old as Ada. I know Ada 95 is more recent, but bolting OO onto a procedural
language is always a compromise compared to starting with a clean slate.

A more important measure of a languages worth is how many people
understand and use it. Eskimo might be the best language to talk about
snow, but it's no good if there's no one to talk to (Appologys to any
Eskimo's out there). When you start to take this into account Ada starts 
to look pretty good.

Now back to the language war :-)

Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
does in 40 reserved words and 81 syntax rules. The only things missing
from modula-2 that are in Ada are generics, exceptions, and operator
overloading. However, it makes up for these deficiencys by having late
binding (through procedure variables) and a neater, cleaner, simpler 
syntax.

Unfortunatly, Modula-2 and Ada appeared on the scene about the same time.
With little difference between them bar complexity, the DOD mandate faded 
Modula-2 into obscurity. Dispite this, it did briefly have some favor in
Europe, and has been an inspiration for many other languages since. Most
languages that claim inheritance from Ada usualy owe more to Modula-2.

>I ask because I am interested in learning more about C and other languages,
>and so maybe there is some feature that these other languages have that Ada
>doesn't have, that I am unaware of.
>
Feature counting alone is not enough to gauge the technical merits. Too
many features can also compromise a language. The thing to aim for is the
minimum number of features required to cover the maximum number of
target applications most comfortably.

However, since you asked;
Garbage collection,
Multiple inheritance,
Design by Contract (inheritable assertions)
Parametric classes (OK, sort of the same as generics, but more formalised)
A complete inheritance heirachy

>One application I can think of, and which I've had a some experience with,
>is with real-time embedded applications.  I can say that having done it
>both in C and Ada, my  preference is for Ada.
>
my preference would be modula-2, but you'd probably have a hard time
convincing a customer to let you. C might still beat Ada on this one at
this stage because of a broader, cheaper, development tool base. When it
comes to hard real time, Assembler is still right up there.

>Another application is in safety-critical applications such as railroad
>control and air traffic control, for which Ada is very highly suited.  In
>fact, Ada is the language of choice for such systems.  (Visit the Ada home
>page, <http://www.adahome.com> , for a list of many companies writing Ada
>software for this domain.)
>

The Ada home page is hardly going to say Ada is a crock. Just like the
Eiffel pages aren't going to say Eiffel is. Here's another interesting
URL;

http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

[snip]
>
>I think the DOD would prefer you use Ada, but the DOD does not mandate
>Ada's use.  As a contractor to the government, you are free to use whatever
>language you feel is most appropriate (in the context of a systems
>engineering analysis).  That there is no mandate for the use of Ada should
>be interpreted to mean that Ada is a strong enough language that it doesn't
>require a mandate.
>
Ada has probably got enough momentum now to keep going without a DOD
mandate. However, now DOD has opened the door...

>Note too that the idea that Ada is "used for military applications only" is
>a myth.  There many safety-critical systems - not military in any way -
>written in Ada.  For example, the Boeing 777 is an all-Ada system.  
>
>What language do you feel is better than Ada for safety-critical systems? 
>Can you explain what features that language has that makes it so?  I would
>like to learn what you know about safety-critical applications.
>
Eiffel is IMHO a better choice for safety-critical applications without
excessive real time requirements. Design by contract obviously (and
measurably?) contributes significantly to program safety. Combining this
with a complete inheritanc heirachy of library classes with all the
contracts defined and inheritable has to make a huge difference.

OO and real time never were good bed-fellows, but they are getting more
comfortable together all the time. However, I would probably still go for
a procedural language becuase most control-systems theory is well
formalised to produce a procedural design.

>Also, I'm not sure what you mean by the comment that Ada is good because it
>means "more money for programmers."  As a consultant, my fee is the same
>for Ada, C, C++, Java, or whatever other language you ask me to use.
>
But I bet you get more Ada work because there is currently more demand for
Ada programmers per available programmer than for the other languages.

A good URL on languages and language comparisons is;

http://www.progsoc.uts.edu.au/~geldridg/cpp/

ABO

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Brian Rogoff]

On 4 Jul 1997, Donovan Baarda wrote:
> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
> whoa, I never intended to spark another language war, but I guess I asked
> for it with that last paragraph :-)

They're a fact of newsgroup existence, like the weather.

> But the language complexity doesn't just impact the front end, it also
> makes the back end harder as well. In the case of GNAT, I belive they
> started with the gcc backend, but had to modify it to meet Ada's specific
> requirements. Many other compilers for more compact languages manage to
> use the gcc back end unchanged.

No, the gcc backend is (was?) C specific, and other languages like Fortran
77 also require changes (in particular to handle aliased arrays). The
changes that make it into gcc are those which can do the greatest good for
the greatest number of languages.

> I'd be interested in knowing if the effort spent on the back end was
> actualy improving optimization, or just trying to shoe-horn Ada into it.
> The gcc back end already has pretty impressive optimisation.

I wonder how g77 users regard the level of optimization compared to 
a good Fortran compiler?

> Granted, Ada is better than C or Fortran for most applications. But there
> are other languages that do it better. However, before I get into a
> your-gol vs my-gol discussion, I should point out that it is easy to
> invent a new language that is "better" than any other language for a
> variety of reasons (especialy with the benefit of hindsite). It is much
> harder, and more significant, to get that language into widespread use.

I agree that Ada sucks, but I think all current computer languages suck in 
one way or another. Language choice is a minimization-of-suckfullness
problem with lots of variables. I think Ada 95 is reasonable solution for 
some problems for now. 

> Now back to the language war :-)
> 
> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> does in 40 reserved words and 81 syntax rules. The only things missing
> from modula-2 that are in Ada are generics, exceptions, and operator
> overloading. However, it makes up for these deficiencys by having late
> binding (through procedure variables) and a neater, cleaner, simpler 
> syntax.

The only things missing are GENERICS, EXCEPTIONS, and operator overloading?
Sorry, no generics makes a statically typed language lame. I can do without 
language minimalism myself. In fact I even wish Ada had user defined
operators like Algol 68! I agree that Ada would be better with Pascal style 
procedure parameters, but you can fake them with generics or (to be
compiler-specific) with Unrestricted_Access in GNAT.

> Feature counting alone is not enough to gauge the technical merits. Too
> many features can also compromise a language. The thing to aim for is the
> minimum number of features required to cover the maximum number of
> target applications most comfortably.

Its still not a well-posed problem, and intelligent people will disagree 
on what is "good". Lots of people think that OO is mostly BS and would 
prefer languages based on genericity, higher order functions, and such. 

The rest of this is an ad for Eiffel, which Donovan seems to like, but 
which, IMHO, also sucks.

-- Brian

PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
     not suck nearly as much as many popular languages :-) 
     

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Donovan Baarda]

On Fri, 4 Jul 1997 15:11:35 -0700, Brian Rogoff <bpr@shellx.best.com> wrote:
>On 4 Jul 1997, Donovan Baarda wrote:
>> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
[snip]
>No, the gcc backend is (was?) C specific, and other languages like Fortran
>77 also require changes (in particular to handle aliased arrays). The
>changes that make it into gcc are those which can do the greatest good for
>the greatest number of languages.
>
As a matter of interest, were the extensions added to the gcc backend for
Ada and Fortran merged and added to the gcc back end in general, or are
they mantained seperately as language specific backends?

>> The gcc back end already has pretty impressive optimisation.
>
>I wonder how g77 users regard the level of optimization compared to 
>a good Fortran compiler?
>
Me too.

>I agree that Ada sucks, but I think all current computer languages suck in 
>one way or another. Language choice is a minimization-of-suckfullness
>problem with lots of variables. I think Ada 95 is reasonable solution for 
>some problems for now. 
>
Agreed :-) 
I also believe in using the best tool for the job, which means choosing
the best language for the application. It is easy to fall into the trap
of thinking that all you need is one language. Perhaps the root of all my
complaints about Ada stem from the fact that it tried to be the one tool
for everything.

>The only things missing are GENERICS, EXCEPTIONS, and operator overloading?
>Sorry, no generics makes a statically typed language lame. I can do without 
>language minimalism myself. In fact I even wish Ada had user defined
>operators like Algol 68! I agree that Ada would be better with Pascal style 
>procedure parameters, but you can fake them with generics or (to be
>compiler-specific) with Unrestricted_Access in GNAT.
>
Procedure variables in a staticly typed language with no generics make it
less lame. However, generics are a neat feature. When I need them in
modula-2 I use the M4 macro-pre-processor to implement them (A trick I
learned at Uni that was being used with Pascal by one lecturer).

>> Feature counting alone is not enough to gauge the technical merits. Too
>> many features can also compromise a language. The thing to aim for is the
>> minimum number of features required to cover the maximum number of
>> target applications most comfortably.
>
>Its still not a well-posed problem, and intelligent people will disagree 
>on what is "good". Lots of people think that OO is mostly BS and would 
>prefer languages based on genericity, higher order functions, and such. 
>
I never said it was easy. Mostly it is very subjective, which is the main
reason why language flame wars are a waste of time. (Says I, who started
this one :-)

>The rest of this is an ad for Eiffel, which Donovan seems to like, but 
>which, IMHO, also sucks.
>
Actualy, it does look a bit like an ad for Eiffel, but I didn't mean it
quite that way. Eiffel also has its limitations, and is definitely not for
every application. However, IMHO, in most of the applications that people
advocate Ada for, Eiffel probably would be better. That's if you only take
into account language features, of course.

>-- Brian
>
>PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
>     not suck nearly as much as many popular languages :-) 
>     
Eiffel's biggest problem is it is even bigger than Ada. It also tries to
be the one tool for everything.

ABO

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Joachim Durchholz]

Donovan Baarda wrote:

> >PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
> >     not suck nearly as much as many popular languages :-)

Good :))

> Eiffel's biggest problem is it is even bigger than Ada.

This sounds strange to me. I feel Ada is more complicated than Eiffel.
And that's comparing the very first draft of Ada with current versions
of Eiffel!
Of course these are just feelings, and from a developer's viewpoint,
too. Under the hood, Eiffel may have more (and more complicated)
features than Ada. But the language design is so clear and
straightforward that most complexity doesn't show until you really want
to know about it.

> It also tries to
> be the one tool for everything.

Not really. It is intended for large systems, where correctness and
clear structure become really important. It is adequate for
intermediate-sized projects. It is not intended for real-time embedded
systems (though one could cramp Eiffel into that environment if one
really wanted to, but then you can do that with C++ or Lisp, too).

Besides, there's nothing wrong in trying to be the one tool for (mostly)
everything. One of the more important cost factor is retraining
programmers for new languages, new paradigms, new libraries, and new
tools. A language must try to be all things to everybody to have a
chance today.
This universality must not make the language bulky, of course. Your
perception of Eiffel's bulkiness may differ, of course, but I find the
language's unbulkiness striking.
Eiffel is even more universal than one might think. It is not just a
programming language, it is also useful for formal specifications in
analysis and design. (One OOAD method actually exploits this. It is BON,
by Kim Wald=E9n and Jean-Marc Nerson.)

Regards,
Joachim

[C and C++ discussion groups clipped.]
-- =

Please don't send unsolicited ads.

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Brian Rogoff]

On 7 Jul 1997, Donovan Baarda wrote:
> On Fri, 4 Jul 1997 15:11:35 -0700, Brian Rogoff <bpr@shellx.best.com> wrote:
> >No, the gcc backend is (was?) C specific, and other languages like Fortran
> >77 also require changes (in particular to handle aliased arrays). The
> >changes that make it into gcc are those which can do the greatest good for
> >the greatest number of languages.
> >
> As a matter of interest, were the extensions added to the gcc backend for
> Ada and Fortran merged and added to the gcc back end in general, or are
> they mantained seperately as language specific backends?

To the best of my knowledge, someone somewhere (MIT?) is modifying gcc/g77 
to handle Fortran better. Since Ada is very proper about who can point to 
what (aliased variables must be made explicit) the same optimizations will 
be applicable, while C and C++ require some sort of no-alias pragma for 
this.

> I also believe in using the best tool for the job, which means choosing
> the best language for the application. It is easy to fall into the trap
> of thinking that all you need is one language. Perhaps the root of all my
> complaints about Ada stem from the fact that it tried to be the one tool
> for everything.

I never thought of it this way. Coming from a scientific computing 
background, I'd say it is competing with C, C++, Fortran, and Eiffel but
not Matlab, Mathematica, Maple, or Macsyma (or Perl, or Icon, ...).

-- Brian

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Don Harrison]

Donovan Baarda wrote:

:Actualy, it does look a bit like an ad for Eiffel, but I didn't mean it
:quite that way.

That's okay - it deserves your praise.  :)

:Eiffel's biggest problem is it is even bigger than Ada. 

Not sure what you mean here. If you mean that it's complex, I would have to
disagree. In fact, as a minimalist language, it's very small and simple. Great
care has been taken in Eiffel's design to provide the minimal required 
mechanisms in the core language and to deliver advanced functionality through 
reuse, that is via libraries. This is the exact antithesis of Ada which is 
maximalist and complex. The Ada solution to adding functionality is adding 
(yet another) language feature. Consequently, Ada is about an order of magnitude
more complex than Eiffel due to the myriad interactions of language features.

According to Bertand Meyer, the explosion of language features in Ada-9X even
led to the resignation of Jean Ichbiah (one of Ada's original designers):

  "It is interesting to note that Jean Ichbiah, the creator of Ada, resigned
   publicly from the Ada95 reviewing group after trying in vain for several
   years to keep the extensions simple. His long resignation letter includes 
   comments such as: 'A massive increase in complexity will result from 9X
   [later renamed Ada95] adding one or more additional possibilities where 
   Ada now offers two. For example, 9X adds: [...] access parameters, to in, 
   out and in out; tagged types, to normal types, dipatched subprogram calls,
   to normal subprogram calls; use type clause to use package clauses; [Other
   examples skipped; overall 12 were included.] With 9X, the number of 
   interactions to consider is close to 60,000 since we have 3 or more 
   possibilities in each case (that is, 3**10).' "

[Source: Object-Oriented Software Construction 2nd ed.]
 
:It also tries to
:be the one tool for everything.

Being general purpose is fine, IMO.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <slrn5rq1gc.che.abo@minkirri.apana.org.au> abo@minkirri.apana.org.au (Donovan Baarda) writes:

> >Also, at least a couple of other compiler vendors in the real-time market
> >have purchased Intermetric's Ada-Magic front end, so that they too can
> >spend their time on optimization, because they were able to buy the front
> >end off the shelf.
> >
> what this also means is the front end is non-trivial, and they were better
> off paying someone else a fortune for it than developing their own.

What this _really_ means is that a) finally someone somewhere produced
a truely reusable _and_ non-trivial "component" and b) finally some
others have woke up to the fact that "rolling your own" really sucks.


> >So again, I am confused by the comment that "compiler writers don't have
> >time to optimize the code," because there is ample evidence to the
> >contrary.  For which compiler writers specifically is this the case?
> >
> What I should have said is; given equivalent time and resources, people
> developing compilers for simpler languages will be able to put more work
> into optimization than people developing Ada.

First, define "simpler".  On an obvious level Lisp is _vastly_ simpler
than C.  But doing a truely good implementation is a lot harder.
Second, I don't see the relevance.  The end result is what counts.
Given equal time and resources people building bicycles will be able
to optimize the hell out of them over the same level achieved for an
ICE.  So what?  This sort of mentality is the absolute _bane_ of
software.  The reason why it can't seem to build upon itself in any
way.  And the reason why most of it sucks.


> My original point was that arguing for your-gol based on language
> merits alone is asking for trouble, because sure as chips there's
> going to be some-gol out there that does it better.

"In a particular area or context", is the very important bit you left
out.  Of course, when this bit is added in, your point is not exactly
interesting.


> Particularly with a language as old as Ada. I know Ada 95 is more
> recent, but bolting OO onto a procedural language is always a
> compromise compared to starting with a clean slate.

Depends on.  In the case of Ada95, this was not much of a "compromise"
as it was simply extending a couple bits of what was already in Ada83.
What many people (for some reason) don't seem to realize is that Ada83
had the concept of "class", had inheritance and allowed for the
extension of _behavior_ in type derivations.  Adding in dynamic
binding and state extension was pretty natural.


> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> does in 40 reserved words and 81 syntax rules. The only things missing
> from modula-2 that are in Ada are generics, exceptions, and operator
> overloading.

And tasking and unconstrained types and ...  This is pretty silly.
No, it's _very_ silly.


> However, it makes up for these deficiencys by having late binding
> (through procedure variables) and a neater, cleaner, simpler syntax.

Not particularly.


> Europe, and has been an inspiration for many other languages
> since. Most languages that claim inheritance from Ada usualy owe
> more to Modula-2.

Neither is particularly innovative.  In fact, no computer language
really is.  But, the things in Ada that were "important" in "proof for
everyday useage" were not in M2: Tasking, Generics, Exceptions, and
(possibly) overloading.


> However, since you asked;
> Garbage collection,

Agreed (though it is recommended by the standard)

> Multiple inheritance,

Strongly disagree.  Actually, far more useful and expressive would be
multiple dispatch (but that is certainly a whole other kettle of
fish).

> Design by Contract (inheritable assertions)

More like class invariants.

> A complete inheritance heirachy

Presumably ala' Eiffel or some such.  Why?  Seems a big shrug.


> The Ada home page is hardly going to say Ada is a crock. Just like the
> Eiffel pages aren't going to say Eiffel is. Here's another interesting
> URL;
> 
> http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

No, this is not an interesting URL.  Unless you think simplistic
advertising passed off as "objectivity" is.  A large, and mostly
non-productive, "discussion" resulted from this, the last time it was
brought up.  Go back and check the results.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Donovan Baarda]

In article <JSA.97Jul4200941@alexandria.organon.com>, you wrote:
>
>> Particularly with a language as old as Ada. I know Ada 95 is more
>> recent, but bolting OO onto a procedural language is always a
>> compromise compared to starting with a clean slate.
>
>Depends on.  In the case of Ada95, this was not much of a "compromise"
>as it was simply extending a couple bits of what was already in Ada83.
>What many people (for some reason) don't seem to realize is that Ada83
>had the concept of "class", had inheritance and allowed for the
>extension of _behavior_ in type derivations.  Adding in dynamic
>binding and state extension was pretty natural.
>

Can you inherit from an INTEGER? Subtyping is not the same thing. Is there
a parent class to INTEGER and FLOAT that can be used by a class that
manipulates either?

>
>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
>> does in 40 reserved words and 81 syntax rules. The only things missing
>> from modula-2 that are in Ada are generics, exceptions, and operator
>> overloading.
>
>And tasking and unconstrained types and ...  This is pretty silly.
>No, it's _very_ silly.
>
Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
types, but if you mean unconstrained array types, modula-2 didn't have
them exactly but it did have unconstrained array parameters. However, I do
belive that being able to make a type out of them is a neat idea.

>
>Neither is particularly innovative.  In fact, no computer language
>really is.  But, the things in Ada that were "important" in "proof for
>everyday useage" were not in M2: Tasking, Generics, Exceptions, and
>(possibly) overloading.
>
Generics and Exceptions were a pretty important step. However, I don't
believe they were fully understood at the time Ada83 was implemented, and
there are now nicer implementations of these two concepts.

>> A complete inheritance heirachy
>
>Presumably ala' Eiffel or some such.  Why?  Seems a big shrug.
>
It makes a difference in OO because you can make something that
manipulates OBJECTs, and know that it can be fed anything because
everything is inherited from OBJECT. A complete heirachy of numeric types
is useful for the same reason.

ABO

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Canada Bass]

On 7 Jul 1997 05:07:43 GMT, abo@minkirri.apana.org.au (Donovan Baarda)
wrote:

snip:
>>
>>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
>>> does in 40 reserved words and 81 syntax rules. The only things missing
>>> from modula-2 that are in Ada are generics, exceptions, and operator
>>> overloading.
>>
>>And tasking and unconstrained types and ...  This is pretty silly.
>>No, it's _very_ silly.
>>
>Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
>types, but if you mean unconstrained array types, modula-2 didn't have
>them exactly but it did have unconstrained array parameters. However, I do
>belive that being able to make a type out of them is a neat idea.
>
snip:

I am unsure as to effect of this post, but does M2 have true
multi-tasking to which he was referring to? I know little of any other
language that has a standard multi-tasking function. :)

Canada Bass

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Dale Pontius]

In article <33c2aa99.20716474@news.visi.net>,
        cbass@visi.net.no_spam (Canada Bass) writes:
>
> I am unsure as to effect of this post, but does M2 have true
> multi-tasking to which he was referring to? I know little of any other
> language that has a standard multi-tasking function. :)
>
Modula2 has a fundamental capability of executing coroutines. It
has the ability to switch between coroutines, and to enter a
coroutine through an interrupt. The interrupt response routine
also understands interrupt masks. This is pretty much the minimal
set of primitives to implement multitasking

Dale Pontius
(NOT speaking for IBM)

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Martin Tom Brown]

In article <33c2aa99.20716474@news.visi.net>
           cbass@visi.net.no_spam "Canada Bass" writes:

> On 7 Jul 1997 05:07:43 GMT, abo@minkirri.apana.org.au (Donovan Baarda)
> wrote:
> 
> snip:
> >>
> >>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> >>> does in 40 reserved words and 81 syntax rules. The only things missing
> >>> from modula-2 that are in Ada are generics, exceptions, and operator
> >>> overloading.
> >>
> >>And tasking and unconstrained types and ...  This is pretty silly.
> >>No, it's _very_ silly.
> >>
> >Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
> >types, but if you mean unconstrained array types, modula-2 didn't have
> >them exactly but it did have unconstrained array parameters. However, I do
> >belive that being able to make a type out of them is a neat idea.
> >
> snip:
> 
> I am unsure as to effect of this post, but does M2 have true
> multi-tasking to which he was referring to? I know little of any other
> language that has a standard multi-tasking function. :)

The Modula 2 language standard PIM3 and above contains facilities for 
synchronisation by SIGNAL, cooperative multitasking by TRANSFER and 
interrupt handlers by IOTRANSFER. Modules can also have priority masks.
It is relatively easy to write a timeslice based scheduler in M2 and 
most of the compiler vendors source library files include one.

There is a newly published ISO standard with a complete formal language
specification for Modula2 now, with standardised libraries. Too late :(
It is a neat little language which still holds certain safety critical 
market niches in embedded instrument control and the like.

I still think it is an excellent minimallist language.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <slrn5s0ucv.fpc.abo@minkirri.apana.org.au>,
abo@minkirri.apana.org.au (Donovan Baarda) wrote:

>Can you inherit from an INTEGER? Subtyping is not the same thing. Is there
>a parent class to INTEGER and FLOAT that can be used by a class that
>manipulates either?

Wegner described contrasted "subtypes" and "subclasses."

A subtype has range semantics, in the sense that a subtype constrains the
range of values that may be designated by an object.

A subclass has template semantics, in the sense that a subclass constrains
the behavior of its parent.

But you can think of an object of a subclass as only being able to
designate fewer values, because it has more behavior constraints.

Ada has both specialization mechanisms.  However, "type extension" is not
available for numeric types such as Integer or Float, only subtype (range)
constraints.  So, numeric types such as Integer or Float are not related in
any kind of inheritence hierarchy (ie don't have a common superclass).

Different languages have made different choices with respect to whether all
types should be part of a common hierarchy.  That Eiffel did so, and Ada
did not, should not be construed as better, just different.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Nick Leaton]

Matthew Heaney wrote:

> Different languages have made different choices with respect to whether all
> types should be part of a common hierarchy.  That Eiffel did so, and Ada
> did not, should not be construed as better, just different.

I'm not sure about this. If you don't have a common hierarchy, then that
precludes you from using a common root. Now this is useful when we look
at container classes. It is particularly useful when you can constrain
the type that is store in a container to a particular type. 

By having a common hierarchy you are not limited from doing anything
that you can without one. However the reverse is not true. Therefore a
common heirarchy is the better solution.

-- 

Nick

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <33C4AF0E.339D@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:

>> Different languages have made different choices with respect to whether all
>> types should be part of a common hierarchy.  That Eiffel did so, and Ada
>> did not, should not be construed as better, just different.
>
>I'm not sure about this. If you don't have a common hierarchy, then that
>precludes you from using a common root. Now this is useful when we look
>at container classes. It is particularly useful when you can constrain
>the type that is store in a container to a particular type. 

I think there is confusion here between what one does versus how one does it.

In Ada, you can constrain the type you use to parameterize a container
class, it's just that the mechanism for doing so is different from Eiffel.

For example, I can parameterize a type with any assignable type:

generic
   type T is private;
package Containers_G is

   type Root_Container is abstract tagged private;
...

I can constrain the generic formal type so that it only allows integers:

generic
   type T is range <>;
package Containers_G is ...;

I can constrain the type to only integer types that derive from integer
type T (example *):

generic
   type NT is new T;
package Containers_G is ...;

I can constrain the type to any type with an addition operator:

generic
   type T is private;
   with function "+" (L, R : T) return T is <>;
package Containers_G is ...;

I can constrain the type so that it only takes tagged types (those that
have type extension):

generic
   type T is tagged private;
package Containers_G is ...;

I can constrain the type so that it only takes tagged types that derive
from a specific tagged type T (example **):

generic 
   type NT is new T with private;
package Containers_G is ...;

Examples (*) and (**) are examples of "constrained genericity," which is
exactly what you said would be really nice to have.  So you have it an
Eiffel AND Ada.

So what's the problem?   In Ada, you can constrain the type used to
parameterize another, without all types necessarily being related via a
hierarchy.  That Eiffel does it differently from Ada should be construed
only to mean that Eiffel does it differently from Ada, not better.

In Ada, you can even do mixin inheritance without using multiple
inheritance.  Imagine that!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Nick Leaton]

Matthew Heaney wrote:


> In Ada, you can even do mixin inheritance without using multiple
> inheritance.  Imagine that!

And you can use MI for it in Eiffel, without the problems of C++!

-- 

Nick

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Don Harrison]

Matthew Heaney wrote:

:In article <33C4AF0E.339D@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:
:
:>> Different languages have made different choices with respect to whether all
:>> types should be part of a common hierarchy.  That Eiffel did so, and Ada
:>> did not, should not be construed as better, just different.
:>
:>I'm not sure about this. If you don't have a common hierarchy, then that
:>precludes you from using a common root. Now this is useful when we look
:>at container classes. It is particularly useful when you can constrain
:>the type that is store in a container to a particular type. 
:
:I think there is confusion here between what one does versus how one does it.

I think what Nick means is that because Ada does not define Integer and Float 
as classes inheriting from a common ancestor class Numeric, they are less 
flexible than in Eiffel. In particular, you can't declare a generic Numeric 
container class and constrain *through inheritance* to store Integers or Floats. 
Consequently, you can't use a Numeric container polymorphically by substituting
an Integer or Float container. Also, you can't store both Floats and Integers 
in the same Numeric container. These things are simple and straightforward 
to do in Eiffel because INTEGER and REAL are both classes (as well as types)
inheriting from class NUMERIC. 

In Ada, there is something like a notional Numeric *type* having properties
like assignment and addition but because it is not a class (tagged type), it's
not extensible through inheritance. You may be able to extend using Ada's
*other* inheritance mechanism - derived types - but that doesn't allow 
polymorphism so you miss something compared with Eiffel.


:In Ada, you can constrain the type you use to parameterize a container
:class, it's just that the mechanism for doing so is different from Eiffel.

[examples of constrained numeric types unrelated by inheritance]

:I can constrain the type so that it only takes tagged types (those that
:have type extension):

[example of constrained *non-numeric* type related by inheritance]

:Examples (*) and (**) are examples of "constrained genericity," which is
:exactly what you said would be really nice to have.  So you have it an
:Eiffel AND Ada.

No, I think Nick meant constraining from a common ancestor *through 
inheritance* which is different from the examples you have given. We already 
know that both Ada and Eiffel support both constrained and unconstrained
genericity.

:In Ada, you can even do mixin inheritance without using multiple
:inheritance.  

Yes, through a round-about way using genericity. This is inelegant compared 
with multiple inheritance. However, it's simple compared to the obscure 
technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
I'm still trying to comprehend that one!
 
:Imagine that!

Imagine!


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:

>Yes, through a round-about way using genericity. This is inelegant compared 
>with multiple inheritance. However, it's simple compared to the obscure 
>technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
>I'm still trying to comprehend that one!

Be careful bandying about terms like "more elegant" and "less pure."  Those
are concepts invented by humans to convey an idea to another human.  Nature
doesn't care about what is more or less elegant, she only cares about what
works and what doesn't.

As system builders, especially as builders of software systems, we always
have to be concerned with keeping things simple.  The language designer
must balance expressiveness of the language against inclusion of yet more
features.

Does the putative "elegance" of the MI solution outweigh the language
complexity that would result had MI been included in Ada?  Doesn't
simplicity count for something?  Should one reject Ada out of hand, because
mixin inheritance in Ada using generics is "inelegant" compared to using
multiple inheritence in Eiffel?

Isn't it possible that there are other features of Ada, that allow some
things to be done more easily or more elegantly than in Eiffel?  Is the
mechanism used to implement mixin inheritance so important that those other
features aren't significant?

The multiple view technique is an admittedly difficult idiom to understand
- at first.  But once apprehended, it makes perfect sense, and isn't hard
to do.  You get multiple views for free, because it builds on existing
language mechanisms, and it very nearly gives you what you get in MI,
without requiring that MI be part of the language.

You may want to study my discussion of the Adapter pattern in the SIGAda
patterns WG archives, where I specifically discuss and give code examples
of the multiple views technique.

<http://www.acm.org/sigada>

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Brian Rogoff]

(C, C++ groups removed...)
On Tue, 15 Jul 1997, Matthew Heaney wrote:
> In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:
> >Yes, through a round-about way using genericity. This is inelegant compared 
> >with multiple inheritance. However, it's simple compared to the obscure 
> >technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
> >I'm still trying to comprehend that one!
> 
> Be careful bandying about terms like "more elegant" and "less pure."  Those
> are concepts invented by humans to convey an idea to another human.  Nature
> doesn't care about what is more or less elegant, she only cares about what
> works and what doesn't.

Most of us got it the first time: Eiffel way good, Ada way bad. I am
disgusted with myself for preferring Ada 95 to Eiffel, and I must be warped
because I  find the self referential structure of the MI in the Rationale
4.6.3 (http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p2-4.html#6 for 
those of you who want to see for yourselves) *beautiful*, and worth the 
small effort invested in comprehension.

Interestingly, the creators of BETA also decided to leave out MI as well. 
But I guess they must be poor designers too. There is only one true OOP 
way after all, and Don *knows* it.

And people who use SML must be the most barbarous of all, since they don't 
have "objects"! How can they do anything?

-- Brian

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Don Harrison]

Matt Heaney wrote:

:In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:
:
:>Yes, through a round-about way using genericity. This is inelegant compared 
:>with multiple inheritance. However, it's simple compared to the obscure 
:>technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
:>I'm still trying to comprehend that one!
:
:Be careful bandying about terms like "more elegant" and "less pure."  Those
:are concepts invented by humans to convey an idea to another human.  Nature
:doesn't care about what is more or less elegant, she only cares about what
:works and what doesn't.

Have to disagree here. Appreciation of elegance and purity are God-given
qualities which many either suppress or don't have much of in the first place.
Judging by God's handiwork, He possesses them in abundance. 

IMO, it's software users that don't care about elegance and purity but only 
inasmuch as it doesn't affect them. That is, they couldn't care less if 
software is inelegant under-the-covers so long as it works and is easy to use. 
Unfortunately, what's more likely is that it won't work and won't be easy to 
use if it's design is complex - a poor designer doesn't radically change the 
way they do things when they come to the GUI and complexity tends to compromise
reliability. 

:As system builders, especially as builders of software systems, we always
:have to be concerned with keeping things simple.  

I agree.

:The language designer
:must balance expressiveness of the language against inclusion of yet more
:features.

I tend to think there are good and bad ways of delivering functionality -
see below... 


:Does the putative "elegance" of the MI solution outweigh the language
:complexity that would result had MI been included in Ada?  Doesn't
:simplicity count for something?  

Yes, it counts for a lot. However, I think it's helpful to recognise the 
relative complexity engendered by the two primary means of delivering 
functionality - language mechanisms and libraries. The former increases 
overall complexity more than the latter because language features interact 
with each other *non-orthogonality* and libraries are *standalone*. Also, I 
think we need to distinguish between *actual* and *perceived* orthogonality. 
A naive user, for example, may perceive a language such as Ada to be more 
complex than it actually is simply because they don't know what is orthogonal 
and what isn't. 

As an example of the standalone complexity of libraries (strictly in Ada it's
optional language and libraries), Ada is not made more complex for a 
realtime user due to the existence of an Information Systems Annexe
because it's immediately obvious from the fact that it's optional that it 
doesn't concern them. The same can't be said of language mechanisms whose 
orthogonality is recognised more through use rather than immediate 
comprehension. Most humans can only grasp a handful of concepts at a time 
so it's asking too much of them to immediately comprehend which of a multitude
of language mechanisms are independent of each other. Obviously, the fewer 
there are, the less there is to learn and the quicker you will master the 
language.

I doubt anyone would disagree that Annexes are a good idea. Minimalist 
languages (such as Eiffel) take this principle further by placing as much 
functionality as possible in "Annexes" (called libraries in Eiffel). In this 
way, the basic functionality of the language is reused heavily to provide 
other functionality. The analogy on the back of "Eiffel The Language" (ETL) 
is very apt:

  "Eiffel has been called a 'RISC language'".

Some examples of this reuse which contrast with Ada are:

  - Implementation of basic types as classes.
  - Implementation of parts of the exception facilities as a class.
  - Implementation of various aspects of concurrency (timed interrupts, 
    coroutines etc.) as classes.

The more functionality you can implement in standalone libraries, the simpler
the language itself becomes. A rough measure of that complexity is language 
validity rules. Eiffel only has about 81 including SCOOP. How many does Ada95 
have? (I mean the number of distinct RM references which an Ada compiler can
spit out) I've roughly estimated about 2400 - I can't tell for sure because the 
Librarian has annexed my copy of the LRM. This difference translates fairly 
directly into how complex the language is perceived to be, especially to a 
beginner.


In the specific case of MI, I think it's such a useful modelling tool as to 
warrant its inclusion in the language itself if that will make it easier to use
(which I think it does).


:Should one reject Ada out of hand, because
:mixin inheritance in Ada using generics is "inelegant" compared to using
:multiple inheritence in Eiffel?

No, but it may mean that you're not able to model things as directly as you 
might otherwise.


:Isn't it possible that there are other features of Ada, that allow some
:things to be done more easily or more elegantly than in Eiffel?  

Sure. Low-level facilities may be one such area. But, IME, it's typically the 
other way round.

:Is the
:mechanism used to implement mixin inheritance so important that those other
:features aren't significant?

I think they're likely to be orthogonal wrt MI.


:The multiple view technique is an admittedly difficult idiom to understand
:- at first.  But once apprehended, it makes perfect sense, and isn't hard
:to do.  You get multiple views for free, because it builds on existing
:language mechanisms, and it very nearly gives you what you get in MI,
:without requiring that MI be part of the language.
:
:You may want to study my discussion of the Adapter pattern in the SIGAda
:patterns WG archives, where I specifically discuss and give code examples
:of the multiple views technique.
:
:<http://www.acm.org/sigada>

Thanks for the reference. If I get a chance, I'll take a look.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Matthew Heaney]

In article <EDEDB3.8rv@syd.csa.com.au>, donh@syd.csa.com.au wrote:

>:Be careful bandying about terms like "more elegant" and "less pure."  Those
>:are concepts invented by humans to convey an idea to another human.  Nature
>:doesn't care about what is more or less elegant, she only cares about what
>:works and what doesn't.
>
>Have to disagree here. Appreciation of elegance and purity are God-given
>qualities which many either suppress or don't have much of in the first place.
>Judging by God's handiwork, He possesses them in abundance. 

You've fallen into a common trap, Don.  You think that beauty and elegance
exist independent of human perception; this is, of course, incorrect.

Here's a quote for you, to provide an analogy:

"Complexity per se is not the culprit, of course; rather it is our human
limitations in dealing with complexity that cause the problem." - William
Wulf, quoted by Booch

There is no such thing as complexity, really.  Complexity is just a concept
- it's what is felt by a human, when he observes natural phenomena (or the
reaction of this human when he reviews software...).

When you speak of beauty and elegance, those terms have no meaning without
speaking of the human who thinks something is beautiful or the human that
perceives something to be elegant.  A thing is not beautiful all by itself
- it is beautiful only in the mind of a human.

Looking at it from a systems point of view, beauty and elegance are refered
to as "emergent properties," a thing that emerges because of the
interaction of parts.

So we can dispense with any mention of God, because he has nothing to do
with it.  Contrary to they're being handed over by God, "elegance" and
"purity" are simply concepts that emerge because of the structure of the
human brain.  If you take away the human, then of course you take away
elegance and purity to.

You even hint at this yourself, when you say "Judging by God's handiwork." 
It's a _human_ that does the judging; there being no judge, there can be no
elegant handiwork or pure handiwork - just handiwork.

In fact, the concept of God is an emergent property, which emerges as the
result of the interaction of a reflexive system aware of its own mortality,
and a strong, built-in propensity to maintain its own existance ("survival
instinct").  Take away the system, and of course you take away "God" too.

If these concepts are alien to you, then I suggest you study up on systems
thinking.  It'll make you a much better systems designer.  Here's a couple
of books to read

The Blind Watchmaker
Richard Dawkins
W.W.Norton
ISBN 0-393-30448-5

Dealing with Complexity
Robert Flood and Ewart Carson
Plenum Press
ISBN 0-306-44299-X

You may also want to take a gander at Capra's new book

The Web of Life
Fritjof Capra
Anchor Books (Doubleday)
0-385-47675-2


>IMO, it's software users that don't care about elegance and purity but only 
>inasmuch as it doesn't affect them. That is, they couldn't care less if 
>software is inelegant under-the-covers so long as it works and is easy to use. 
>Unfortunately, what's more likely is that it won't work and won't be easy to 
>use if it's design is complex - a poor designer doesn't radically change the 
>way they do things when they come to the GUI and complexity tends to compromise
>reliability. 

I think we're both in agreement here.

>:Should one reject Ada out of hand, because
>:mixin inheritance in Ada using generics is "inelegant" compared to using
>:multiple inheritence in Eiffel?
>
>No, but it may mean that you're not able to model things as directly as you 
>might otherwise.

Spoken like a true afficionado of inheritence!  Well, I have some more news
for you, Don.  Nature (interpret that to mean God, if that suits you) has
chosen aggregation as the essential means of systems construction.  Oh, by
the way, artificial ("man-made") systems are built using aggregation too! 
Imagine that!

In spite of what you may have heard, your dishwasher, your car, your watch,
and even you are constructed using aggregation.  Last time I checked,
neither my computer (my little Mac, bless it), nor my stereo, nor my
microwave oven were constructed using inheritence - not even (gasp!)
multiple inheritence.  Say it ain't so, Joe!

How is this even possible? the dear Eiffel reader must be wondering.

Oh, yes, I know the argument: Humans use classification to simplify things,
so we should use classification to build software, blah blah blah.  Well
here's the real scoop: humans use _abstraction_ to simplify their world. 
Humans view and build systems as multi-level, heirarchical structures,
using _aggregation_.  So why build software systems any differently?

In spite of the propaganda enunciated by certain computer scientists, real
software systems do get built without inheritence.  A lone voice in a
chaotic world, JP Rosen, says it clearly enough:

"Once again, composition will exhibit a lower complexity and a greater
security at the cost of ease of design.  For small-sized, quickly developed
projects, classification can be an efficient method.  But for large-scale,
long-lasting projects, composition is necessary to ensure control on the
overall complexity."  - JP Rosen, What Orientation Should Ada Objects
Take?, CACM, Nov 1992 (Vol 35, No 11)

If neither I nor Jean-Pierre can convince you of the efficacy of
aggregation over inheritence, then perhaps these authors can:

Hierarchically Organized Systems In Theory & Practice
Paul Weiss

Theory of Hierarchical, Multilevel Systems
Mesarovic, Macko, Takahara

Hierarchical Structures
Whyte, Wilson, and Wilson

Hierarchy Theory
Howard Pattee

And by all means read the chapter The Architecture of Complexity, in 

The Sciences of the Artificial 
Herbert Simon

which just came out in a brand spankin' new 3rd ed.

(Oh, Herb won a Nobel prize, by the way.)

And if that isn't enough, maybe the Gang of Four can put you over the edge:

"Favor object compostion over class inheritance." -- p. 20 of Design
Patterns, by Gamma et al


The argument that in Ada, "you can't model things as directly as you might
otherwise," is completely specious.  Just the opposite is true, in fact. 
Ada has a very rich type system, specifically designed to allow you to
"directly model" logical entities, and especially physical entities, as
would be necessary for its intended domain, embedded systems.

Let's consider a simple example, from Ada: Language and Methodology, by
Watt, Wichmann, and Findlay (the "famous" book in which Tony Hoare tepidly
endorses Ada in the Foreward).

Suppose we need to write a disk controller.  We manipulate the disk through
a disk control block, located at memory address (octal) 77430.

The block comprises 2 16 bit words: the function code and some status bits
are located in upper byte of the first word, and the disk address is the
second word, ie

type Function_Code is (Read, Write, Write_With_Check, Seek);

for Function_Code use
  (Read => 2#0000#,
   Write => 2#0010#,
   Write_With_Check => 2#0100#,
   Seek => 2#1000#);

for Function_Code'Size use 4;

type Disk_Control_Block is
   record
      Code : Function_Code;
      Write_Not_Permitted : Boolean;
      Disk_Busy : Boolean;
      Disk_Off_Line : Boolean;
      Disk_Address : Interfaces.Unsigned_16;
   end record;

for Disk_Control_Block use
   record
      Code                              at 0 range 0 .. 3;
      Write_Not_Permitted at 0 range 5 .. 5;
      Disk_Busy                    at 0 range 6 .. 6;
      Disk_Off_Line               at 0 range 7 .. 7;
      Disk_Address              at 2 range 0 .. 15;
   end record;

for Disk_Control_Block'Size 32;

Control_Block : Disk_Control_Block;
for Control_Block'Address use 8#77430#;

Now, what were you saying about not be able to model the problem directly?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Composition vs. Inheritance (was Re: Is ADA as good for graphics programming as C?)

[Robert I. Eachus]

    Matthew Heaney wrote an excellent post on why aggregation should
be favored over inheritance in most cases, ending with:

  > Now, what were you saying about not be able to model the problem directly?

  Amen.  For years I have been saying that the first lesson of Ada
style is to model the problem domain not the solution.  Ada has a rich
vocabulary for modelling the "real world". As we all know, the
requirements keep changing.  The problem space evolves too, but in
most cases, at a slower rate.

  In addition, code that models the problem space is much easier to reuse
within a domain--the problem space hasn't changed.  I have actually
had cases where out of a 50K SLOC program, the only thing not reused
on the next project was the 300 SLOC main program.

--

					Robert I. Eachus

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

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Nasser]

In article <mheaney-ya023680001707970007130001@news.ni.net>, mheaney@ni.net
says...
>
>Spoken like a true afficionado of inheritence!  Well, I have some more news
>for you, Don.  Nature (interpret that to mean God, if that suits you) has
>chosen aggregation as the essential means of systems construction.  

So, how does one explain what genetics tells us about DNA duplication
ftom parents to their children? How do you explain that green skinned people
produce green skinned people? and taller people most will produce taller
people? this is all nature at work, and each new creation of nature 
has inherited propertites of eariler generations.

offcourse, the human body is build by aggregation (eyes, ears, legs, arms,
etc.), but the poperty that those pieces have are mostly inherited.

As for aggreation vs. inheritence, for me, the most important thing is
to be to do software reuse as easily as possible, which methodology one 
chooses to drive towardes this, is just detailes. I think Ada is the best
language I have programmed with to enable code resuse.

I happend to think aggregation seems 'easier' to work with, but may be 
that becuase I have not done allot of inheritence. Also inheritence, 
by its nature, implies code coupling between the base and the children. 
If one chances the base, then ALL of its children behaviours will change, 
while in aggregation, one "client" can choose not to use the new 
changed/modified aggregate component, while the rest of the clients who 
used the common component can 'upgrade' to the new one.  
  

Nasser

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Brian Rogoff]

On 19 Jul 1997, it was written:
> In article mheaney@ni.net says...
> >Spoken like a true afficionado of inheritence!  Well, I have some more news
> >for you, Don.  Nature (interpret that to mean God, if that suits you) has
> >chosen aggregation as the essential means of systems construction.  
> 
> So, how does one explain what genetics tells us about DNA duplication
> ftom parents to their children? How do you explain that green skinned people
> produce green skinned people? and taller people most will produce taller
> people? this is all nature at work, and each new creation of nature 
> has inherited propertites of eariler generations.

I think it is a gross error of reasoning to suggest that OO inheritance is 
somehow "natural" because we use the same word "inheritance" to describe 
the process of the passing of genetic material from a biological entity to 
its offspring. I suppose poorly designed inheritance hierarchies must also 
be natural, since in nature we have examples of snippets of genetic
material being transferred by virus. Reasoning by analogy is particularly
suspect here.

> I happend to think aggregation seems 'easier' to work with, but may be 
> that becuase I have not done allot of inheritence. Also inheritence, 
> by its nature, implies code coupling between the base and the children. 
> If one chances the base, then ALL of its children behaviours will change, 
> while in aggregation, one "client" can choose not to use the new 
> changed/modified aggregate component, while the rest of the clients who 
> used the common component can 'upgrade' to the new one.  

This part is right. I tend to think that inheritance and dynamic dispatch 
should be used sparingly. GUI programming is one place it seems to be 
effective. Interpreters can also benefit in some places from an "OO" 
approach. But aggregation is really ubiquitous.

IMO, one of the big mistakes of modern CS theory is the emphasis on
"better" type systems (OO type systems are the rage) over  better control
structures. Hopefully some of us Ada programmers will get a chance to
experiment with way more powerful control structures when GNAT 3.10 comes
out and some SNOBOL 4 capabilities become available.

-- Brian
 

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <Pine.SGI.3.95.970720113201.28934B-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> > So, how does one explain what genetics tells us about DNA duplication
> > ftom parents to their children? How do you explain that green skinned peo
...
> I think it is a gross error of reasoning to suggest that OO inheritance is 
> somehow "natural" because we use the same word "inheritance" to describe 
> the process of the passing of genetic material from a biological entity to 
> its offspring.

Correct.  The problem is in using the same term "inheritance" in
settings where its meaning (and hence the semantics of the model type
involved) are completely different.  I discussed this a little in an
attendant post...

> This part is right. I tend to think that inheritance and dynamic dispatch 
> should be used sparingly.

Absolutely agreed.

> approach. But aggregation is really ubiquitous.

Exactly.


> IMO, one of the big mistakes of modern CS theory is the emphasis on
> "better" type systems (OO type systems are the rage) over  better control
> structures. Hopefully some of us Ada programmers will get a chance to
> experiment with way more powerful control structures when GNAT 3.10 comes
> out and some SNOBOL 4 capabilities become available.

Could not agree more.  This is sort of a case of the "revenge effect".
Used sparingly and with good judgement, "OO" stuff is quite effective
and useful.  Unfortunately, it has somehow become interpreted that
this means it should be used everywhere and that it is universally
good in development.  Completely fatuous.  Worse - outright
_clueless_.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Andrew Dunstan]

In article <Pine.SGI.3.95.970720113201.28934B-100000@shellx.best.com>, Brian Rogoff <bpr@shellx.best.com> wrote:

>I think it is a gross error of reasoning to suggest that OO inheritance is 
>somehow "natural" because we use the same word "inheritance" to describe 
>the process of the passing of genetic material from a biological entity to 
>its offspring. I suppose poorly designed inheritance hierarchies must also 
>be natural, since in nature we have examples of snippets of genetic
>material being transferred by virus. Reasoning by analogy is particularly
>suspect here.
>

Right. I once heard a computer scientist, who now occupies a prestigious 
chair, say that only left derived top down parsers should be used because 
that is how people read natural language. Not only is this a dubious 
proposition at best (I have seen research indicating that bottom up LR 
parsing has significant analogues in the way we read). but I can see no 
reason why a computer parser  should mimic a human. So let's steer clear of 
dubious analogies.

cheers

andrew

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <5qs47k$duf@drn.zippo.com> Nasser writes:

> In article <mheaney-ya023680001707970007130001@news.ni.net>, mheaney@ni.net
> says...
> >
> >Spoken like a true afficionado of inheritence!  Well, I have some more news
> >for you, Don.  Nature (interpret that to mean God, if that suits you) has
> >chosen aggregation as the essential means of systems construction.  
> 
> So, how does one explain what genetics tells us about DNA duplication
> ftom parents to their children?

It is pretty clear that Mathew is _not_ discussing this style of
inheritance - a type of genealogy inheritance.  If you want to draw
this sort of analogy into it, then note: OOPL classification style
inheritance is like Linean systematics, while what you are talking
about is akin to phylogentic systematics (a kind of cladistics).  The
semantics of these are totally different.


> offcourse, the human body is build by aggregation (eyes, ears, legs, arms,
> etc.), but the poperty that those pieces have are mostly inherited.

Actually, as long as you keep your terms and model types straight, the
"parts" are indeed inherited (in the phylogenetic sense).


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C?

[Matthew Heaney]

In article <01bc94e1$46912100$53aa20cc@default>, "Douglas A. Gwyn"
<DAGwyn@null.net> wrote:

>By the way, I am not taking sides in the subject debate, other than to
>point out that the choice of language may often be rationally influenced
>by factors other than purely linguistic considerations.  For example, Ada
>might be chosen by a DoD embedded systems provider simply because
>getting a waiver is too difficult, while C might be chosen for another
>project
>simply because C compilers and programmers are easier to obtain.

First of all, there is no waiver policy, because there is no mandate.  Ada
is a good enough language that it doesn't require one.

Read Emmett Page's Official Letter:

<http://sw-eng.falls-church.va.us/AdaIC/pol-hist/oasd497.shtml>

Second of all, Ada might be chosen by a DoD embedded systems provider
because the developers think it is the best language for the job, not
because they are required to use Ada (which they aren't).  Indeed, many
commercial organizations use Ada, by choice.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Is ADA as good for graphics programming as C?

[Dennis Weldy]

 Thats not quite correct. There WAS a mandate, and you DID have to get a
waiver to use non-ada code. 
When I was working for a defense contractor on a network-simulation
project, we had to get a waiver because the proect was not going to be done
in Ada,rather, Pascal. 
Recently, they've done away with the mandates and waivers, but they existed
for a long time.

Dennis

Matthew Heaney wrote in article ...

>In article <01bc94e1$46912100$53aa20cc@default>, "Douglas A. Gwyn"
><DAGwyn@null.net> wrote:
>
>>By the way, I am not taking sides in the subject debate, other than to
>>point out that the choice of language may often be rationally influenced
>>by factors other than purely linguistic considerations.  For example,
Ada
>>might be chosen by a DoD embedded systems provider simply because
>>getting a waiver is too difficult, while C might be chosen for another
>>project
>>simply because C compilers and programmers are easier to obtain.
>
>First of all, there is no waiver policy, because there is no mandate. 
Ada
>is a good enough language that it doesn't require one.
>
>Read Emmett Page's Official Letter:
>
><http://sw-eng.falls-church.va.us/AdaIC/pol-hist/oasd497.shtml>
>
>Second of all, Ada might be chosen by a DoD embedded systems provider
>because the developers think it is the best language for the job, not
>because they are required to use Ada (which they aren't).  Indeed, many
>commercial organizations use Ada, by choice.
>
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
><mailto:matthew_heaney@acm.org>
>(818) 985-1271
>.
> 

Re: Is ADA as good for graphics programming as C?

[Jon S Anthony]

In article <01bc94e1$46912100$53aa20cc@default> "Douglas A. Gwyn" <gwyn@ix.netcom.com> writes:

> > In spite of what you may have heard, your dishwasher, your car, your
> watch,
> > and even you are constructed using aggregation.  Last time I checked,
> > neither my computer (my little Mac, bless it), nor my stereo, nor my
> > microwave oven were constructed using inheritence - not even (gasp!)
> > multiple inheritence.  Say it ain't so, Joe!
> 
> That's not at all true.  In the course of engineering, there is
> normally a vast amount of inheritance going into systems design.
> What is inherited is often a model for the general class of the
> particular product, and the less original the designer, the more
> this shows.  For example, automobiles pretty much all look alike,
> and when a new one is designed they don't really start with a
> totally clean slate.  I doubt that assumptions such as "has 4
> wheels" are reexamined; they are merely inherited.

This is _not_ in any way shape or form anything like the sort of
"inheritance" codified and directly expressed in typical OOPLs.  What
you mention above is "genealogy style inheritance".  So, while there
is definitely truth in what you say, it is irrelevant to the topic at
hand.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Robert C. Martin]

Matthew Heaney wrote:
> 
> Oh, yes, I know the argument: Humans use classification to simplify things,
> so we should use classification to build software, blah blah blah.  Well
> here's the real scoop: humans use _abstraction_ to simplify their world.
> Humans view and build systems as multi-level, heirarchical structures,
> using _aggregation_.  So why build software systems any differently?

I sympathize with this point of view.   But let me add a bit more to
the heresy.  Inheritance, as defined in OO languages, *is* a form of
composition!  A derived class is *composed* of its base class along
with any other elements unique to the derivative.  

In the specific case of abstraction by polymorphism, the derived
classes that implement the interface of the base class are *composed*
of the interface of the base and the implementation of the derived.

Any of the abilities of inheritance can be achieved through 
composition, without the use of inheritance.  However, such techniques
can be inconvenient and error prone.  Inheritance is a very nice
language feature when you want to compose an interface with an
implementation.
> 
-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Relative complexity - Eiffel and Ada.

[Don Harrison]

Matt Heaney wrote:

:In article <EDEDB3.8rv@syd.csa.com.au>, donh@syd.csa.com.au wrote:
:
:>Have to disagree here. Appreciation of elegance and purity are God-given
:>qualities which many either suppress or don't have much of in the first place.
:>Judging by God's handiwork, He possesses them in abundance. 
:
:You've fallen into a common trap, Don.  You think that beauty and elegance
:exist independent of human perception; this is, of course, incorrect.

No, I realise they are perceived but believe that perception is pretty much
the same among all people. IMO, apparent variance from this principle is
attributable more to other factors such as dishonesty or mistaking other 
things for elegance than real variance. 

Assuming complexity is perceived the same by everybody, it suffices to speak 
simply of complexity rather than someone's perception of it.


:Here's a quote for you, to provide an analogy:
:
:"Complexity per se is not the culprit, of course; rather it is our human
:limitations in dealing with complexity that cause the problem." - William
:Wulf, quoted by Booch

This is true and a necessary consequence is that the complex task of software
engineering should be made as simple as possible to accomodate our inadequacy
in dealing with that complexity.


:There is no such thing as complexity, really.  Complexity is just a concept
:- it's what is felt by a human, when he observes natural phenomena (or the
:reaction of this human when he reviews software...).

I disagree. The fact that it is an abstract concept, doesn't mean we can't use 
it meaningfully to compare things including languages or software. For example,
since it's a relative concept, we can make meaningful qualitative statements 
like 

  "Language A is more complex than language B". 

Further, since we can even measure complexity, we can say 

  "Language A is roughly 50 times more complex than language B". 

[Languages A and B shall remain anonymous to protect the innocent.] :)


:When you speak of beauty and elegance, those terms have no meaning without
:speaking of the human who thinks something is beautiful or the human that
:perceives something to be elegant.  A thing is not beautiful all by itself
:- it is beautiful only in the mind of a human.

Agree.

:Looking at it from a systems point of view, beauty and elegance are refered
:to as "emergent properties," a thing that emerges because of the
:interaction of parts.

Okay here.

:So we can dispense with any mention of God, because he has nothing to do
:with it.  Contrary to they're being handed over by God, "elegance" and
:"purity" are simply concepts that emerge because of the structure of the
:human brain.  If you take away the human, then of course you take away
:elegance and purity to.

If you take away God, you take away the human and the ability God has given 
him to perceive elegance. But for the sake of discussion of perception,
it's true that we can ignore the source of that ability.

:You even hint at this yourself, when you say "Judging by God's handiwork." 
:It's a _human_ that does the judging; there being no judge, there can be no
:elegant handiwork or pure handiwork - just handiwork.

I think what you're saying here is that if something exists in isolation and
no-one is aware of its existence, non-one can judge it to be elegant or 
otherwise. While this is true of some things, it isn't true of languages that 
we are familiar with. Since we are aware of their existence, we may judge 
their relative elegance.

:In fact, the concept of God is an emergent property, which emerges as the
:result of the interaction of a reflexive system aware of its own mortality,
:and a strong, built-in propensity to maintain its own existance ("survival
:instinct").  Take away the system, and of course you take away "God" too.

This may be a convenient notion but there's a slight problem in that no-one 
seems to have told God about this. When I ultimately stand before His judgement
seat, I hope to have something more convincing to say than:

  "I don't have to worry about you because you're just an emergent property."

Actually, I doubt I'll have much to say as I will be the one spoken to, not
listened to. ("It can't happen soon enough!", I hear someone saying.)


:>:Should one reject Ada out of hand, because
:>:mixin inheritance in Ada using generics is "inelegant" compared to using
:>:multiple inheritence in Eiffel?
:>
:>No, but it may mean that you're not able to model things as directly as you 
:>might otherwise.
:
:Spoken like a true afficionado of inheritence!  Well, I have some more news
:for you, Don.  Nature (interpret that to mean God, if that suits you) has
:chosen aggregation as the essential means of systems construction.  Oh, by
:the way, artificial ("man-made") systems are built using aggregation too! 

Not just aggregation but also inheritance. God has chosen a common template
in His creation which is applied repeatedly. An example is the animal template
which is composed of a brain, a heart, limbs etc. (aggregation). God has  
applied this template to all animals (technically, it's the reverse relation of 
inheritance at work). 

:Imagine that!

Not bad, eh?

:In spite of what you may have heard, your dishwasher, your car, your watch,
:and even you are constructed using aggregation.  Last time I checked,
:neither my computer (my little Mac, bless it), nor my stereo, nor my
:microwave oven were constructed using inheritence - not even (gasp!)
:multiple inheritence.  Say it ain't so, Joe!

Joe: "It ain't so". :)

What you're missing is that all these things also inherit (the designs common 
to all computers, to all stereos etc. The designers of the particular objects 
you possess have applied the inherited the designs of their predecessors and 
simply refined them a little. We know this practice as "Not re-inventing the 
wheel".

:How is this even possible? the dear Eiffel reader must be wondering.

Tell us! Tell us! (Sorry - couldn't resist).

:Oh, yes, I know the argument: Humans use classification to simplify things,
:so we should use classification to build software, blah blah blah.  Well
:here's the real scoop: humans use _abstraction_ to simplify their world. 
:Humans view and build systems as multi-level, heirarchical structures,
:using _aggregation_.  

.. and inheritance.

:So why build software systems any differently?

Why, indeed!

:In spite of the propaganda enunciated by certain computer scientists, real
:software systems do get built without inheritence.  A lone voice in a
:chaotic world, JP Rosen, says it clearly enough:
:
:"Once again, composition will exhibit a lower complexity and a greater
:security at the cost of ease of design.  For small-sized, quickly developed
:projects, classification can be an efficient method.  But for large-scale,
:long-lasting projects, composition is necessary to ensure control on the
:overall complexity."  - JP Rosen, What Orientation Should Ada Objects
:Take?, CACM, Nov 1992 (Vol 35, No 11)

I don't know what the basis is for this claim, but he's probably talking about
assertion-less software (eg. Ada). Inheritance minus DBC *is* dangerous and 
may introduce uncontrollable complexity. However, inheritance plus DBC scales
up quite nicely thanks very much so there's no need to favour composition
or inheritance depending on system size.

:If neither I nor Jean-Pierre can convince you of the efficacy of
:aggregation over inheritence, then perhaps these authors can:..

:And if that isn't enough, maybe the Gang of Four can put you over the edge:..
:
:"Favor object compostion over class inheritance." -- p. 20 of Design
:Patterns, by Gamma et al

In view of the danger of using inheritance *without* DBC and the fact that no 
commercial OO language in wodespread use promotes DBC, is it any surprise that 
the bulk of respected literature tries to steer you away from inheritance. I 
don't find that at all surprising.


:The argument that in Ada, "you can't model things as directly as you might
:otherwise," is completely specious.  Just the opposite is true, in fact. 

If I had the time, I could show this to be false (in general, compared to
Eiffel) ..

:Ada has a very rich type system, specifically designed to allow you to
:"directly model" logical entities, and especially physical entities, as
:would be necessary for its intended domain, embedded systems.

I agree Ada is strong in this area. Your example below demonstrates it well.

:Let's consider a simple example, from Ada: Language and Methodology, by
:Watt, Wichmann, and Findlay (the "famous" book in which Tony Hoare tepidly
                                                                    ^^^^^^^ :)
:endorses Ada in the Foreward).

[example elided]

:Now, what were you saying about not be able to model the problem directly?

I agree Ada fares well in modelling low-level problems but I think Eiffel
is better generally as a modelling tool. Also, so you may savour your moment 
of glory, I'll refrain from commenting on some syntactic issues. :)

In terms of low-level modelling, I guess a different (more OO) approach would 
suit Eiffel better. 


BTW, I think you'll find most Eiffel developers use inheritance sparingly. 
Composition is the primary form of reuse.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> I think what Nick means is that because Ada does not define Integer
> and Float as classes inheriting from a common ancestor class
> Numeric, they are less

Who cares.  In typical practice this is not even going to be used -
the efficiency sucks for any real numerical work and you will have to
resort to expanded types anyway.


> flexible than in Eiffel. In particular, you can't declare a generic
> Numeric container class and constrain *through inheritance* to store
> Integers or Floats.  Consequently, you can't use a Numeric container
> polymorphically by substituting an Integer or Float container. Also,
> you can't store both Floats and Integers in the same Numeric
> container. These things are simple and straightforward to do in
> Eiffel because INTEGER and REAL are both classes (as well as types)
> inheriting from class NUMERIC.

Shrug.  If you want that, just build Numeric.  But really, I doubt
that this is something you will want in the sort of applications Ada
and Eiffel target.  You want this sort of stuff?  Use CL.


> In Ada, there is something like a notional Numeric *type* having
> properties like assignment and addition but because it is not a
> class (tagged type), it's not extensible through inheritance. You

False.  You can extend and change the _behavior_ through inheritance.


> *other* inheritance mechanism - derived types - but that doesn't allow 
> polymorphism so you miss something compared with Eiffel.

Right.  As for polymorphism here - again who cares? as it is not very
likely that you want dispatching on individual numbers anyway.


> :Examples (*) and (**) are examples of "constrained genericity," which is
> :exactly what you said would be really nice to have.  So you have it an
> :Eiffel AND Ada.
> 
> No, I think Nick meant constraining from a common ancestor *through 
> inheritance*

OK, but again - who cares?  IMO, forcing everything into a
classification style of model naive, simplistic, overly constraining,
and typically wrong.


> :In Ada, you can even do mixin inheritance without using multiple
> :inheritance.  
> 
> Yes, through a round-about way using genericity. This is inelegant compared 
> with multiple inheritance.

No it is not.  IMO, for mixins, the generic + SI is a _much_ better
model as it does not confuse the issue with any sort of is-a
semantics.  Just because I want to mixin a printing capability with my
rational number facility, does not mean that my rational numbers
suddenly become printers, but with MI, that is basically what you are
saying even though you probably don't mean it.  What you are really
looking for with mixins is composition with a form of automatic
delegation.


> However, it's simple compared to the obscure technique for acheiving
> multiple views in Ada95 Rationale, Section 4.6.3.  I'm still trying
> to comprehend that one!

It is obscure, but not particularly difficult.  However, I agree that
is the one case where MI is actually useful.  OTOH, this is relatively
rare thing.  IMO, if you really want/need this level of capability,
then you may as well just use CLOS, as it is far more capable than
either Ada's or Eiffel's object model.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Don Harrison]

Jon S Anthony wrote:

:In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> I think what Nick means is that because Ada does not define Integer
:> and Float as classes inheriting from a common ancestor class
:> Numeric, they are less
:
:Who cares.  In typical practice this is not even going to be used -
:the efficiency sucks for any real numerical work and you will have to
:resort to expanded types anyway.

The convenience is there if you need it. You don't even have that option in Ada.


:> flexible than in Eiffel. In particular, you can't declare a generic
:> Numeric container class and constrain *through inheritance* to store
:> Integers or Floats.  Consequently, you can't use a Numeric container
:> polymorphically by substituting an Integer or Float container. Also,
:> you can't store both Floats and Integers in the same Numeric
:> container. These things are simple and straightforward to do in
:> Eiffel because INTEGER and REAL are both classes (as well as types)
:> inheriting from class NUMERIC.
:
:Shrug.  If you want that, just build Numeric.  But really, I doubt
:that this is something you will want in the sort of applications Ada
:and Eiffel target.  

Ditto.


:> In Ada, there is something like a notional Numeric *type* having
:> properties like assignment and addition but because it is not a
:> class (tagged type), it's not extensible through inheritance. You
:
:False.  You can extend and change the _behavior_ through inheritance.

Try reading the whole paragraph instead of quoting out of context - it's obvious
I'm talking about inheritance ala tagged types.

:> *other* inheritance mechanism - derived types - but that doesn't allow 
:> polymorphism so you miss something compared with Eiffel.
:
:Right.  As for polymorphism here - again who cares? as it is not very
:likely that you want dispatching on individual numbers anyway.

Possibly.


:> :Examples (*) and (**) are examples of "constrained genericity," which is
:> :exactly what you said would be really nice to have.  So you have it an
:> :Eiffel AND Ada.
:> 
:> No, I think Nick meant constraining from a common ancestor *through 
:> inheritance*
:
:OK, but again - who cares?  IMO, forcing everything into a
:classification style of model naive, simplistic, overly constraining,
:and typically wrong.

In your opinion.


:> :In Ada, you can even do mixin inheritance without using multiple
:> :inheritance.  
:> 
:> Yes, through a round-about way using genericity. This is inelegant compared 
:> with multiple inheritance.
:
:No it is not.  IMO, for mixins, the generic + SI is a _much_ better
:model as it does not confuse the issue with any sort of is-a
:semantics.  Just because I want to mixin a printing capability with my
:rational number facility, does not mean that my rational numbers
:suddenly become printers, 

Depending on who you listen to, that's an inappropriate use of MI.

:but with MI, that is basically what you are
:saying even though you probably don't mean it.  What you are really
:looking for with mixins is composition with a form of automatic
:delegation.
:
:
:> However, it's simple compared to the obscure technique for acheiving
:> multiple views in Ada95 Rationale, Section 4.6.3.  I'm still trying
:> to comprehend that one!
:
:It is obscure, but not particularly difficult.  However, I agree that
:is the one case where MI is actually useful.  OTOH, this is relatively
:rare thing.  IMO, if you really want/need this level of capability,
:then you may as well just use CLOS, as it is far more capable than
:either Ada's or Eiffel's object model.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Jon S Anthony]

In article <EDCJ0J.JKI@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jon S Anthony wrote:
> 
> :In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
> :
> :> I think what Nick means is that because Ada does not define Integer
> :> and Float as classes inheriting from a common ancestor class
> :> Numeric, they are less
> :
> :Who cares.  In typical practice this is not even going to be used -
> :the efficiency sucks for any real numerical work and you will have to
> :resort to expanded types anyway.
> 

> The convenience is there if you need it. You don't even have that
> option in Ada.

??? Of course you do.  That's what I meant by building a "Numeric"
tagged type (speaking of reading/quoting things in overall
context...).  Of course, you do actually have to build it if you
really want this and _that_ might be considered a disadvantage.


> :Shrug.  If you want that, just build Numeric.  But really, I doubt
> :that this is something you will want in the sort of applications Ada
> :and Eiffel target.  
> 
> Ditto.

Ditto.


> :> :Examples (*) and (**) are examples of "constrained genericity," which is
> :> :exactly what you said would be really nice to have.  So you have it an
> :> :Eiffel AND Ada.
> :> 
> :> No, I think Nick meant constraining from a common ancestor *through 
> :> inheritance*
> :
> :OK, but again - who cares?  IMO, forcing everything into a
> :classification style of model naive, simplistic, overly constraining,
> :and typically wrong.
> 
> In your opinion.

Right - as stated.  The important point being that the contrary view
is _just opinion_ as well.  And IMO (:-), not at all convincing.
Especially as there are loads of alternative modeling styles used
everywhere everyday.


> :No it is not.  IMO, for mixins, the generic + SI is a _much_ better
> :model as it does not confuse the issue with any sort of is-a
> :semantics.  Just because I want to mixin a printing capability with my
> :rational number facility, does not mean that my rational numbers
> :suddenly become printers, 
> 
> Depending on who you listen to, that's an inappropriate use of MI.

But _not_ of mixins.  Which is exactly the point.

> 
> :but with MI, that is basically what you are
> :saying even though you probably don't mean it.  What you are really
> :looking for with mixins is composition with a form of automatic
> :delegation.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Robert I. Eachus]

In article <33C4AF0E.339D@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

  > Matthew Heaney wrote:

  >> Different languages have made different choices with respect to
  >> whether all types should be part of a common hierarchy.  That
  >> Eiffel did so, and Ada did not, should not be construed as
  >> better, just different.

  > I'm not sure about this. If you don't have a common hierarchy, then that
  > precludes you from using a common root. Now this is useful when we look
  > at container classes. It is particularly useful when you can constrain
  > the type that is store in a container to a particular type. 

  > By having a common hierarchy you are not limited from doing anything
  > that you can without one. However the reverse is not true. Therefore a
  > common heirarchy is the better solution.

     But you should never let consistancy get in the way of doing the
"right" thing.  Ada does have a common hierarchy, but as it says right
under the language-defined class chart at RM 3.2(12), "The classes
'numeric' and 'nonlimited' represent other classification dimensions
and do not if into the above strictly hierarchical picture." RM 3.2(13)

     In Ada integer types are grouped with enumeration types into
discrete types, while floating point types are grouped with ordinary
fixed point types and decimal fixed point types into real types.

     Of course, if you don't like this hierarchy, you can create your
own, and even if you want have all classes rooted at 'Object'.  But
you will lose some of the richness of the Ada organization if you stay
inside such a family of classes.
--

					Robert I. Eachus

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

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[John Nagle]

abo@minkirri.apana.org.au (Donovan Baarda) writes:
>the book I've got says that programs that depend on the mechanism used are
>erroneous. I would take a bloody good compiler to raise an error on a
>program that does it.

    It can be done.  See my "Practical Program Verification", 
POPL '83.

>>>The biggest problem with Ada compared to C, is the language is so complex.
>>>The compiler writers have such a hard time just getting it to work that
>>>they hardly get around to putting in optimisation. C is so small that
>>>compiling it is easy, so more effort gets spent on optimization. 

    C++, though, is now bigger than Ada.

>>I think the DOD would prefer you use Ada, but the DOD does not mandate
>>Ada's use.

    At one time DOD did mandate Ada, but they gave up.

						John Nagle

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Don Harrison]

Donovan Baarda wrote:

:Eiffel is IMHO a better choice for safety-critical applications without
:excessive real time requirements. Design by contract obviously (and
:measurably?) contributes significantly to program safety. Combining this
:with a complete inheritanc heirachy of library classes with all the
:contracts defined and inheritable has to make a huge difference.

I agree on all points.

Realtime development will be an interesting one for Eiffel if the SCOOP 
concurrency model is adopted. IMO, Eiffel will offer a better alternative
to Ada, probably even for hard realtime systems. This is because SCOOP:

  1) Allows safe sharing of data, 
  2) Allows easy reallocation of threads to different processors, and
  3) Integrates concurrency with the class and contracting models.

WRT 1), SCOOP provides automatic locking of shared data so that users don't 
have to worry about it. Adding protected types to Ada to protect shared data
is a good idea, but if you use tasks on their own you have to roll-your-own
data protection using semaphores, for example, which is error prone.

While you can choose to do the right thing for new systems, your software will
be more reliable if the language takes care of locking automatically. Also (as 
Robert Dewar is fond of reminding us), you're not always in a position to 
choose - for example when using legacy code.

WRT 2), SCOOP allows you to reconfigure your system by re-allocating threads
to different processors to optimise performance without changing any code.
This is done in an external Concurrency Configuration File. This would be 
particularly valuable for realtime systems because you could logically partition 
the system according to how hard the realtime constraints are and allocate the 
hard bits to dedicated processors. Such partitioning would also allow liberal use
of assertions in the softer parts of the system where performance is not 
critical.

Some Ada implementations probably allow such flexibility as well but it 
certainly couldn't be any simpler than in SCOOP.

WRT 3), by integrating concurrency with classes and contracting, SCOOP offers 
a simpler (just classes - not tasks + protected types), more flexible (objects 
are not constrained to being either active or passive; concurrent classes may 
be extended through inheritance) and more powerful (synchronisation and 
correctness may be inherited) model than Ada's.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Tucker Taft]

Don Harrison (donh@syd.csa.com.au) wrote:

: Donovan Baarda wrote:

: :Eiffel is IMHO a better choice for safety-critical applications without
: :excessive real time requirements. Design by contract obviously (and
: :measurably?) contributes significantly to program safety. Combining this
: :with a complete inheritanc heirachy of library classes with all the
: :contracts defined and inheritable has to make a huge difference.

: I agree on all points. ...

I'm curious what you mean by safety-critical.

In my experience with safety-critical applications, you 
cannot have any significant amount of out-of-line run-time
support, and little or no use of dynamic storage allocation after 
system startup.

Eiffel's dependence on dynamic storage allocation and garbage 
collection basically rules it out for most (serious) safety-critical
applications, despite all its admittedly nice invariants and assertions.

One of the important features of Ada in the safety-critical domain
is that there is a very useful subset that makes little or no use 
of out-of-line run-time support, and essentially no use of dynamic
storage allocation.   Furthermore, there are FAA-certified versions 
of the minimal run-time support required.  I doubt the FAA will
ever certify a garbage collector.

Finally there are available tools (such as the "SPARK" tools from Praxis, 
Ltd.) which add support for all of the kinds of assertions that
Eiffel has, including full static analysis and theorem
proving support of the assertions, while allowing the programmer
to code within a subset of Ada that requires essentially
no out-of-line run-time support, and can still be compiled by any
commercial Ada compiler.

These are some of the reasons why Ada is the language of choice in many
applications that are safety-critical.  It is relatively straightforward
to add additional assertion-checking via pragmas and static analysis tools.  
It is not so easy to take a language like Eiffel that is fundamentally 
oriented toward dynamic storage allocation (and pervasive dynamic binding), 
and adapt it to work in the fully statically analyzable environment required 
for applications where human life is at stake.  

Ada95 was designed to be able to support programming in a way
that minimizes dynamic storage allocation, unnecessary dynamic binding, etc.
while still supporting the object-oriented paradigm and a very strong
and separately compilable contract between the clients 
and the implementation(s) of an abstract interface.  The "contract"
enforced at compile-time by the Ada compiler is much stronger than
the contract enforced at compile-time by most compilers, since it
includes strong type distinctions between otherwise equivalent scalar,
array, and pointer types, plus compiler-enforced parameter modes,
and the ability to use formal parameter names to verify actual/formal
parameter association.

: Don.
: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
: Don Harrison             donh@syd.csa.com.au

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

Safety-critical development in Ada and Eiffel

[Don Harrison]

Tucker Taft wrote:

:Don Harrison (donh@syd.csa.com.au) wrote:
:
:: Donovan Baarda wrote:
:
:: :Eiffel is IMHO a better choice for safety-critical applications without
:: :excessive real time requirements. Design by contract obviously (and
:: :measurably?) contributes significantly to program safety. Combining this
:: :with a complete inheritanc heirachy of library classes with all the
:: :contracts defined and inheritable has to make a huge difference.
:
:: I agree on all points. ...
:
:I'm curious what you mean by safety-critical.

Probably the same as you - systems which must function correctly (meet all 
functional requirements including timing constraints) where failure to do so
will incur great cost (loss of life, financial meltdowns etc.)


:In my experience with safety-critical applications, you 
:cannot have any significant amount of out-of-line run-time
:support, 

What, apart from managing concurrency, do you have in mind here?

In terms of the Eiffel concurrency overhead, it would probably be comparable
to that of Ada tasking. Optimisations and sensible design would make that 
acceptable, IMO.


:and little or no use of dynamic storage allocation after 
:system startup.
:
:Eiffel's dependence on dynamic storage allocation and garbage 
:collection basically rules it out for most (serious) safety-critical
:applications, despite all its admittedly nice invariants and assertions.

Both of these issues can be dealt with in Eiffel:

  1) Dynamic storage allocation - The solution here (as in Ada) is to use 
     a pre-allocated memory pool for HRT parts of the system so eliminating 
     the need for dynamic allocation under HRT conditions.

  2) Garbage collection - This can be solved by turning memory allocation and
     deallocation (GC) off after start-up. Most Eiffel implementations already 
     allow you to turn GC off so vendors would just have to add the ability 
     to control allocation as well. It could work as follows:

       - At startup, dynamic storage would be pre-allocated as per 1).
       - Dynamic storage allocation and GC would be turned off.
       - The thread operates under HRT conditions communicating minimally
         with other threads.
       - At shutdown, dynamic storage allocation and GC are turned on again.

     Note that in a concurrent context, such memory control would occur on a 
     per-thread basis so allocation and GC would work as normal on less critical 
     threads.


:One of the important features of Ada in the safety-critical domain
:is that there is a very useful subset that makes little or no use 
:of out-of-line run-time support, and essentially no use of dynamic
:storage allocation.   

What is included in that subset?


:Finally there are available tools (such as the "SPARK" tools from Praxis, 
:Ltd.) which add support for all of the kinds of assertions that
:Eiffel has, including full static analysis and theorem
:proving support of the assertions, ...

Sounds like a step in the right direction, however I guess the assertions are 
not inheritable. If so, they are not as powerful as Eiffel's.

 
[...]
 
:It is not so easy to take a language like Eiffel that is fundamentally 
:oriented toward dynamic storage allocation (and pervasive dynamic binding), ...

Eiffel implementations optimise a high percentage of dynamic calls to static 
ones - 80-90%? Also, since the overhead of the calling mechanism is just part
of the cost of making the call (the total cost includes execution of the body),
the resultant penalty for default dynamic binding is reduced to 5-10% - 
obviously not worth getting excited over, even for HRT systems.


:Ada95 was designed to be able to support programming in a way
:that minimizes dynamic storage allocation, unnecessary dynamic binding, etc.
:while still supporting the object-oriented paradigm and a very strong
:and separately compilable contract between the clients 
:and the implementation(s) of an abstract interface.  The "contract"
:enforced at compile-time by the Ada compiler is much stronger than
:the contract enforced at compile-time by most compilers, since it
:includes strong type distinctions between otherwise equivalent scalar,
:array, and pointer types, plus compiler-enforced parameter modes,
:and the ability to use formal parameter names to verify actual/formal
:parameter association.

Some of these aren't necessary and have been omitted in the design of Eiffel. 
Of the rest, Eiffel effectively delivers the same (or an equivalent) 
functionality or enables you to acheive it through good design. 

A couple of points, however..

1) Eiffel automatically generates interfaces from class texts (a good thing, 
   IMO) but I'm unsure which impementations routinely recompile the "body" 
   of a class after changes that *don't* change the "interface". 
   None should, IMO, as it's technically possible to detect this situation.

2) Eiffel's contracts are stronger, more general, more flexible and more powerful
   than in standard Ada. This doesn't mean Ada's contracting is useless by 
   any means. It's a tribute to the designers of Ada83 that support for 
   predefined contracts was included at the time it was designed. I'm 
   disappointed, of course, that they were omitted from Ada95.

3) Named parameter association is not necessary with systematic, sensible naming.
   I confess to still using them in Ada (through force of habit) but usually 
   find that my formal and actual names are identical. Using named association 
   under such circumstances only serves to clutter the software text.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Mike Stark]

Don Harrison wrote:
> 
> Tucker Taft wrote:
> 
<snip> 
> :and little or no use of dynamic storage allocation after
> :system startup.
> :
> :Eiffel's dependence on dynamic storage allocation and garbage
> :collection basically rules it out for most (serious) safety-critical
> :applications, despite all its admittedly nice invariants and assertions.
> 
> Both of these issues can be dealt with in Eiffel:
> 
>   1) Dynamic storage allocation - The solution here (as in Ada) is to use
>      a pre-allocated memory pool for HRT parts of the system so eliminating
>      the need for dynamic allocation under HRT conditions.

Does this "pre-allocated memory pool" mean that you will know exactly
what address
each object's data will reside at, or merely that you dynamically
allocate memory
at initialization and do not dynamically allocate after initialization
is complete?

My experience with flight software people here at Goddard (and it is
admittedly
limited) is that they are very conservative about knowing *exactly*
where
everything is located in memory -- they want the equivalent of a FORTRAN
common
block, which can be achieved in Ada (or C++, to be fair) by declaring
variables
of a tagged type in a package specification, e.g.

package Flight_Objects is
  DSS1,DSS2 : aliased Digital_Sun_Sensor.Instance; 
  -- Digital_Sun_Sensor.Instance is a tagged type in the Sensor class
hierarchy
  -- all the types below are tagged
  Sun : aliased Solar_Model.Instance;  
  Orbit : aliased Orbit_Propagator.Instance;
  -- etc.
  
end Flight_Objects;

(the aliased keyword in Ada allows pointers to statically declared
objects)

This is *not* the same thing as allocating objects at initialization --
the heap is 
not involved at all.
> 
>   2) Garbage collection - This can be solved by turning memory allocation and
>      deallocation (GC) off after start-up. 

Agreed -- this is reasonable approach
<snip>
> 
> :It is not so easy to take a language like Eiffel that is fundamentally
> :oriented toward dynamic storage allocation (and pervasive dynamic binding), ...
> 
> Eiffel implementations optimise a high percentage of dynamic calls to static
> ones - 80-90%? Also, since the overhead of the calling mechanism is just part
> of the cost of making the call (the total cost includes execution of the body),
> the resultant penalty for default dynamic binding is reduced to 5-10% -
> obviously not worth getting excited over, even for HRT systems.

Both Ada and Eiffel provide information to the compiler that allows
optimization
of dynamic calls to static ones -- this is an advantage of these 2
languages over
a less rigorously typed language such as Smalltalk. However, calls to
constructors
and destructors are exceedingly expensive compared to other method
calls, at least
in our division's experiences with C++.

In the interests of full disclosure, I will say my knowledge of Ada is
through
actual use and of Eiffel is purely academic, so I don't have the same
intuition
for what works in reality when you are talking about Eiffel.  I very
much like
the ideas behind Eiffel, especially the concept of programming by
contract.  

Despite that, my guess is that flight software people at Goddard would
not look kindly
on the fact that all objects must be dynamically allocated, and that
this goes double
for the manned space program or for the FAA's certification of
airliners. I am
interested in any contrary opinions, though, especially from people who
actually
have used Eiffel for safety critical systems.

--------------------------------------------------------------------------------
Michael Stark                                                  
NASA/GSFC                                           
Phone: (301) 286-5048                                   Code 551
Fax:    (301) 286-0245                                   Greenbelt, MD
20771
 e-mail: michael.e.stark@gsfc.nasa.gov
"I don't give them hell.  I tell the truth and they THINK it's hell!" 
Harry S. Truman
--------------------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Donovan Baarda]

On Thu, 10 Jul 1997 19:26:17 -0400, 
 Mike Stark <michael.e.stark@gsfc.nasa.gov> wrote:
>Don Harrison wrote:
>> 
>> Tucker Taft wrote:
>> 
><snip> 
>> :and little or no use of dynamic storage allocation after
>> :system startup.
>> :
>> :Eiffel's dependence on dynamic storage allocation and garbage
>> :collection basically rules it out for most (serious) safety-critical
>> :applications, despite all its admittedly nice invariants and assertions.
>> 
[snip heaps of stuff about the evils of dynamic memory allocation in
safety critical applications, and how to get around it in various
languages such as turning off the GC!!]

I can't help but think that the reason dynamic memory allocation got such
a bad rap in the first place was there was no GC in old languages. Turning
it off seems to me like a step backwards.

Absolute control of memory allocation has been seen as necisary in safety
critical systems because you need to be sure that you will never run out
of memory and never write things over each other. 

Dynamic memory allocation made proving this much harder, so the safety
people just banned it, and used the measurable decrease in failures as
proof. Kill dynamic memory in C and it becomes a hell of a lot more
reliable.

However, GC has changed the whole landscape a bit. I wonder if anyone has
tried to formally prove that a GC will ensure you never die from running
out of memory in a program with strictly controlled objects in a
controlled environment?

Programs are so complex today that doing safety analysis right from the
bottom (like where variables are allocated in memory) up for every program
is getting out of the question. At some point there is going to have to be
a heriachical aproach to safety, where low level tools (such as GC) are
proven safe first. Future programs can use these tools, and can have the
safety analysis done at a higher level without worrying about proving the
low level tools all over again.

I'm sure GC would improve safety, but I wouldn't want to try and convince
the safety people. Safety people are by nature, and probably necesity,
conservative people and will take a hell of a lot of convincing before
they will let you do anything the new way, even if it is safer.

I also wouldn't want to try and provide the proof :-)

ABO

Re: Safety-critical development in Ada and Eiffel

[Steve Furlong]

In article <slrn5scda9.3bm.abo@minkirri.apana.org.au>,
Donovan Baarda <abo@minkirri.apana.org.au> wrote:
>[snip heaps of stuff about the evils of dynamic memory allocation in
>safety critical applications, and how to get around it in various
>languages such as turning off the GC!!]
>
>I can't help but think that the reason dynamic memory allocation got such
>a bad rap in the first place was there was no GC in old languages. Turning
>it off seems to me like a step backwards.
>
>Absolute control of memory allocation has been seen as necisary in safety
>critical systems because you need to be sure that you will never run out
>of memory and never write things over each other. 
...

Another reason GC wasn't or isn't used in hard-real-time systems is
because you could never tell when it was going to need a long time to
get or free memory. If your process _must_ check ports every 10 ms,
you can't be waiting half a second for memory compaction.

Modern GC presumably can get around that problem, but the purveyors
presumably can't prove its efficacy and response time to the
satisfaction of the FAA and other safety hard-noses.


Regards,
Steve Furlong

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Steve Furlong wrote:
> get or free memory. If your process _must_ check ports every 10 ms,
> you can't be waiting half a second for memory compaction.

Arrgh! Will that idea nevere go away!!
The best available GC algorithms don't go away for compacting; they run
in parallel with the normal program (as a coroutine if you don't want a
preemptive scheduler).

> Modern GC presumably can get around that problem,

That reads "definitely", not "presumably". The algorithms are there.
Besides, hand-crafted GC may look nice on paper, but it's usually less
efficient than automatec GC.
Manual deallocation means programmers will pass around more copies of
objects, defeating the very reason why automated GC isn't used. (The
reason is that, if the programmer would just pass the reference, the
owner of the object has to worry wether that reference he gave aways is
still in use somewhere. If the object is copied, the owner can
deallocate the original and doesn't have to worry about the copy - but
the copying process itself may be more machine cycles than what would
have been necessary to reclaim the single object with automated GC.)


> but the purveyors
> presumably can't prove its efficacy and response time to the
> satisfaction of the FAA and other safety hard-noses.

Well, I'm feeling cynical today, so I'd say that the safety gurus just
don't know or care about the algorithms, because it's something new and
they'd have to *think*. (There is a surprising number of non-engineers
in any bureaucratic body.)

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Steve Furlong wrote:
> > get or free memory. If your process _must_ check ports every 10 ms,
> > you can't be waiting half a second for memory compaction.
> 
> Arrgh! Will that idea nevere go away!!
> The best available GC algorithms don't go away for compacting; they run
> in parallel with the normal program (as a coroutine if you don't want a
> preemptive scheduler).

How does GC run "in parallel" on a uniprocessor implementation?

I assume you mean that it can be run in a separate process, but that's
not
a concern. More interesting questions to ask about these algorithms are
(for example):

1. What is the longest "critical section" (a section that cannot be
pre-empted) within these GC algorithms?

2. If the GC process is given the lowest priority, how long can it be
"starved" before memory allocation problems occur?

3. If the GC process is not given the lowest priority, what is the
likelihood that a lower priority process will be starved?

4. How much overhead will be used in swapping this process in and out
sufficiently often to keep sufficient memory available?

> 
> > Modern GC presumably can get around that problem,
> 
> That reads "definitely", not "presumably". The algorithms are there.
> Besides, hand-crafted GC may look nice on paper, but it's usually less
> efficient than automatec GC.
> Manual deallocation means programmers will pass around more copies of
> objects, defeating the very reason why automated GC isn't used. (The
> reason is that, if the programmer would just pass the reference, the
> owner of the object has to worry wether that reference he gave aways is
> still in use somewhere. If the object is copied, the owner can
> deallocate the original and doesn't have to worry about the copy - but
> the copying process itself may be more machine cycles than what would
> have been necessary to reclaim the single object with automated GC.)
> 
> > but the purveyors
> > presumably can't prove its efficacy and response time to the
> > satisfaction of the FAA and other safety hard-noses.
> 
> Well, I'm feeling cynical today, so I'd say that the safety gurus just
> don't know or care about the algorithms, because it's something new and
> they'd have to *think*. (There is a surprising number of non-engineers
> in any bureaucratic body.)

Or, perhaps the people have enough problems analyzing time effects in
a safety-critical system to have to worry about another process, one
with potentially variable effects depending upon heap utilization
at different points in the program.

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

J Durchholz said

<<Arrgh! Will that idea nevere go away!!
The best available GC algorithms don't go away for compacting; they run
in parallel with the normal program (as a coroutine if you don't want a
preemptive scheduler).
>>


All very well, and a loud minority has been yelling this for a while :-)

But what would be convincing would be actual examples of critical real
time programs that use this kind of concurrent garbage collection
successfully. Typically in the past we have often seen posts of this
kind based on best understanding of current theory, but we have not
seen much in the way of real life experience articles!

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33CBF5DE.D5FB1B6C@munich.netsurf.de> Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:

> Steve Furlong wrote:
> > get or free memory. If your process _must_ check ports every 10 ms,
> > you can't be waiting half a second for memory compaction.
> 
> Arrgh! Will that idea nevere go away!!
> The best available GC algorithms don't go away for compacting; they run
> in parallel with the normal program (as a coroutine if you don't want a
> preemptive scheduler).

Well, I'm certainly a GC supporter (as many here know only too well
:-), but there's more to this than a simplistic "yes it can" "no it
can't".

First, compacting may well have nothing to do with it.  What
compacting are you talking about?  The sort that you get for "free" in
a copying collector?  Or do you really mean a compacting MS style
collector?  Even generational variants of the former will likely suck
up _way_ too much memory for the sort of application that Steve is
talking about.  And for the latter, true compaction activity
interwoven with mutator activity is non-trivial.  The techniques would
be closer to incremental or true concurrent collectors.  Now, these
latter are _claimed_ to be sufficient in _some_ real time scenarios.
But, a) this is typically predicated on some sort of HW support for
the GC, and b) even then, the sort of time constraints Steve is
talking about seem implausible given the current evidence.

Given the sort of application Steve seems to be talking about, I don't
think that current GC could guarantee things and besides, it probably
wouldn't buy you that much anyway - it's not likely that the
structures involved in the sort of program indicated would be highly
interwoven, which is when manual deallocation becomes extremely
burdensome and highly error prone (maybe outright impractical).


> That reads "definitely", not "presumably". The algorithms are there.

Highly unlikely given the sort of setting Steve seems to have in mind.
Think of an ECU where the 10ms time limit is the hard limit on the
evaluation loop and every cycle available in that time limit is used
up by "real" work.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Jon S Anthony wrote:

... Delete GC comments

> Highly unlikely given the sort of setting Steve seems to have in mind.
> Think of an ECU where the 10ms time limit is the hard limit on the
> evaluation loop and every cycle available in that time limit is used
> up by "real" work.

And this is in a safety critical development? Tell me where so I can
avoid it if possible. If you are so close to the time limit, you have no
margin for error which isn't very safe.

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33CF2193.18B0@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> Jon S Anthony wrote:
> 
> ... Delete GC comments
> 
> > Highly unlikely given the sort of setting Steve seems to have in mind.
> > Think of an ECU where the 10ms time limit is the hard limit on the
> > evaluation loop and every cycle available in that time limit is used
> > up by "real" work.
> 
> And this is in a safety critical development? Tell me where so I can
> avoid it if possible. If you are so close to the time limit, you have no
> margin for error which isn't very safe.

I was speaking somewhat more generally - realtime applications (which
may or may not be safety critical).  The most typical example of this
sort of thing that most everyone reading this NG probably uses
everyday is your car.  Turn on the ignition and, voila', you are using
such an application.  It is also worth noting that a) it is
_stunningly_ robust compared to the vast majority of software and b)
may well be written in lowly assembler...

But, that doesn't mean the same sort of constraint isn't there for
safety critical applications and there for a _very important reason_.
That hard 10ms time limit may be there in order to _ensure_ enough
_spare_ cycles are _always_ available for a non-nominal event.  That
is, you are _guaranteeing_ an appropriate margin of error.  Given that
you apparently think that would somehow be a bad thing, all I can say
is I'm glad you are not working on such applications (I infer that you
are not by the mere suggestion you make).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[John Nagle]

Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:
>Steve Furlong wrote:
>> get or free memory. If your process _must_ check ports every 10 ms,
>> you can't be waiting half a second for memory compaction.

>Arrgh! Will that idea nevere go away!!
>The best available GC algorithms don't go away for compacting; they run
>in parallel with the normal program (as a coroutine if you don't want a
>preemptive scheduler).

>> Modern GC presumably can get around that problem,

>That reads "definitely", not "presumably". The algorithms are there.

     If only the Java people would use them.

					John Nagle

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <nagleEDI407.ABs@netcom.com> nagle@netcom.com (John Nagle) writes:

> >> Modern GC presumably can get around that problem,
> 
> >That reads "definitely", not "presumably". The algorithms are there.
> 
>      If only the Java people would use them.

:-)!  To be fair (to GC), with respect to any (all the!!!) problems of
efficiency, efficacy or robustness in Java, GC is the _least_ of its
worries!

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

> Eiffel implementations optimise a high percentage of dynamic calls to
static 
> ones - 80-90%? Also, since the overhead of the calling mechanism is just
part
> of the cost of making the call (the total cost includes execution of the
body),
> the resultant penalty for default dynamic binding is reduced to 5-10% - 
> obviously not worth getting excited over, even for HRT systems.

I dunno. I've seen more than one safety-critical embedded real-time systems
that
had to be re-worked at some cost to recover 5-10% overhead.


> 2) Eiffel's contracts are stronger, more general, more flexible and more
powerful
>    than in standard Ada. This doesn't mean Ada's contracting is useless
by 
>    any means. It's a tribute to the designers of Ada83 that support for 
>    predefined contracts was included at the time it was designed. I'm 
>    disappointed, of course, that they were omitted from Ada95.

I'm not sure what was in Ada83 that was omitted in Ada95; however, I have
noticed
that Eiffel examples posted in various places tend to have assertions that
are
fairly simple in nature (range checks), etc that are directly representable
in Ada.
Those that aren't tend to be easy to do with good Ada design using
exceptions (sort
of the same "good design principles" that you discussed using in Eiffel to
get
the features made explicit in Ada).

I think I'd like to see more cases where Eiffel is used in "hard" real-time
safety-critical
systems, and in particular some years of experience where Eiffel accurately
detects -
AND CORRECTS - for faults that are not routinely handled in equivalent Ada
systems
developed by the same vendor. I think that experience is already starting
to emerge with
respect to Ada vs. older languages in this domain, particularly for Ada's
static checks.

> 
> 3) Named parameter association is not necessary with systematic, sensible
naming.
>    I confess to still using them in Ada (through force of habit) but
usually 
>    find that my formal and actual names are identical. 

Not our experience at all, particularly for commonly-used routines within a
system. Named
parameter association is extremely useful, in my experience.

> Using named association 
>    under such circumstances only serves to clutter the software text.

Fortunately, in Ada, you can only use named notation where you want.

> 
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au
> 
> 
> 

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Ken Garlington wrote:

> I'm not sure what was in Ada83 that was omitted in Ada95; however, I have
> noticed
> that Eiffel examples posted in various places tend to have assertions that
> are
> fairly simple in nature (range checks), etc that are directly representable
> in Ada.
> Those that aren't tend to be easy to do with good Ada design using
> exceptions (sort
> of the same "good design principles" that you discussed using in Eiffel to
> get
> the features made explicit in Ada).
> 

There's a big difference between assertions and exceptions.

I think a sign that says: "Dangerous curve ahead: left turn required"
(precondition)

is much more useful than one that says: "Accident zone ahead"
(exception declaration)

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Ted Velkoff wrote:
> 
> Ken Garlington wrote:
> 
> > I'm not sure what was in Ada83 that was omitted in Ada95; however, I have
> > noticed
> > that Eiffel examples posted in various places tend to have assertions that
> > are
> > fairly simple in nature (range checks), etc that are directly representable
> > in Ada.
> > Those that aren't tend to be easy to do with good Ada design using
> > exceptions (sort
> > of the same "good design principles" that you discussed using in Eiffel to
> > get
> > the features made explicit in Ada).
> >
> 
> There's a big difference between assertions and exceptions.
> 
> I think a sign that says: "Dangerous curve ahead: left turn required"
> (precondition)
> 
> is much more useful than one that says: "Accident zone ahead"
> (exception declaration)

However, compare and contrast:

(ada-ish): type Foo_Type is range 1 .. 10;
           procedure Do_Something ( X : in Foo_Type );

(Eiffel-ish): procedure Do_Something ( X : in Integer );
                require X > 0 and X < 11;

Doesn't seem to make a lot of difference to me, although of course I
get to reuse Foo_Type in a lot of static contexts.

As to the more elaborate checks:

       procedure Do_Something (X : in Integer);

       X_Error : exception;
         -- raised if X does not meet precondition Complex_Precondition;

is not particularly more difficult to understand than:

     procedure Do_Something (X: in Integer);
       require Complex_Precondition(X);

The key is to have the external view of these assertions documented, and
to have
violations of those assertions cause certain effects in the system. Ada
has done more
than an adequate job in this area for our safety-critical systems. I
don't
need more of this; I need more static analysis tools (as the Safety and
Security Annex provides the foundation to support) and more efficient
code,
since safety critical embedded systems usually have a lot of
requirements
that preclude using the latest and greatest hardware.


> 
> -- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33C831CE.4E56@flash.net> Ken Garlington <keg0@flash.net> writes:

> However, compare and contrast:
> 
> (ada-ish): type Foo_Type is range 1 .. 10;
>            procedure Do_Something ( X : in Foo_Type );
> 
> (Eiffel-ish): procedure Do_Something ( X : in Integer );
>                 require X > 0 and X < 11;
> 
> Doesn't seem to make a lot of difference to me

That's because there basically isn't any.


>, although of course I get to reuse Foo_Type in a lot of static
> contexts.

Right.  But then that's what Eiffel class invariants are about...


> As to the more elaborate checks:
> 
>        procedure Do_Something (X : in Integer);
> 
>        X_Error : exception;
>          -- raised if X does not meet precondition Complex_Precondition;
> 
> is not particularly more difficult to understand than:
> 
>      procedure Do_Something (X: in Integer);
>        require Complex_Precondition(X);

The complexity of the pre/post condition is not an issue.  You can get
basically the same "expressiveness" in Ada with:

    type Require is boolean range True..True;
...

    Assert : Require := Complex_Precondition(X);

So, the complexity of the condition is irrelevant.  What you can't get
at this level of expressiveness are general level class invariants.
BUT,


> The key is to have the external view of these assertions documented,
> and to have violations of those assertions cause certain effects in
> the system. Ada has done more than an adequate job in this area for
> our safety-critical systems. I don't need more of this; I need more
> static analysis tools (as the Safety and Security Annex provides the
> foundation to support) and more efficient code, since safety
> critical embedded systems usually have a lot of requirements that
> preclude using the latest and greatest hardware.

sounds a _lot_ more apropos and important.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Wes Groleau]

> > As to the more elaborate checks:
> >
> >        procedure Do_Something (X : in Integer);
> >
> >        X_Error : exception;
> >          -- raised if X does not meet precondition Complex_Precondition;
> >
> > is not particularly more difficult to understand than:
> >
> >      procedure Do_Something (X: in Integer);
> >        require Complex_Precondition(X);
> 
> The complexity of the pre/post condition is not an issue.  You can get
> basically the same "expressiveness" in Ada with:
> 
>     type Require is boolean range True..True;
> ...
> 
>     Assert : Require := Complex_Precondition(X);

Although this raises Constraint_Error instead of X_Error, i.e., it is
a little less descriptive

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

Don Sez:

> Jon S Anthony wrote:
> 
> :In article <33C831CE.4E56@flash.net> Ken Garlington <keg0@flash.net> writes:
> :
> :> However, compare and contrast:
> :> 
> :> (ada-ish): type Foo_Type is range 1 .. 10;
> :>            procedure Do_Something ( X : in Foo_Type );
> :> 
> :> (Eiffel-ish): procedure Do_Something ( X : in Integer );
> :>                 require X > 0 and X < 11;
> :> 
> :> Doesn't seem to make a lot of difference to me
> :
> :That's because there basically isn't any.
> 
> In this case, only by virtue of the fact that in Ada, Integer isn't
> an extensible type.

First, Integer _is_ extensible with respect to operations.  You can't
add new slots to it (data extension), but you can add operations.  But
then why would you _want_ to add new slots??

Second, even if you couldn't do this, why would that "fact" be a
reason for the claim??


> Even if it were, you can't inherit the contract.

Well, a) it is and b) you certainly _can_ inherity this sort of
contract:

    type My_Integer is new Integer range 1..10;
    --
    -- Inherits std integer ops and attributes
    -- Maybe we add some more to these specific to My_Integer

... Somewhere later

    type Gain_Type is new My_Integer;
    --
    -- Inherits the range constraint and all My_Integer ops,
    -- both the std integer ones and any of the new specific ones
    -- Override or add new ones here...


> You have to redeclare it each time you inherit 

I don't think so.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Jon S Anthony wrote:

:In article <33C831CE.4E56@flash.net> Ken Garlington <keg0@flash.net> writes:
:
:> However, compare and contrast:
:> 
:> (ada-ish): type Foo_Type is range 1 .. 10;
:>            procedure Do_Something ( X : in Foo_Type );
:> 
:> (Eiffel-ish): procedure Do_Something ( X : in Integer );
:>                 require X > 0 and X < 11;
:> 
:> Doesn't seem to make a lot of difference to me
:
:That's because there basically isn't any.

In this case, only by virtue of the fact that in Ada, Integer isn't an extensible 
type. Even if it were, you can't inherit the contract. You have to redeclare 
it each time you inherit - not very good for maintenance, let alone reliability. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Jon S Anthony wrote:
> 
> :In article <33C831CE.4E56@flash.net> Ken Garlington <keg0@flash.net> writes:
> :
> :> However, compare and contrast:
> :>
> :> (ada-ish): type Foo_Type is range 1 .. 10;
> :>            procedure Do_Something ( X : in Foo_Type );
> :>
> :> (Eiffel-ish): procedure Do_Something ( X : in Integer );
> :>                 require X > 0 and X < 11;
> :>
> :> Doesn't seem to make a lot of difference to me
> :
> :That's because there basically isn't any.
> 
> In this case, only by virtue of the fact that in Ada, Integer isn't an extensible
> type. Even if it were, you can't inherit the contract. You have to redeclare
> it each time you inherit - not very good for maintenance, let alone reliability.

Not sure what this means... the "Integer" referred to above would be
Eiffel's integer,
not Ada's.

You can certainly inherit the contract for Foo_Type in Ada. Any types
declared based on
Foo_Type will inherit the operations defined for it. (Apparently this
isn't used a whole
lot, but it is available...)


> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <JSA.97Jul13164937@alexandria.organon.com>, 
jsa@alexandria.organon.com says...

>    type Require is boolean range True..True;
>...
>
>    Assert : Require := Complex_Precondition(X);

Interesting idea.  However it does not match Eiffel assertions.

1: Eiffel assertions are only executed at certain times, not at every
invocation of a routine (see E:TL or OOSC2 for the gory details).

2: You can't inherit assertions.  Any such system would require lots
of duplicated assertions.

3: Invariants are still very tricky to support.  You need to call the
invariant checks at the same time as the pre and post conditions.  See
above for details of when this occurs.

4: You had better be pretty sure that the compiler is not going to
optimise your checks into oblivion during debugging, and conversely
you need a way to turn them off for production code.

5: Whilst you could extract the short and flat forms for an Ada class
(sorry, "tagged type"), you can only do so by extending the language
beyond the standard (new special types "require", "ensure", "invariant")
and introducing special coding standards.  This kind of non-standard
language extension is one of the things Ada was designed to avoid.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
> In article <JSA.97Jul13164937@alexandria.organon.com>,
> jsa@alexandria.organon.com says...
> 
> >    type Require is boolean range True..True;
> >...
> >
> >    Assert : Require := Complex_Precondition(X);
> 
> Interesting idea.  However it does not match Eiffel assertions.
> 
> 1: Eiffel assertions are only executed at certain times, not at every
> invocation of a routine (see E:TL or OOSC2 for the gory details).

OK, so Eiffel's different. What's the significant advantage of this
approach.

> 
> 2: You can't inherit assertions.  Any such system would require lots
> of duplicated assertions.

Why would I have to duplicate assertions?

> 
> 3: Invariants are still very tricky to support.  You need to call the
> invariant checks at the same time as the pre and post conditions.  See
> above for details of when this occurs.

Again, I'm not trying to duplicate Eiffel. How much do I lose if Ada
invariants
are different?

> 
> 4: You had better be pretty sure that the compiler is not going to
> optimise your checks into oblivion during debugging, and conversely
> you need a way to turn them off for production code.

Actually, I don't mind the checks being "optimized into oblivion" if the
compiler can deduce that they are unnecessary, and I certainly don't
want
to exercise one kind of code during development and another during test.
The alternative (as was proposed by one Eiffel advocate) is to not use
_any_ assertions for hard real-time threads.

If Eiffel compilers do no optimizations of assertions, and there are a
lot of complex assertions in Eiffel code, what does this say for the
efficiency of the code?

> 5: Whilst you could extract the short and flat forms for an Ada class
> (sorry, "tagged type"), you can only do so by extending the language
> beyond the standard (new special types "require", "ensure", "invariant")
> and introducing special coding standards.  This kind of non-standard
> language extension is one of the things Ada was designed to avoid.

Why would you want to _extract_ such information? The contract is in the
Ada specification in all of my code, at the level of detail I want
public.

> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <33CD6207.6007@flash.net>, kennieg@flash.net says...
>
>Paul Johnson wrote:

>> 1: Eiffel assertions are only executed at certain times, not at every
>> invocation of a routine (see E:TL or OOSC2 for the gory details).
>
>OK, so Eiffel's different. What's the significant advantage of this
>approach.

The thing to understand about Eiffel assertions is that the mechanism was
not thrown together in an ad-hoc manner.  The "public" assertions (pre and
post conditions, and invariants) are there to support the production of
correct classes.  A class is "correct" in the Eiffel sense if a client
can never see a postcondition or invariant violated, provided that the
client follows the preconditions.

However if you call a routine from within a class, there is nothing to
say that the assertions have to be maintained.  In fact it would be
very restrictive to say that they must be.

What this comes down to is that if I write

   object.foo (arg1, arg2)

then the appropriate assertions should be tested.  OTOH if I write

   foo (arg1, arg2)

then the assertions should *not* be tested.

>> 2: You can't inherit assertions.  Any such system would require lots
>> of duplicated assertions.
>
>Why would I have to duplicate assertions?

Because of the Liskov Substitutability Principle.  A class must be able
to stand in for its ancestors.  Therefore it has to inherit the contracts
of its ancestors.  Therefore when you redefine a routine you need to copy 
the assertions from the ancestor.  Ditto for the invariants.

Eiffel does this automatically.

>> 3: Invariants are still very tricky to support.  You need to call the
>> invariant checks at the same time as the pre and post conditions.  See
>> above for details of when this occurs.

>Again, I'm not trying to duplicate Eiffel. How much do I lose if Ada
>invariants are different?

See above.  Remember also that if a routine is not redefined in a descendant,
it still has to check the descendant's invariants rather than just the
ancestors.  You need to define a routine "invariant_check".  To add new
invariants in a descendant, you redefine this routine to check the new
invariant and then call it's ancestor version(s).

>> 4: You had better be pretty sure that the compiler is not going to
>> optimise your checks into oblivion during debugging, and conversely
>> you need a way to turn them off for production code.
>
>Actually, I don't mind the checks being "optimized into oblivion" if the
>compiler can deduce that they are unnecessary,

In many compilers, if you say "assert: require = (a > b)" then the compiler
will observe that the value of "require" is not used thereafter, and
remove the statement.

>and I certainly don't
>want
>to exercise one kind of code during development and another during test.

The whole point of Eiffel assertions is that in a correct program they
have no effect on execution.  Therefore you get exactly the same results
whether they are enabled or not.

Apart from assertion exceptions, the only way that the execution of an
assertion can make a difference is if you call a function with side effects.
Eiffel functions are specifically banned from having side effects.

Of course, you *can* leave them enabled, but it slows down your code.

>If Eiffel compilers do no optimizations of assertions, and there are a
>lot of complex assertions in Eiffel code, what does this say for the
>efficiency of the code?

The point of assertions is to detect errors during debugging.  Some people
leave preconditions on in production code as well, if there are no speed
problems as a result.

>> [Difficulty of getting "short-flat" forms]

>Why would you want to _extract_ such information? The contract is in the
>Ada specification in all of my code, at the level of detail I want
>public.

No its not.  The point of software contracting is that the public assertions
are just that: public.  They are shown in the class interface (the short-flat
form).  Eiffel takes a different attitude to Ada here, and I can see the case
for the Ada approach.  Instead of writing interface and implementation in 
separate files, Eiffel provides tools to extract the interface information
from the implementation.  The public assertions are part of the interface,
because they specify the class behaviour to its clients.

The Ada approach has the advantage that you can easily lock the interface
while allowing changes to the implementation.  In Eiffel this could be
achieved by recording the short-flat form of a class (the interface) and
checking that the new short-flat form still matches after any change is made.
Its just a bit more hassle to organise.

Part of the important thing about the short-flat form is that it includes
*all* the interface information about a class, including any features inherited
from ancestors.  This is important, particularly in the presence of multiple
inheritance.  It means that programmers don't have to search through listings
to reconstruct it manually.

If you wanted to design a dialect of Ada with software contracting built
in properly then you would have to bring the public assertions into the
interface file.  And you would still need the equivalent of "flat" to bring
all the ancestor features into your class.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
> In article <33CD6207.6007@flash.net>, kennieg@flash.net says...
> >
> >Paul Johnson wrote:
> 
> >> 1: Eiffel assertions are only executed at certain times, not at every
> >> invocation of a routine (see E:TL or OOSC2 for the gory details).
> >
> >OK, so Eiffel's different. What's the significant advantage of this
> >approach.
> 
> However if you call a routine from within a class, there is nothing to
> say that the assertions have to be maintained.  In fact it would be
> very restrictive to say that they must be.

OTOH, wouldn't I want the option to see if intra-class dependencies
cause
assertions to be violated? (Actually, in my case, I generally do want
this...)

Certainly, if I wanted to have my Ada exceptions raised only from an
external caller, it would not be particularly difficult to structure my
package to do this. So, other than maybe writing a little less code,
what's
the significant advantage of this approach? Is it safer to not enforce
assertions for intra-class dependencies?

I still don't see the big advantage from a safety-critical
perspective...

> >> 2: You can't inherit assertions.  Any such system would require lots
> >> of duplicated assertions.
> >
> >Why would I have to duplicate assertions?
> 
> Because of the Liskov Substitutability Principle.

To expand: Why do I have to duplicate assertions _in Ada_?

> >> 3: Invariants are still very tricky to support.  You need to call the
> >> invariant checks at the same time as the pre and post conditions.  See
> >> above for details of when this occurs.
> 
> >Again, I'm not trying to duplicate Eiffel. How much do I lose if Ada
> >invariants are different?
> 
> See above.

Ditto.

> >> 4: You had better be pretty sure that the compiler is not going to
> >> optimise your checks into oblivion during debugging, and conversely
> >> you need a way to turn them off for production code.
> >
> >Actually, I don't mind the checks being "optimized into oblivion" if the
> >compiler can deduce that they are unnecessary,
> 
> In many compilers, if you say "assert: require = (a > b)" then the compiler
> will observe that the value of "require" is not used thereafter, and
> remove the statement.

Since this isn't Ada, I couldn't comment.

> 
> >and I certainly don't
> >want
> >to exercise one kind of code during development and another during test.
> 
> The whole point of Eiffel assertions is that in a correct program they
> have no effect on execution.  Therefore you get exactly the same results
> whether they are enabled or not.

This would require (a) no changes in timing and (b) zero probability
that
the compiler generates incorrect code with a certain combination of
compiler switches and code. I am skeptical.

> Apart from assertion exceptions, the only way that the execution of an
> assertion can make a difference is if you call a function with side effects.
> Eiffel functions are specifically banned from having side effects.

See above.

> Of course, you *can* leave them enabled, but it slows down your code.

It does something else. It requires you to decide what to do if the
assertion is violated during execution.

> >If Eiffel compilers do no optimizations of assertions, and there are a
> >lot of complex assertions in Eiffel code, what does this say for the
> >efficiency of the code?
> 
> The point of assertions is to detect errors during debugging.  Some people
> leave preconditions on in production code as well, if there are no speed
> problems as a result.

What do they do if the assertion is violated?

> 
> >> [Difficulty of getting "short-flat" forms]
> 
> >Why would you want to _extract_ such information? The contract is in the
> >Ada specification in all of my code, at the level of detail I want
> >public.
> 
> No its not. 

You haven't read my Ada specs!

> The point of software contracting is that the public assertions
> are just that: public.  They are shown in the class interface (the short-flat
> form). 

Exactly. The Ada specification is just that: the public part. In fact,
it's
included in our software user's manual for OS-type software for that
reason.
It defines what the user needs to know, and nothing else. (Actually, we
do have to do one thing: we suppress printing of the private part, much
like
Eiffel uses documentation tools to extract the class specification.)

> Eiffel takes a different attitude to Ada here, and I can see the case
> for the Ada approach.  Instead of writing interface and implementation in
> separate files, Eiffel provides tools to extract the interface information
> from the implementation.  The public assertions are part of the interface,
> because they specify the class behaviour to its clients.
> 
> The Ada approach has the advantage that you can easily lock the interface
> while allowing changes to the implementation.  In Eiffel this could be
> achieved by recording the short-flat form of a class (the interface) and
> checking that the new short-flat form still matches after any change is made.
> Its just a bit more hassle to organise.

Right, although I don't the organization as a signficant issue. I would
be
more worried about making an inadvertant change, and failing to do the
check
afterwards.

Of course, I suspect you could acheive the same effect in Eiffel by
having the code
in multiple files, and using a CM system to merge the files as needed.

> 
> Part of the important thing about the short-flat form is that it includes
> *all* the interface information about a class, including any features inherited
> from ancestors.  This is important, particularly in the presence of multiple
> inheritance.  It means that programmers don't have to search through listings
> to reconstruct it manually.

> If you wanted to design a dialect of Ada with software contracting built
> in properly then you would have to bring the public assertions into the
> interface file.  And you would still need the equivalent of "flat" to bring
> all the ancestor features into your class.

You can do this in Ada, too, with the proper documentation tools. It's
just
a bit more of a hassle to organize :)

> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <33CEB334.44C5@flash.net>, kennieg@flash.net says...
>
>Paul Johnson wrote:

>> However if you call a routine from within a class, there is nothing to
>> say that the assertions have to be maintained.  In fact it would be
>> very restrictive to say that they must be.
>
>OTOH, wouldn't I want the option to see if intra-class dependencies
>cause assertions to be violated? (Actually, in my case, I generally 
>do want this...)

You can always put in "private" assertions, such as "check" clauses
(similar to the classic C "assert" macro), and loop variant and invariant
clauses.

>Certainly, if I wanted to have my Ada exceptions raised only from an
>external caller, it would not be particularly difficult to structure my
>package to do this.

How?  It sounds like you would have to have internal and external
versions of all routines, all suitably redefined in the presence of
inheritance.  This is not a trivial suggestion.

>So, other than maybe writing a little less code, what's
>the significant advantage of this approach? Is it safer to not enforce
>assertions for intra-class dependencies?

Suppose I have an invariant in my class: "foo (a, b) = 0"

This states a relationship between a and b.

Now my class could have one routine which computes both a and b 
simultaniously.  Or it could have one routine which computes a, and
another routine which computes b.  This is purely an internal
implementation decision, so I should be able to chose either.

But if I have in my class the following two lines

   compute_a;
   compute_b;

then under your scheme I will get an exception.  As "compute_a" terminates,
the invariant will be checked, and will fail.  So the public assertion
constrains the private implementation.

(Actually, its even worse.  If I assign to a and then call any
routine before assigning to b then I'll trip the invariant check)

>I still don't see the big advantage from a safety-critical
>perspective...

The Eiffel rules for assertion checking allow the software to be laid out
in the most logical manner, making proper use of functions and procedures.  
This helps the programmers avoid bugs.


>> >Why would I have to duplicate assertions?
>> 
>> Because of the Liskov Substitutability Principle.
>
>To expand: Why do I have to duplicate assertions _in Ada_?

Well, Ada these days has inheritance.  If you want to write correct
software then descendants must inherit their ancestors contracts.
If you want to check and document this then you have to write the
appropriate assertions.


>> In many compilers, if you say "assert: require = (a > b)" then the compiler
>> will observe that the value of "require" is not used thereafter, and
>> remove the statement.
>
>Since this isn't Ada, I couldn't comment.

This discussion started when someone (I assumed it was you, sorry I didn't
check) proposed a type "require" defined as a subrange of Boolean constrained
to be true.  The above statement declares a variable "assert" of type
"require" and initialises it to "(a > b)".  If this expression evaluates to
false then a range exception will be triggered.  Sorry if I've got the
syntax wrong, and sorry that my explanation was wrong as well: I should have 
said "... the value of 'assert' is not used thereafter ...".

Of course there are other ways of writing assertion checks in Ada.

>> The whole point of Eiffel assertions is that in a correct program they
>> have no effect on execution.  Therefore you get exactly the same results
>> whether they are enabled or not.
>
>This would require (a) no changes in timing 

If your software depends upon timing for the correctness of its results
then I would certainly not want to see your software used in safety
critical applications.

I agree that timing variations can cause different results, but why would
they cause incorrect results?  If they don't cause incorrect results then
why are you worried?

>and (b) zero probability
>that the compiler generates incorrect code with a certain combination of
>compiler switches and code. I am skeptical.

What does this have to do with the problem under discussion?  I agree that
this can happen, but why does the ability to enable and disable assertions
cause any new problems?

>> Apart from assertion exceptions, the only way that the execution of an
>> assertion can make a difference is if you call a function with side effects.
>> Eiffel functions are specifically banned from having side effects.
>
>See above.

Functions that might have side effects are fairly easy to detect (they
assign to non-local variables, or call other routines that do so).  This
can be statically checked.

Sometimes a function will cache a result for future use.  I've written
table classes that do this.  Such functions are fairly rare.  When detected
by static checks they can either be inspected carefully or simply banned.

>> Of course, you *can* leave them enabled, but it slows down your code.
>
>It does something else. It requires you to decide what to do if the
>assertion is violated during execution.

Surely the same arguments apply to Ada?  Look at Arianne 5.

>> Some people
>> leave preconditions on in production code as well, if there are no speed
>> problems as a result.

>What do they do if the assertion is violated?

Depends on the application.  Generally they print an error report, dump
stack information to a file, and ask the user to phone the vendor.  Note
that I am not proposing this for real-time embedded applications.  However
there are safety-critical applications which are not real-time.
 
>> >> [Difficulty of getting "short-flat" forms]

>You haven't read my Ada specs!

Are you saying that you write the contract in comments in the spec?  If
so then good for you: its good practice.  The problem is that you have 
now duplicated the information: one copy is in comments, and the other
is in the assertions in the code.  Hence you have doubled the associated
work, and increased the risk of an error.  Eiffel requires that you write
the contract once, and uses the text for both purposes.

I'll agree that all of the benefits of Eiffel assertions are available
in Ada if you put in enough work, but why all this effort to do something
that Eiffel does automatically?  Also if the work becomes too onerous
then it tends to get dropped when schedule and budget pressure is on.
This has been the vice of software engineering ever since the discipline
was invented.  Eiffel makes good practice so cheap, easy and obvious 
that people do it without needing to make a special point of it.

[Stuff about deriving documentation from specs deleted: we seem to be in
broad agreement]

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <5qnab3$ft$3@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:

>>> In many compilers, if you say "assert: require = (a > b)" then the compiler
>>> will observe that the value of "require" is not used thereafter, and
>>> remove the statement.
>>
> >Since this isn't Ada, I couldn't comment.
>
> This discussion started when someone (I assumed it was you, sorry I
> didn't check) proposed a type "require" defined as a subrange of
> Boolean constrained to be true.  The above statement declares a
> variable "assert" of type "require" and initialises it to "(a > b)".
> If this expression evaluates to false then a range exception will be
> triggered.  Sorry if I've got the syntax wrong, and sorry that my
> explanation was wrong as well: I should have said "... the value of
> 'assert' is not used thereafter ...".

Actually, that would be myself who posted that (well known) idiom.
Please note that any compiler that did what you suggest without static
versions of a and b would be buggy.  If a and b are computed or passed
in or whatever, the only way that the compiler could blow off the code
would be if it did complete inter-procedural analysis to ensure that
no side effects anywhere could _possibly_ occur in the computation of
a and b.  Of course, if it could do that and still infer what the
assert would be, then of course it would be free to insert a
Constraint_Error in place of the code (if it was determinted to be
false) or simply remove the code (if it was determined to be true).

But in general, your scenario is either fantasy or a bug in the
compiler.


> Functions that might have side effects are fairly easy to detect (they
> assign to non-local variables, or call other routines that do so).  This
> can be statically checked.

Yes, this is "possible", but in the general case, basically
impractical.  The call graph could be extremely large and complicated
- especially in a dispatching environment.  Even worse - you can add
to the call graph in an inheritance based extension without going back
and recompiling everything that _might_ end up calling your new
side-effect inducing function.  That's actually part of the point of
such OO style extension.  In fact, you might not even be _able_ to go
back and recompile everything even if you decided to take that stance.
Any library code that a client might extend, for which there is no
available source will be impossible in principle to fix up in this
way.

In short, this is easier said than done and your comment evinces a
rather naive view of the matter.  In Ada you can "tag" such a function
as having no side effects by placing it in a "Pure" unit.  But even in
this much more restricted setting it is hard to give absolute
guarantees.


> >It does something else. It requires you to decide what to do if the
> >assertion is violated during execution.
> 
> Surely the same arguments apply to Ada?  Look at Arianne 5.

This is completely irrelevant to the Ariane 5 case.  I'm not sure why
people can't seem to twig this fact.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
 How?  It sounds like you would have to have internal and external
> versions of all routines, all suitably redefined in the presence of
> inheritance.  This is not a trivial suggestion.

Seems fairly trivial to me, particularly since I only have to worry
about this in certain cases.

> >So, other than maybe writing a little less code, what's
> >the significant advantage of this approach? Is it safer to not enforce
> >assertions for intra-class dependencies?
> 
> Suppose I have an invariant in my class: "foo (a, b) = 0"
> 
> This states a relationship between a and b.
> 
> Now my class could have one routine which computes both a and b
> simultaniously.  Or it could have one routine which computes a, and
> another routine which computes b.  This is purely an internal
> implementation decision, so I should be able to chose either.
> 
> But if I have in my class the following two lines
> 
>    compute_a;
>    compute_b;
> 
> then under your scheme I will get an exception.  As "compute_a" terminates,
> the invariant will be checked, and will fail.  So the public assertion
> constrains the private implementation.
> 
> (Actually, its even worse.  If I assign to a and then call any
> routine before assigning to b then I'll trip the invariant check)

Since I can structure me system to only perform the invariant from
an external call, this doesn't seem to be a big issue...

> 
> >I still don't see the big advantage from a safety-critical
> >perspective...
> 
> The Eiffel rules for assertion checking allow the software to be laid out
> in the most logical manner, making proper use of functions and procedures.
> This helps the programmers avoid bugs.

But that's an argument from assertion checking in general (which
Ada also supports). What's the big deal about having to write a
little extra code to only have certain assertions exercised from
external calls? The only difference is that Ada does internal
checks by defaults, Eiffel requires extra code if you want the internal
checks.

> 
> >> >Why would I have to duplicate assertions?
> >>
> >> Because of the Liskov Substitutability Principle.
> >
> >To expand: Why do I have to duplicate assertions _in Ada_?
> 
> Well, Ada these days has inheritance.  If you want to write correct
> software then descendants must inherit their ancestors contracts.
> If you want to check and document this then you have to write the
> appropriate assertions.

You have to write the appropriate assertions in the ancestor, in
either Ada or Eiffel.

To repeat: Why do I have to _duplicate_ assertions in Ada?

> >> In many compilers, if you say "assert: require = (a > b)" then the compiler
> >> will observe that the value of "require" is not used thereafter, and
> >> remove the statement.
> >
> >Since this isn't Ada, I couldn't comment.
> 
> This discussion started when someone (I assumed it was you, sorry I didn't
> check) proposed a type "require" defined as a subrange of Boolean constrained
> to be true.  The above statement declares a variable "assert" of type
> "require" and initialises it to "(a > b)".  If this expression evaluates to
> false then a range exception will be triggered.

ah... assert : require := (a > b);

However, this shouldn't be optimized out if an exception is possible, I
don't think. (I'd have to go look back at chapter 11 to be sure...)

>  Sorry if I've got the
> syntax wrong, and sorry that my explanation was wrong as well: I should have
> said "... the value of 'assert' is not used thereafter ...".
> 
> Of course there are other ways of writing assertion checks in Ada.
> 
> >> The whole point of Eiffel assertions is that in a correct program they
> >> have no effect on execution.  Therefore you get exactly the same results
> >> whether they are enabled or not.
> >
> >This would require (a) no changes in timing
> 
> If your software depends upon timing for the correctness of its results
> then I would certainly not want to see your software used in safety
> critical applications.
> 
> I agree that timing variations can cause different results, but why would
> they cause incorrect results?

Because you made a mistake, of course! A mistake which will be hidden
during
your testing, but become (potentially fatally) obvious during
operational use.
This is considered a Bad Thing.

>  If they don't cause incorrect results then
> why are you worried?

Because I won't know whether or not the actual system is correct or not!

> >and (b) zero probability
> >that the compiler generates incorrect code with a certain combination of
> >compiler switches and code. I am skeptical.
> 
> What does this have to do with the problem under discussion?  I agree that
> this can happen, but why does the ability to enable and disable assertions
> cause any new problems?

Because I have seen compilers that generate correct code with one set of
compiler options enabled, and a different (incorrect) set with a
different
set of options enabled. As with the timing issue above, I can do all of
my testing with assertions enabled, and have no clue whether or not the
code will still work after I disable those assertions (due to a compiler
bug). Again, this is a Bad Thing for safety-critical systems.

> 
> >> Apart from assertion exceptions, the only way that the execution of an
> >> assertion can make a difference is if you call a function with side effects.
> >> Eiffel functions are specifically banned from having side effects.
> >
> >See above.
> 
> Functions that might have side effects are fairly easy to detect (they
> assign to non-local variables, or call other routines that do so).  This
> can be statically checked.
> 
> Sometimes a function will cache a result for future use.  I've written
> table classes that do this.  Such functions are fairly rare.  When detected
> by static checks they can either be inspected carefully or simply banned.
> 
> >> Of course, you *can* leave them enabled, but it slows down your code.
> >
> >It does something else. It requires you to decide what to do if the
> >assertion is violated during execution.
> 
> Surely the same arguments apply to Ada?  Look at Arianne 5.

Yes, they certainly do (and I have applied them to Ada in comp.lang.ada
in the psat). Of course, this discussion isn't about Ada vs. Eiffel, is
it?
It's about the usefulness vs. the risks of using assertions in safety-
critical real-time systems. Eiffel claims it's big advantage over other
languages (including Ada) in this domain is stronger assertions. This is
not a particularly useful claim if there are serious problems with using
assertions extensively in such systems, is it?

> 
> >> Some people
> >> leave preconditions on in production code as well, if there are no speed
> >> problems as a result.
> 
> >What do they do if the assertion is violated?
> 
> Depends on the application.  Generally they print an error report, dump
> stack information to a file, and ask the user to phone the vendor.  Note
> that I am not proposing this for real-time embedded applications.  However
> there are safety-critical applications which are not real-time.

True. Furthermore, there are safety-critical real-time applications that
are not required to be fail-operational. In both cases, I can at least
see
the glimmer of hope that assertions might have some value. (However,
even
a non-real-time system monitoring a nuclear power plant, for example,
might
not want to print out a message saying "phone the vendor, and I hope the
reactor doesn't go supercritical while you're on hold :)

However, for _at least_ certain classes of safety-critical systems, this
behavior is completely unacceptable. Unfortunately, most people who
advocate
liberal use of exceptions are working on systems where it is quite
acceptable.

> 
> >> >> [Difficulty of getting "short-flat" forms]
> 
> >You haven't read my Ada specs!
> 
> Are you saying that you write the contract in comments in the spec?  If
> so then good for you: its good practice.  The problem is that you have
> now duplicated the information: one copy is in comments, and the other
> is in the assertions in the code. 

Actually, no: the public (abstracted) view of the assertion is in the
spec,
the implementation is in the code. This allows me to change the
implementation
any way I want without affecting the client, so long as I meet the
_requirement_
for the assertion.

> Hence you have doubled the associated
> work, and increased the risk of an error.  Eiffel requires that you write
> the contract once, and uses the text for both purposes.

Which is less writing, but may also require the user to see details that
are not necessary. (There's no obvious "best" answer here in my mind,
but
both approaches seem to be satisfactory from a safety standpoint.)

The other advantage in comments is that they won't affect the object
code. Thus, I can put in a user constraint, but not enforce it in the
code,
if I want. (I can enforce it in other ways; e.g. in a debugging
environment). This allows me to compromise between no assertion
capability
at all, and having assertions that affect my object code in unwanted
ways.
Particularly for complex constraints, comments may actually be more
safe in this environment. (Simple constraints, of course, can be coded
in
type information and checked statically, even if no dynamic checking is
done.)

> 
> I'll agree that all of the benefits of Eiffel assertions are available
> in Ada if you put in enough work, but why all this effort to do something
> that Eiffel does automatically?

As noted before, there doesn't seem to be much difference in the Ada
work
vs. the Eiffel work, particularly since there are limitations to the
amount of assertions to be embedded in the code for safety-critical
systems.

>  Also if the work becomes too onerous
> then it tends to get dropped when schedule and budget pressure is on.
> This has been the vice of software engineering ever since the discipline
> was invented.  Eiffel makes good practice so cheap, easy and obvious
> that people do it without needing to make a special point of it.

However, this extra capability does me no good if I can't take advantage
of it.

> 
> [Stuff about deriving documentation from specs deleted: we seem to be in
> broad agreement]
> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <33CFF256.61B4@flash.net>, kennieg@flash.net says...
>
>Paul Johnson wrote:

> How?  It sounds like you would have to have internal and external
>> versions of all routines, all suitably redefined in the presence of
>> inheritance.  This is not a trivial suggestion.

>Seems fairly trivial to me, particularly since I only have to worry
>about this in certain cases.

Hmmm.  I'd be interested to see a framework in Ada which lets you do all
the things with assertions that Eiffel does.  There is quite a lot of
stuff to do.  Some of it can be automated, some has to depend on coding
rules, and some requires new "special" variables or types (e.g. "require")
which will be recognised by language tools.  Any single part of the
Eiffel behaviour can be brought in fairly easily, but the whole thing
is starting to look rather clumsy.

>Since I can structure me system to only perform the invariant from
>an external call, this doesn't seem to be a big issue...

How does a routine distinguish between internal and external calls?

Or are you going to have two versions of each call?  An internal one
without assertion checks, and an external one which wraps the checks
around the internal one?  Or is there some nifty Ada Guru trick for
making this happen :-)

> The only difference is that Ada does internal
>checks by defaults, Eiffel requires extra code if you want the internal
>checks.

I'm not so sure about this.  Ada's main contribution to internal checks
are its subrange types.  I grant that declaring a subrange type is a bit
quicker and easier than putting an invariant in, but ultimately there
is not a lot of difference.

Meanwhile the emphasis on putting the interfaces to routines in their
assertions tends to reduce the number of explicit range checks required
on variables.  For instance array bound checks are carried out by
preconditions on the "array" routines.  Ada has a small edge here with
numeric data, but anything more complex presents problems.  To extend
the array subscript example, how would you express the fact that the
"item" routine of a hash table requires the argument value to be
contained in the hash table?  Eiffel just adds a "has(value)" 
precondition.

>You have to write the appropriate assertions in the ancestor, in
>either Ada or Eiffel.

>To repeat: Why do I have to _duplicate_ assertions in Ada?

Yes, but when you redefine the routine, you need to redefine its interface.
Software Contracting (the Eiffel approach to the LSP) states that you 
can:

1. Weaken the preconditions (so the routine may handle a wider range 
   of data,

2. Strengthen the postconditions (so the routine makes stronger guarantees
   about its effects).

To express this in Eiffel you use the "require else" and "ensure then"
clauses.  In Ada you would have to copy the pre and post conditions,
including the modifications.


>ah... assert : require := (a > b);
>
>However, this shouldn't be optimized out if an exception is possible, I
>don't think. (I'd have to go look back at chapter 11 to be sure...)

I believe you are correct.  Point conceeded.


>> I agree that timing variations can cause different results, but why would
>> they cause incorrect results?
>
>Because you made a mistake, of course! A mistake which will be hidden
>during
>your testing, but become (potentially fatally) obvious during
>operational use.
>This is considered a Bad Thing.

Umm.  Yes.  So bad that I would prefer a testing regime which at least
reduces the probability that it can occur.  How about a special stochastic
scheduler that simulates a wide variety of timing effects during testing.
I must confess I would have thought that this would be a good idea.  Lots
of things can cause timing changes.



>> [...] but why does the ability to enable and disable assertions
>> cause any new problems?
>
>Because I have seen compilers that generate correct code with one set of
>compiler options enabled, and a different (incorrect) set with a
>different set of options enabled. [...]
>Again, this is a Bad Thing for safety-critical systems.

Agreed.  I believe that the SCS people are looking at systems to verify
the object code against the source, as a way of getting around this problem
in general.  Of course the verifier may have bugs of its own, but it is
such a different piece of software to the compiler that the two bug sets
are unlikely to overlap.  Also it won't suffer from optimiser induced bugs.

Inheritance causes headaches here because you have to reconstruct the 
inheritance hierarchy from the optimised jump tables.  But then inheritance
causes problems in SCS anyway.


>Eiffel claims it's big advantage over other
>languages (including Ada) in this domain is stronger assertions. This is
>not a particularly useful claim if there are serious problems with using
>assertions extensively in such systems, is it?

Eiffel assertions are also part of the specification of classes.  It is
this that makes them significantly more powerful than Ada ranged types
and implementation assertions.

An Eiffel compiler is more likely to generate correct code with assertions
removed than with them enabled, because the code required for correct
assertion behaviour is quite complex.  However in the general case I
conceed your point.



>> Hence you have doubled the associated
>> work, and increased the risk of an error.  Eiffel requires that you write
>> the contract once, and uses the text for both purposes.
>
>Which is less writing, but may also require the user to see details that
>are not necessary. 

Such as?  I'm sorry, but I don't quite see what sort of details you 
have in mind.

Have you read Meyer's discussion of assertions and correctness in OOSC?
There are rules about this sort of thing (principally: the client must
be able to check the precondition before calling, and verify the
postcondition afterwards.  No private features are allowed in the public
assertions)

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <5qi26c$8ll$2@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:

> In article <JSA.97Jul13164937@alexandria.organon.com>, 
> jsa@alexandria.organon.com says...
> 
> >    type Require is boolean range True..True;
> >...
> >
> >    Assert : Require := Complex_Precondition(X);
> 
> Interesting idea.  However it does not match Eiffel assertions.

Never said it did.  I simply said that the complexity of the condition
does not prevent a similar expression in Ada to that in Eiffel.  That
still stands.


> 1: Eiffel assertions are only executed at certain times, not at every
> invocation of a routine (see E:TL or OOSC2 for the gory details).

Yeah, I've looked at this - what's the point??


> 2: You can't inherit assertions.  Any such system would require lots
> of duplicated assertions.

Sigh, for the _umpteenth_ time: Yes you can!  The correct statement
here is that you don't have _general_ class invariants without
"programming" them.  But constraints _are_ inherited.  And besides,
why is just waving "inheritance" around supposed to mean something
"important"??!?!?  Believe me - from my perspective it has _long_
since lost any magical luster it may have once had in SWE.


> 3: Invariants are still very tricky to support.  You need to call the
> invariant checks at the same time as the pre and post conditions.  See
> above for details of when this occurs.

This is just point 2 repeated...


> 4: You had better be pretty sure that the compiler is not going to
> optimise your checks into oblivion during debugging, and conversely
> you need a way to turn them off for production code.

???  As long as it is _legal_ (does not change the _meaning_ of the
code) this would be a _good_ thing!  It amounts to verification at
_compile_ time.


> 5: Whilst you could extract the short and flat forms for an Ada class
> (sorry, "tagged type"), you can only do so by extending the language
> beyond the standard (new special types "require", "ensure", "invariant")
> and introducing special coding standards.  This kind of non-standard
> language extension is one of the things Ada was designed to avoid.

Who cares about the bogus short flat form?  That is simply an error
prone method for describing interfaces.  Ada has no need for it as it
makes this stuff explicit!

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EDHqKo.K52@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> >> In article <JSA.97Jul13164937@alexandria.organon.com>, 
> >> jsa@alexandria.organon.com says...
> >> 
> >> >    type Require is boolean range True..True;
> >> >...
> >> >
> >> >    Assert : Require := Complex_Precondition(X);
> 
> This isn't quite right, because RM-11.6 allows the check to be
> eliminated.

Bob, could you clarify this?  I just had a look at 11.6 and I'm not
clear on how this works.  For example given the above it would clearly
be the case that you would also have:

...
exception
    when E : Constraint_Error =>
        Do_Something(....)...

in order to catch and do something in case the CE is raised.  How
could the implementation know that this would not "have some effect on
the external interactions of the program"????  I don't see how that is
possible (but then there's the old saying, "if it happens, it must be
possible"...)


> >> 4: You had better be pretty sure that the compiler is not going to
> >> optimise your checks into oblivion during debugging, and conversely
> >> you need a way to turn them off for production code.
> >
> >???  As long as it is _legal_ (does not change the _meaning_ of the
> >code) this would be a _good_ thing!  It amounts to verification at
> >_compile_ time.
> 
> An optimizer can change the *behavior* of a program without changing its
> *semantics*.

I know what you mean here, but a more accurate description would be
that an optimizer can change the behavior as long as that behavior is
not part of the defined semantics.

> This is true in all programming languages, including Ada.  Mostly,
> you're right -- if the optimizer can prove an assertion at compile
> time (and the optimizer is not buggy) then that's good.  But the
> 11.6 cases I mentioned above are troublesome.  In Ada, I prefer to
> use an Assert routine, or a pragma Assert (if supported by the
> compiler).  End users care about the *behavior*.

Actually, if they really did care about behavior that was _not_ part
of the defined semantics, wouldn't that really be a case of an
"erroneous" or possibly "bounded error" program????


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Robert A Duff]

In article <JSA.97Jul18151414@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EDHqKo.K52@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>
>> >> In article <JSA.97Jul13164937@alexandria.organon.com>, 
>> >> jsa@alexandria.organon.com says...
>> >> 
>> >> >    type Require is boolean range True..True;
>> >> >...
>> >> >
>> >> >    Assert : Require := Complex_Precondition(X);
>> 
>> This isn't quite right, because RM-11.6 allows the check to be
>> eliminated.
>
>Bob, could you clarify this?

Suppose Complex_Precondition(X) returns False.  Normally, you would
expect a range check on the assignment, and that would raise C_E.
However, 11.6(5) says the implementation does *not* have to raise C_E,
since *in the absence of raising it*, the result has no external effect.
I'm presuming there are no further references to Assert.  If
Complex_Precondition has externally-visible side-effects, then they must
happen.  If it doesn't (and the compiler can prove it), then the entire
call can also be eliminated.

Another example:

    X: Integer := 999;
    Y: Integer range 1..10 := X;

If there are no further references to Y (or there are, but they in turn
have no external effect), C_E need not be raised.  This is true whether
or not there is a handler for C_E (or others) somewhere (which of course
the compiler doesn't know, since it might be further up the call stack
-- that is, the permission would be useless if the presence of a handler
had something to do with it).

Of course, in order to take advantage of the permission, the compiler
has to prove the absence of external effect.  If Y is a local variable,
that's easy.

I've heard some compiler writers say they would never consider taking
advantage of 11.6, since it would confuse programmers.  I've heard other
compiler writers say that without 11.6, performance would stink.  I also
believe that compilers aren't super clever about taking advantage of
11.6 -- I believe that, because I've seen many ACVC tests that would
fail if the compiler was smarter.  Such ACVC tests are wrong, of course,
but they only get fixed if compiler writers complain.  (You can imagine
why such tests exist -- they are checking that C_E is raised in all the
zillion cases it should be, and it's easy to write a test where the
*only* external effect of the C_E is in the exception handler.  This
isn't the kind of code that occurs a lot in *real* programs.)

The basic idea is that you shouldn't write code that depends on getting
C_E for a failed run-time check (which the "Assert: Require..." example
does).  You can, however, depend on the fact that if a given value is
checked, you can't end up using a junk value in an externally visible
way.  E.g., in the above example, if we add a "Put(Y)", it cannot print
out "999" -- it must raise C_E before that.  In the "Assert: Require"
example, if you print out the value of Assert, then the check will not
be eliminated (but that kind of defeats the purpose of that little
trick).

Note that the permissions apply only to predefined checks.  If you write
an explicit "raise Constraint_Error;" or "raise My_Favorite_Error;",
then the permission does not apply.

>...  I just had a look at 11.6 and I'm not
>clear on how this works.  For example given the above it would clearly
>be the case that you would also have:
                      ^^^^^ could?
>
>...
>exception
>    when E : Constraint_Error =>
>        Do_Something(....)...

You *could* have such a handler, but normally you wouldn't -- you would
just let the program crash, and use debugging tools (and/or your brain)
to figure out why.  After all, you wrote the assertion because you
thought it was true.

>in order to catch and do something in case the CE is raised.  How
>could the implementation know that this would not "have some effect on
>the external interactions of the program"????

I think you're missing the phrase "in the absence of raising it" in the
RM.

>I know what you mean here, but a more accurate description would be
>that an optimizer can change the behavior as long as that behavior is
>not part of the defined semantics.

Yeah, maybe.  My point is just that the semantics (defined in the RM)
defines a *set* of possible behaviors, and the compiler's job is to make
sure that the actual behavior belongs to that set.  If you recompile
with optimization on, or if you simply run the same binary again, you
might get a different behavior.

>>...  End users care about the *behavior*.
>
>Actually, if they really did care about behavior that was _not_ part
>of the defined semantics, wouldn't that really be a case of an
>"erroneous" or possibly "bounded error" program????

Not sure what you mean here.  I'm talking about "end users" -- they
don't normally care one whit what the programming language semantics
are, nor even what programming language was used -- they just want the
program to behave properly.  And they often want the program to be
written in such a way that it always gets the same answer for the same
input.

- Bob

Re: Safety-critical development in Ada and Eiffel

[Tucker Taft]

Robert A Duff (bobduff@world.std.com) wrote:

: In article <JSA.97Jul18151414@alexandria.organon.com>,
: Jon S Anthony <jsa@alexandria.organon.com> wrote:
: >In article <EDHqKo.K52@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
: >
: >> >> In article <JSA.97Jul13164937@alexandria.organon.com>, 
: >> >> jsa@alexandria.organon.com says...
: >> >> 
: >> >> >    type Require is boolean range True..True;
: >> >> >...
: >> >> >
: >> >> >    Assert : Require := Complex_Precondition(X);
: >> 
: >> This isn't quite right, because RM-11.6 allows the check to be
: >> eliminated.
: >
: >Bob, could you clarify this?

: Suppose Complex_Precondition(X) returns False.  Normally, you would
: expect a range check on the assignment, and that would raise C_E.
: However, 11.6(5) says the implementation does *not* have to raise C_E,
: since *in the absence of raising it*, the result has no external effect. ...

The way I like to think about 11.6(5) is that if a range-check fails, the
expression returns a special "undefined" value (equivalent to "bottom"
in some formal languages).  The compiler can then perform its normal
"dead assignment"/"dead variable" elimination on uses of this "undefined" 
value.  

For example, if you have a local variable that is assigned some
value, but then never used again, many compilers will remove the
assignment, and parts of the evaluation of the expression that have
no side effects (failing a language-defined check is *not* considered
a side-effect -- its effect is captured entirely in the "undefinedness"
of the result).

The purpose of raising an exception like Constraint_Error as a result 
of a check failure is to prevent some undefined value from causing
some externally visible "junk" output.  If the undefined value
makes no contribution to external output, then its calculation can
be removed like any other piece of dead code.  On the other hand,
if the undefined value is used as input to some external effect (which
includes any output, assigning into a volatile variable, passing to an
imported subprogram, returning from the main subprogram, etc.), then
an exception is raised to prevent the bad value from producing a bad
external effect.

The simplest way to use this rule is to mark the target of an assignment
as "volatile."  Alternatively, create a subprogram that stores its 
parameter into a volatile global of range True .. True, or that bumps
some global error counter (which you ultimately print out).

Or use "pragma Assert" which I believe is supported in almost all
Ada 95 compilers.


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

Re: Safety-critical development in Ada and Eiffel

[Joe Gwinn]

I would comment that we designed a real safety-critical system, the
Microwave Landing System (now cancelled for the convenience of the
Government, in honor of GPS and WAAS), in a subset of Ada83.  (Ada95 was
not available at the time.)

However, there was a lot more to it than to say it was Ada:  We were
required to use a special safety-critical-code subset of Ada, which was
*sharply* smaller than Ada83.  (I no longer recall the details, but I
could dig them up, given a week or three.  It seems to me that it was a
commercial product.)

Perhaps aside from the strong typing, it was not clear just what was left
that was particular to Ada, or why one couldn't do the same radical
simplification to any language one might choose, to much the same effect.

So, I don't know that I buy the theory that Ada83 or Ada95 is the only
choice for safety-critical systems, as what survives isn't really either
language, and one can do the same surgery on any reasonable language. 
What makes it a safety language is the surgery, not the starting point.  

Sort of like Frankenstein's Monster.

Joe Gwinn

Re: Safety-critical development in Ada and Eiffel

[Robert S. White]

In article <gwinn-1007971853320001@dh5152077.res.ray.com>, gwinn@res.ray.com 
says...
   ...snip...
>However, there was a lot more to it than to say it was Ada:  We were
>required to use a special safety-critical-code subset of Ada, which was
>*sharply* smaller than Ada83.  (I no longer recall the details, but I
>could dig them up, given a week or three.  It seems to me that it was a
>commercial product.)
>
>Perhaps aside from the strong typing, it was not clear just what was left
>that was particular to Ada, or why one couldn't do the same radical
>simplification to any language one might choose, to much the same effect.
>
>So, I don't know that I buy the theory that Ada83 or Ada95 is the only
>choice for safety-critical systems, as what survives isn't really either
>language, and one can do the same surgery on any reasonable language. 
   ...snip...

  Sorry Joe I do not agree!  Even if you strip down Ada 83 to a small
subset you still benefit from a lot of the design requirements 
that went into the language.  What really are you alternatives?  C 
or Fortran?  Neither are strongly typed.  Modula 2 or Oberon?  Not 
very widespread.  Just _what_ is your alternative language of choice
(subsetted) for safty critical applications?  Methinks you protest 
too much.  Ada has worked out well for a number of years for safety
critical applications in avionics and other embedded real time control
applications.  What _IS_ the alternate _BETTER_ language of choice?

  I have been implementing software solutions in industry since 1978 
so I think I qualify as an equal curmudgeon to yourself as far is to
what works and what does not work.  No silver bullets, although a good
problem domain understanding, actual software _design_ with peer 
reviews, and software inspections with checklists, and finally
low level whitebox software module tests (along with final qual
tests to requirements) work best for safety-critical software.  Ada is
still an aid, IMO for the end safety-critical objective.  Eiffel has 
yet to prove its advantages to me.  I agree with Ken, most of the 
Eiffel type assertions can also be done in Ada.  Esp GNAT ada95.

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert S. White wrote:

:In article <gwinn-1007971853320001@dh5152077.res.ray.com>, gwinn@res.ray.com 
:says...
:   ...snip...
:>However, there was a lot more to it than to say it was Ada:  We were
:>required to use a special safety-critical-code subset of Ada, which was
:>*sharply* smaller than Ada83.  (I no longer recall the details, but I
:>could dig them up, given a week or three.  It seems to me that it was a
:>commercial product.)
:>
:>Perhaps aside from the strong typing, it was not clear just what was left
:>that was particular to Ada, or why one couldn't do the same radical
:>simplification to any language one might choose, to much the same effect.
:>
:>So, I don't know that I buy the theory that Ada83 or Ada95 is the only
:>choice for safety-critical systems, as what survives isn't really either
:>language, and one can do the same surgery on any reasonable language. 
:   ...snip...
:
:  Sorry Joe I do not agree!  

Well, you're both right. Joe is right is saying that when you strip out (read 
don't use) the powerful features of languages for safety-critical applications,
they start to look the same. You're also right in saying that what's left over
become the distinguishing features.

:Even if you strip down Ada 83 to a small
:subset you still benefit from a lot of the design requirements 
:that went into the language.  

Even more so with Eiffel because you're still have, among other things, the 
reliability/reuse enhancing facilities of:

  - Built-in, general purpose, inheritable contracts.
  - A rigorous, fine-grained encapsulation model.


:  I have been implementing software solutions in industry since 1978 
:so I think I qualify as an equal curmudgeon to yourself as far is to
:what works and what does not work.  No silver bullets, although a good
:problem domain understanding, actual software _design_ with peer 
:reviews, and software inspections with checklists, and finally
:low level whitebox software module tests (along with final qual
:tests to requirements) work best for safety-critical software.  Ada is
:still an aid, IMO for the end safety-critical objective.  Eiffel has 
:yet to prove its advantages to me.

All these things are good. Adding Design by Contract to them helps you even more.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Robert S. White wrote:
> 
> :In article <gwinn-1007971853320001@dh5152077.res.ray.com>, gwinn@res.ray.com
> :says...
> :   ...snip...
> :>However, there was a lot more to it than to say it was Ada:  We were
> :>required to use a special safety-critical-code subset of Ada, which was
> :>*sharply* smaller than Ada83.  (I no longer recall the details, but I
> :>could dig them up, given a week or three.  It seems to me that it was a
> :>commercial product.)
> :>
> :>Perhaps aside from the strong typing, it was not clear just what was left
> :>that was particular to Ada, or why one couldn't do the same radical
> :>simplification to any language one might choose, to much the same effect.
> :>
> :>So, I don't know that I buy the theory that Ada83 or Ada95 is the only
> :>choice for safety-critical systems, as what survives isn't really either
> :>language, and one can do the same surgery on any reasonable language.
> :   ...snip...
> :
> :  Sorry Joe I do not agree!
> 
> Well, you're both right. Joe is right is saying that when you strip out (read
> don't use) the powerful features of languages for safety-critical applications,
> they start to look the same. You're also right in saying that what's left over
> become the distinguishing features.
> 
> :Even if you strip down Ada 83 to a small
> :subset you still benefit from a lot of the design requirements
> :that went into the language.
> 
> Even more so with Eiffel because you're still have, among other things, the
> reliability/reuse enhancing facilities of:
> 
>   - Built-in, general purpose, inheritable contracts.
>   - A rigorous, fine-grained encapsulation model.

Actually, some of the Eiffel inheritance got stripped out in a previous
post,
as I recall. What was left of Eiffel looked a lot like Ada.

> 
> :  I have been implementing software solutions in industry since 1978
> :so I think I qualify as an equal curmudgeon to yourself as far is to
> :what works and what does not work.

I hate BS statements like this!

The thread clearly states, "Safety-critical development". Do you do
safety-critical systems in Eiffel? If so, please describe these systems.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:I hate BS statements like this!

Wow! I'm glad I didn't say it then! - it was Robert White. :)

As for your other comments, I hope to respond tomorrow. In the meantime, 
take a sedative. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

I wrote:

:2) Eiffel's contracts are stronger, more general, more flexible and more powerful
:   than in standard Ada. This doesn't mean Ada's contracting is useless by 
:   any means. It's a tribute to the designers of Ada83 that support for 
:   predefined contracts was included at the time it was designed. I'm 
:   disappointed, of course, that they were omitted from Ada95.
                                  ^^^^
This should read "Eiffel-like assertions".


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Kazimir Majorinc]

Eiffel is not safe language. Look for example Shang's article
Is a Cow an Animal? Somewhere on Net. Look at Ellipse CIrcle dilemma.
Should array of superclass be superclass of array of subclass? Noone
knows. Do you accept Liskov Substitution principle? Do you accept
derivation from abstract classes only? Noone knows.  Eiffel's assertions
are good, but it's like to drive motorcycle 250 km/hour and say that
helmet will help you.

For some of us, OO is not only suspect, but even wrong paradigm. It's
place is in laboratory, it is not good for mainstream programming, not
to mention safety. 

If you are interested primarily in safety, you should give up from OO, and
choose good old procedural paradigm. It is not far less powerfull, but it
is certenly safer. Ada 83 is maybe the best answer.  

Regards,
______________________________________________________________
        Kazimir Majorinc,  dipl. ing. of mathematics
 Faculty of Natural Sciences and Math, Uni of Zagreb, Croatia
mailto: kmajor@public.srce.hr    http://public.srce.hr/~kmajor  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Kazimir Majorinc wrote:
> 
> Eiffel is not safe language. Look for example Shang's article
> Is a Cow an Animal? Somewhere on Net. Look at Ellipse CIrcle dilemma.
> Should array of superclass be superclass of array of subclass? Noone
> knows. Do you accept Liskov Substitution principle? Do you accept
> derivation from abstract classes only? Noone knows.  Eiffel's assertions
> are good, but it's like to drive motorcycle 250 km/hour and say that
> helmet will help you.
> 
> For some of us, OO is not only suspect, but even wrong paradigm. It's
> place is in laboratory, it is not good for mainstream programming, not
> to mention safety.
> 
> If you are interested primarily in safety, you should give up from OO, and
> choose good old procedural paradigm. It is not far less powerfull, but it
> is certenly safer. Ada 83 is maybe the best answer.

I'm not sure I'd call Ada 83 "procedural." SPC calls it "object-based".

My personal experience is that Ada 83 objects are much better for
handing
complex safety-critical systems than procedural objects in languages
like
FORTRAN and JOVIAL. For very simple systems, I suspect it doesn't
matter.

As to whether full OO languages like Ada 95 introduce safety issues...
we'll
see.

> 
> Regards,
> ______________________________________________________________
>         Kazimir Majorinc,  dipl. ing. of mathematics
>  Faculty of Natural Sciences and Math, Uni of Zagreb, Croatia
> mailto: kmajor@public.srce.hr    http://public.srce.hr/~kmajor
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

[C/C++ groups removed]

Tucker Taft wrote:

::It is not so easy to take a language like Eiffel that is fundamentally 
::oriented toward dynamic storage allocation (and pervasive dynamic binding), ...

I responded:

:Eiffel implementations optimise a high percentage of dynamic calls to static 
:ones - 80-90%? Also, since the overhead of the calling mechanism is just part
:of the cost of making the call (the total cost includes execution of the body),
:the resultant penalty for default dynamic binding is reduced to 5-10% - 
:obviously not worth getting excited over, even for HRT systems.

If even this small overhead is unacceptable, you can force static binding
where necessary by freezing routines. Although you forgo the flexibility of
polymorphism, you can still take advantage of inheritance by virtue of Eiffel
synonyms - these allow you to declare a routine under different names. For an
HRT application, you can use a redefinable version for specialisation but in 
your system, call only the frozen version to force static binding.


Mike Stark wrote:

:Don Harrison wrote:

[...]

:> Both of these issues can be dealt with in Eiffel:
:> 
:>   1) Dynamic storage allocation - The solution here (as in Ada) is to use
:>      a pre-allocated memory pool for HRT parts of the system so eliminating
:>      the need for dynamic allocation under HRT conditions.
:
:Does this "pre-allocated memory pool" mean that you will know exactly
:what address
:each object's data will reside at, or merely that you dynamically
:allocate memory
:at initialization and do not dynamically allocate after initialization
:is complete?

The latter. You don't actually need to know *where* objects are allocated, 
merely that there is sufficient memory to allocate them.

:My experience with flight software people here at Goddard (and it is
:admittedly
:limited) is that they are very conservative about knowing *exactly*
:where
:everything is located in memory -- they want the equivalent of a FORTRAN
:common
:block, which can be achieved in Ada (or C++, to be fair) by [using aliases]...
:
:(the aliased keyword in Ada allows pointers to statically declared
:objects)

I suspect that you can also make an Eiffel reference access a statically
allocated object (expanded type) using a standard class (MEMORY? someone may 
wish to confirm this). There would certainly be no technical obstacle to 
providing this capability if it doesn't already exist enabling you to statically 
allocate whatever memory you require if that's what you want (as in your 
application domain). 


:I am interested in any contrary opinions, though, especially from people who
:actually
:have used Eiffel for safety critical systems.

Your probably unlikely to hear of any because most (including even the Eiffel 
community, unfortunately) seem to overlook its potential for RT systems.


Ken Garlington wrote:

:> 2) Eiffel's contracts are stronger, more general, more flexible and more
:powerful
:>    than in standard Ada. This doesn't mean Ada's contracting is useless
:by 
:>    any means. It's a tribute to the designers of Ada83 that support for 
:>    predefined contracts was included at the time it was designed. I'm 
:>    disappointed, of course, that they were omitted from Ada95.
                                    ^^^^

:I'm not sure what was in Ada83 that was omitted in Ada95; 

Sorry, this should have been "Eiffel-like assertions".


:however, I have noticed
:that Eiffel examples posted in various places tend to have assertions that
:are
:fairly simple in nature (range checks), etc that are directly representable
:in Ada.

Maybe general assertions are more common than you imagine. However, I agree 
that range constraints are roughly covered by Ada subtypes. I use them liberally
for just that purpose.

:Those that aren't tend to be easy to do with good Ada design using
:exceptions ...

Can you clarify what you mean here? If you mean that you can emulate general
assertions in Ada by testing assumptions and raising exceptions when violated,
I agree. In fact that's exactly the style of Ada coding I write these days and
it works great! I routinely apply preconditions, postconditions and check 
instructions to all my code now. Here's an example from some code for managing 
analysis of Sonar tracks (Please excuse the capitals - it's the convention here 
:( ):

  -- ==================================================================
  --
  -- PROCEDURE NAME : REMOVE_TRACK_FROM_ANALYSIS
  --
  --    DESCRIPTION : Remove track from analysis.
  --
  --   Precondition : The specified track is under analysis.
  --  Postcondition : The track is not under analysis and an empty
  --                  position exists.
  --                  
  -- ==================================================================
  
  procedure REMOVE_TRACK_FROM_ANALYSIS (TRACK_INDEX : SAT.TRACK_INDEX_TYPE) is

    POSITION : POSITION_TYPE;
    ANALYSIS_POSITION : POSITION_DATA_TYPE;

  begin
    if SA.ASSERTIONS_ON and then not UNDER_ANALYSIS (TRACK_INDEX) then
      raise SA.PRECONDITION_ERROR;
    end if;

    -- Get it's position.
    POSITION := POSITION_OF_TRACK (TRACK_INDEX);

    -- Set data to defaults.
    ANALYSIS_POSITION := DEFAULT_POSITION_DATA;

    -- Update the tote position data.
    POSITION_DATA(POSITION) := ANALYSIS_POSITION;

    if SA.ASSERTIONS_ON and then (UNDER_ANALYSIS (TRACK_INDEX) 
      or else not ANY_POSITION_VACANT) then
      raise SA.POSTCONDITION_ERROR;
    end if;

  exception
    when others =>
      SEL.LOG_ERROR(
        EXCEPT_STRING => CE.EXCEPTION_NAME,
        PACKAGE_NAME  => PACKAGE_NAME,
        SUBPROG_NAME  => "REMOVE_TRACK_FROM_ANALYSIS" );

      raise;

  end REMOVE_TRACK_FROM_ANALYSIS;


It's not quite as good though because you miss out on inheriting contracts and
it's a little messy to read because there are no distinct assertion clauses
to syntactically separate them from the routine body as in Eiffel.


:I think I'd like to see more cases where Eiffel is used in "hard" real-time
:safety-critical
:systems, and in particular some years of experience where Eiffel accurately
:detects -
:AND CORRECTS - for faults that are not routinely handled in equivalent Ada
:systems
:developed by the same vendor. 

Correct me I misunderstand you.. Are you wondering whether contracting 
helps you to identify more bugs? I can offer my own experience which has 
firmly convinced me of this.

As an example, in our simulation, we have a vehicles object. This is implemented 
as an array of records (they should be variant records discriminated 
on validity, however..). Vehicles are activated and deactivated during the 
course of a "game" by setting a validity flag. I added preconditions to ensure
that other attributes (such as heading) were not queried unless the vehicle was 
active. These simple checks caught a whole bunch of errors that may otherwise 
have gone unnoticed. In the absence of such a check, the problem may only 
have come to our attention if spurious behaviour was observed. In contrast,
the exceptions raised were hard to overlook and ignore and identified these 
problems closer to their source. Consequently, when we (a team of 5) recently 
reached the end of a 5 month long development effort of incremental coding 
and integration testing, the parts of the system that used contracting work 
flawlessly apart from problems resulting from misinterpretation of requirements.

The success was due not only to contracting (other factors such as good design
and some good developers also played a part), but contracting definitely 
contributed significantly.


:I think that experience is already starting
:to emerge with
:respect to Ada vs. older languages in this domain, particularly for Ada's
:static checks.

I agree. Static typing is great for reliability. Complementing it with 
inheritable contracts is even better. 


:> 3) Named parameter association is not necessary with systematic, sensible
:naming.
:>    I confess to still using them in Ada (through force of habit) but
:usually 
:>    find that my formal and actual names are identical. 
:
:Not our experience at all, particularly for commonly-used routines within a
:system. Named
:parameter association is extremely useful, in my experience.

Yes, I guess it's quite handy in many cases. I'm not averse to using it under 
some circumstances.

:> Using named association 
:>    under such circumstances only serves to clutter the software text.
:
:Fortunately, in Ada, you can only use named notation where you want.

Yes, making it optional is a good idea.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[James Graves]

In article <ED5AGp.5MJ@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>
> I suspect that you can also make an Eiffel reference access a statically
> allocated object (expanded type) using a standard class (MEMORY? someone may 
> wish to confirm this). There would certainly be no technical obstacle to 
> providing this capability if it doesn't already exist enabling you to 
> statically allocate whatever memory you require if that's what you want 
> (as in your application domain). 
>

You are not allowed to make a reference to an expanded object in Eiffel,
because of the information hiding principal.  To be able to diddle with
another object's internal data could easily violate the class
invariant.

That's why Mr. Meyer doesn't like Java's ability to perform direct
assignments of an object's data fields (features in Eiffel terms):

    int x;
    Platoon platoon_a;
    x := 50;
    platoon_a.size := x;         <- Could be an invariant violation
				    if Platoons aren't supposed to have
				    that many soldiers.

It could be the programmer should have used platoon_a.set_size(x) which
(presumably) would check the size of it's argument.  Of course in Java,
you can just not export the size variable at all.  Then you would need
to create a function like:

    int get_size()
    {
	return size;
    }

for every variable that clients of the Platoon class should be able to
see (and not set directly).  Does this remind anyone of Smalltalk?

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As for using Eiffel in a Hard Real Time (HRT) situation, when dynamic
allocation/deallocation of memory is not desired, I suppose you could
create all the needed objects at the start, stick them in a hashtable 
(or array), and then turn off garbage collection.  Then search through
all the rest of the code for creation instructions (!!a.make or such),
and a.clone() procedures.

As you run the system, look at it's memory size after the start, and if
it ever grows, you know you've missed something.  A nice compiler option
would be to report how many dynamically bound calls there were, so you
could eliminate those too if you really wanted.  (ISE claims that even
dynamically bound calls are dispatched in constant time, and I bet other
Eiffel vendors have picked this up too.)

Since learning about the proposed concurrency mechanism in Eiffel, I
would feel more secure using it instead of some threads package for C.
If implemented correctly (which only needs to be done once), it
elliminates a lot of the effot and the contention/locking problems of
parallel programming.


Later,

James Graves

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

James Graves writes:

:In article <ED5AGp.5MJ@syd.csa.com.au>,
:Don Harrison <donh@syd.csa.com.au> wrote:
:>
:> I suspect that you can also make an Eiffel reference access a statically
:> allocated object (expanded type) using a standard class (MEMORY? someone may 
:> wish to confirm this). There would certainly be no technical obstacle to 
:> providing this capability if it doesn't already exist enabling you to 
:> statically allocate whatever memory you require if that's what you want 
:> (as in your application domain). 
:>
:
:You are not allowed to make a reference to an expanded object in Eiffel,
:because of the information hiding principal.  To be able to diddle with
:another object's internal data could easily violate the class
:invariant.

Oops! Quite true. 

I agree the technique you suggest is better.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> If even this small overhead is unacceptable, you can force static binding
> where necessary by freezing routines.
> Although you forgo the flexibility of
> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
> synonyms - these allow you to declare a routine under different names.

But I can do this in Ada, as well, so I don't see the benefit.

 :Does this "pre-allocated memory pool" mean that you will know exactly
> :what address
> :each object's data will reside at, or merely that you dynamically
> :allocate memory
> :at initialization and do not dynamically allocate after initialization
> :is complete?
> 
> The latter. You don't actually need to know *where* objects are allocated,
> merely that there is sufficient memory to allocate them.

Actually, in my systems, I do need to know where they are allocated, so
that
I can examine them from the hideously crude display in the cockpit
during
troubleshooting.

> Maybe general assertions are more common than you imagine. However, I agree
> that range constraints are roughly covered by Ada subtypes. I use them liberally
> for just that purpose.

Maybe, but again, I would like to see how these complex assertions are
used. Again,
the code I've seen to date doesn't seem to use them that much.

> Correct me I misunderstand you.. Are you wondering whether contracting
> helps you to identify more bugs? I can offer my own experience which has
> firmly convinced me of this.

Contracting definitely identifies more bugs. However, my concern with
Eiffel
assertions (and Ada assertions, for that matter) is that, once raised,
it's
not always clear what to do about them. In a safety-critical system such
as
we build, you can't just generate a core dump, or ask the user what to
do next.
You have to generate a correct response to the assertion failure, and
you have
to do it very quickly. Static assertion checks, of course, can be
detected and
corrected during development, which is why I like Ada's strong static
type checking.

There is a school of thought that says to add in assertions, test the
system, and
then remove/suppress the exceptions. I have seen too many cases of code
that works
with the assertions active, and then breaks (due to timing differences,
or more
likely code generation errors) to have much confidence in this approach.

Another consequence of using assertions is that you have to develop and
test the
assertions. As a result, you need confidence that the benefits of the
assertions
outweigh the dilution of your test effort. One of the advantages of
Ada's simpler
approach (at least, it seems simpler to me) to simple
pre/post-conditions (range
checks in particular) is that the cost of adding them is somewhat
reduced. However,
in both languages, overuse of assertions may be just as bad as underuse.

(As you can tell, I'm somewhat of an assertions heretic. However, I will
say that
for non-real-time, non-safety-critical systems, they are outstanding. My
tool code
is lousy with them.)

> Consequently, when we (a team of 5) recently
> reached the end of a 5 month long development effort of incremental coding
> and integration testing, the parts of the system that used contracting work
> flawlessly apart from problems resulting from misinterpretation of requirements.

Most of the problems we see in formal testing are from misinterpretation
of
requirements - which is another issue I have with assertions as a magic
safety wand.
Of course, Bertand Meyer's Eiffel website insists that even
misinterpretation of
requirements (Ariane V) will be a problem no longer when Eiffel is used!
:)

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> If even this small overhead is unacceptable, you can force static binding
:> where necessary by freezing routines.
:> Although you forgo the flexibility of
:> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
:> synonyms - these allow you to declare a routine under different names.
:
:But I can do this in Ada, as well, so I don't see the benefit.

I'm not saying there is any extra benefit - merely that you don't have to 
wear the overhead of dynamic binding if you're desperate to maximise efficiency.
Tucker mentioned that overhead. I'm saying it isn't an issue.

BTW, how do call a procedure under different names in Ada?


: :Does this "pre-allocated memory pool" mean that you will know exactly
:> :what address
:> :each object's data will reside at, or merely that you dynamically
:> :allocate memory
:> :at initialization and do not dynamically allocate after initialization
:> :is complete?
:> 
:> The latter. You don't actually need to know *where* objects are allocated,
:> merely that there is sufficient memory to allocate them.
:
:Actually, in my systems, I do need to know where they are allocated, so
:that
:I can examine them from the hideously crude display in the cockpit
:during
:troubleshooting.

That *is* hideously crude (and brings back some bad memories). Depending on how
crude you mean, maybe a primitive tool could give you a map of where objects get 
put in memory. If you mean incredibly crude, use non-reference (expanded in 
Eiffel) types and use a linker-generated memory map.


:> Maybe general assertions are more common than you imagine. However, I agree
:> that range constraints are roughly covered by Ada subtypes. I use them liberally
:> for just that purpose.
:
:Maybe, but again, I would like to see how these complex assertions are
:used. 

You would use them anywhere that a piece of code makes assumptions. For example,
to help avoid the Ariane fiasco, include contracts in the INS(?) that specify 
Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
you apply Ariane 5 dynamics to it.

:Again, the code I've seen to date doesn't seem to use them that much.

If you're looking in Ada code, you're looking in the wrong place because few
Ada developers recognise there are additional benefits from using them in 
addition to static typing and the predefined contracts already in Ada 
(the conditions under which predefined exceptions - eg. Constraint_Error - 
are raised).

Static typing gives you static contract checking. Assertions (predefined and
user-defined give you dynamic contract checking *during development*. What 
most Ada software engineers miss out on is the user-defined variety which 
bring a non-trivial benefit to reliability and reuse.


:> Correct me I misunderstand you.. Are you wondering whether contracting
:> helps you to identify more bugs? I can offer my own experience which has
:> firmly convinced me of this.
:
:Contracting definitely identifies more bugs. However, my concern with
:Eiffel
:assertions (and Ada assertions, for that matter) is that, once raised,
:it's
:not always clear what to do about them. 

They are only turned on during development, so what you do is fix the underlying
problem which is usually not difficult to find if you've used them systematically.
Even if you haven't (I was the only one of a team of 5 using them in our recent
development cycle), they still tell you more than you would otherwise be told.

Good design complemented by static typing and Design by Contract is unbeatable, 
IME.


:In a safety-critical system such
:as
:we build, you can't just generate a core dump, or ask the user what to
:do next.
:You have to generate a correct response to the assertion failure, and
:you have
:to do it very quickly. 

Right. However, only an incorrect program will raise assertion violations at
runtime. As you systematically identify and fix the errors causing them during
development, you can turn assertions off with confidence when the system 
goes live. Then, any errors you may have missed will be handled by exception
handlers in the usual way.
 
:Static assertion checks, of course, can be
:detected and
:corrected during development, which is why I like Ada's strong static
:type checking.

I agree completely. Static typing is great but it isn't the *whole* story.


:There is a school of thought that says to add in assertions, test the
:system, and
:then remove/suppress the exceptions. I have seen too many cases of code
:that works
:with the assertions active, and then breaks (due to timing differences,

Yes, timing *is* something to be concerned about when applied to realtime 
systems. That's why I suggested not using assertions in the hard realtime
threads of a process. BTW, software designed using DBC may actually run *faster*
than code without it because you get to strip out all the defensive validity
checks. You have already ascertained during development that operations are
called in valid contexts so you don't have to check the context.

:or more
:likely code generation errors) to have much confidence in this approach.

If that's a problem, you need to get your vendor to clean their act up.


:Another consequence of using assertions is that you have to develop and
:test the
:assertions. 

Correct. My initial reaction when I started using them was "Gee, I've got to
do this extra work on top of writing the "real" code! However, I found I was 
spending about a third of the time integrating compared with my colleagues
which meant I was saving time overall and producing more reliable code to boot.


:As a result, you need confidence that the benefits of the
:assertions
:outweigh the dilution of your test effort. 

IME, they do.

:One of the advantages of
:Ada's simpler
:approach (at least, it seems simpler to me) to simple
:pre/post-conditions (range
:checks in particular) is that the cost of adding them is somewhat
:reduced. 

I disagree. It takes me about the same amount of time to specify an Ada
subtype as it does to specify a more general assertion. Even if the general 
assertion is a function, I would more than likely need to write it anyway so
would have expended the effort anyway.


:However,
:in both languages, overuse of assertions may be just as bad as underuse.

It is possible to overuse them but 99% of developers err on the othger side. :)


:(As you can tell, I'm somewhat of an assertions heretic. 

That's fine but have a go at using them where appropriate. I'm sure you'll 
become convinced.

:However, I will
:say that
:for non-real-time, non-safety-critical systems, they are outstanding. My
:tool code
:is lousy with them.)
:
:> Consequently, when we (a team of 5) recently
:> reached the end of a 5 month long development effort of incremental coding
:> and integration testing, the parts of the system that used contracting work
:> flawlessly apart from problems resulting from misinterpretation of requirements.
:
:Most of the problems we see in formal testing are from misinterpretation
:of
:requirements - which is another issue I have with assertions as a magic
:safety wand.

No use of assertions will stop you misinterpreting requirements. They're not 
a magic wand but they *will* help you remove a class of errors you would 
otherwise miss.


:Of course, Bertand Meyer's Eiffel website insists that even
:misinterpretation of
:requirements (Ariane V) will be a problem no longer when Eiffel is used!

Come on. He's not saying that.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Wes Groleau]

> You would use them anywhere that a piece of code makes assumptions. For example,
> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> you apply Ariane 5 dynamics to it.

Here we go again with this myth.  Probably won't help, but I'll say 
one more time what others said over and over: telling people to 
assert or document everything pertinent will NOT cure the failure 
to recognize what's pertinent!!  Or in your own words:

> No use of assertions will stop you misinterpreting requirements. 

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Wes Groleau wrote:
> 
> > You would use them anywhere that a piece of code makes assumptions. For example,
> > to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> > Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> > you apply Ariane 5 dynamics to it.
> 
> Here we go again with this myth.  Probably won't help, but I'll say
> one more time what others said over and over: telling people to
> assert or document everything pertinent will NOT cure the failure
> to recognize what's pertinent!!  Or in your own words:
> 
> > No use of assertions will stop you misinterpreting requirements.

Give it up. Until the end of time, Eiffel advocates will be using this
example showing why DBC/Eiffel is better than Ada. If some of the Ada
heavyweights had put up a fuss (a letter to IEEE, for example), we could
have nipped this in the bud. However, it's too late now.

> 
> --
> ----------------------------------------------------------------------
>     Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
> Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
> 
> Don't send advertisements to this domain unless asked!  All disk space
> on fw.hac.com hosts belongs to either Hughes Defense Communications or
> the United States government.  Using email to store YOUR advertising
> on them is trespassing!
> ----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Inserted here is the original context of my statement: general assertions...

:> Maybe general assertions are more common than you imagine. However, I agree
:> that range constraints are roughly covered by Ada subtypes. I use them liberally
:> for just that purpose.
:
:Maybe, but again, I would like to see how these complex assertions are
:used. 

Wes Groleau wrote:

:> You would use them anywhere that a piece of code makes assumptions. For example,
:> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
:> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
:> you apply Ariane 5 dynamics to it.
:
:Here we go again with this myth.  Probably won't help, but I'll say 
:one more time what others said over and over: telling people to 
:assert or document everything pertinent will NOT cure the failure 
:to recognize what's pertinent!!  

If you read carefully what I wrote in the context that I wrote it, you'll notice 
I'm not suggesting it will. I'm simply giving an *example* of a general 
assertion. Nowhere in my statement will you find any suggestion that you can 
formulate an assertion reflecting an assumption if you haven't first identified 
the assumption. No friend of logic would claim anything so outrageous.


So, just to make this clearer, what are the steps involved in proper use of 
contracting? They are:

1) Identify the assumptions.
2) Code the assumptions as assertions.
3) Validate that the coded assertions are always satisfied (and by implication,
   the assumptions they represent) by performing rigorous testing.

Note that each step depends on the previous one. No Eiffel software engineer
will tell you otherwise. There was a high degree of miscommunication during
the interminable "Ariane" thread, so it's not surprising that you were left
thinking that some believed the myth you describe.

FWIW, some participants in that thread were a little naive, IMO, in regarding
the Ariane article as a technical document. Its lack of *detailed* technical
content readily eliminates such an interpretation and exposes it as a marketing 
tool. IMO, some of the comments made in it were at best misleading or expressed
unsubstantiated (albeit valid) opinion. For the document to have any technical
credibility, it would need to be more in-depth, IMO. If you take the trouble to 
read any of Bertrand Meyer's technical papers, you will agree this was not 
one of them.


Now, having dealt with what I didn't mean by the quoted statement, :( 
can we get on to what I *did* mean? 

I've already said I was giving an example of a general assertion in the Ariane situation. Implied is the fact that they would have to be used in conjunction 
with established software engineering practice. 
 
What I *didn't* say but will say now is that using Design by Contract (read 
*disciplined* use of assertions) to complement testing will not only identify 
more errors but make them more obvious. More than likely the Ariane bug would
have been picked up by traditional means (since it's fairly obvious) but in 
the event that it wasn't, it would certainly have been identified if 
the assumption was identified and coded as an assertion.

:Or in your own words:
:
:> No use of assertions will stop you misinterpreting requirements. 

True, though irrelevant to the point I wasn't making. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> More than likely the Ariane bug would
> have been picked up by traditional means (since it's fairly obvious) but in
> the event that it wasn't, it would certainly have been identified if
> the assumption was identified and coded as an assertion.

...and the same traditional means (testing to the actual Ariane V data)
were used to test the system (otherwise the assertion would never have
been exercised). Thus:

1. If the assertion was not identified and coded as an assertion, but
traditional means were used, the problem would have been discovered.

2. If the assertion had been identified and coded as an assertion, but
traditional means were NOT used, the problem would NOT have been
discovered.

So, since traditional methods were required anyway, how did adding the
assertion (either the Ada "Operand_Error" or your Eiffel equivalent)
help for this example?

Meyer et. al. argues that, if the system was written in Eiffel, that
the assertion would have been added despite the lack of foundation for
doing so in the specification, and that reviews of the code would have
found the inconsistency between the code and specification, causing the
designers to ask the specification writers why they thought the Ariane V
profile was the same as the Ariane IV. Thus, even without the testing,
the Eiffel system would have uncovered the fault. My argument is that
no designer of a non-trivial safety-critical software system could be
expected to either (a) have such an all-encompassing knowledge of the
total platform to either write or analyze such a complex and subtle
assertion or (b) be willing to add assertions willy-nilly with no basis
in the specification (extranous code being identified as a potential
safety issue in more than one certification scheme).

(As an amusing aside, the defenders of the Eiffel faith were reduced to
calling my objections "casuistry," or using an inappropriate specific
case to prove a general statement. This argument, of course, is using
a specific case to prove a _specific case_. One could argue that the
Eiffel paper produced by Meyer et. al. was a better definition of
casuistry, however!)

> 
> :Or in your own words:
> :
> :> No use of assertions will stop you misinterpreting requirements.
> 
> True, though irrelevant to the point I wasn't making. :)

Not at all irrelevant, unless you claim that assertion writing
is not coupled to requirements (which is a very dangerous claim!).
If you look at failures in safety-critical aerospace software systems
(and I've done more than one study on this),  they tend to be
requirements-driven (e.g. F-18, YF-22, Gripen, Ariane V). More than
one controlled N-version academic study has shown this as well. (One
of the best was where multiple teams implemented a set of flight
control laws, using a basic safety-critical software development
process along the lines of DO-178. There was only one common
fault among all of them - a period in the requirements had been
misinterpreted as a comma due to the poor quality of the paper
version of the control laws!)

You could argue that assertions make the process of eliminating
design faults easier, thus allowing your finite test time to
focus on requirements issues earlier. However, I've talked to
people who build safety-critical aerospace systems (and also read
Safeware,
et. al.) and those kind of issues are usually resolved fairly
quickly in *any* good safety-critical software development process.
There may be some benefit to assertions in this environment, but
it's pretty small when measured against the potential risks.

Again, for a non-safety-critical system, where there may be a
higher proportion of design faults, then you probably do see a
larger benefit (I know I do) for dynamic assertions. For
safety-critical systems that can fail-safe, vs. those that must
fail-operate, I could also see some benefits (although that
class of systems seems to be shirnking every day). However,
beware casuistry! :)

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Ken says

<<Meyer et. al. argues that, if the system was written in Eiffel, that
the assertion would have been added despite the lack of foundation for
doing so in the specification, and that reviews of the code would have
found the inconsistency between the code and specification, causing the
designers to ask the specification writers why they thought the Ariane V
profile was the same as the Ariane IV. Thus, even without the testing,
the Eiffel system would have uncovered the fault. My argument is that
>>


In fact the assertion *was* present in the Ada code, in the form of
a language specified check. The claim that somehow the programmer would
have noticed the assertion in Eiffel, while missing it in Ada, is entirely
bogus in my view. This is just a case of waffly language advocacy without
any substance at all.

By the way, does Eiffel have fixed-point types? If not, presumably the
entire code would have been obscured by manual scaling ... And if you
think you can add fixed-point types by simply defining packages, think
again (and take a look at the exp_fixd unit in GNAT to get an idea of
what you are talking about :-)

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <dewar.869066151@merv>, dewar@merv.cs.nyu.edu says...
>
>Ken says

>In fact the assertion *was* present in the Ada code, in the form of
>a language specified check. The claim that somehow the programmer would
>have noticed the assertion in Eiffel, while missing it in Ada, is entirely
>bogus in my view. This is just a case of waffly language advocacy without
>any substance at all.

Whilst I don't agree with Meyer that Eiffel would probably have prevented
the Ariane crash, he does have a point.

The thing is that in Eiffel the assertions are not just a run-time error
detection mechanism, they are also a documentation and specification
mechanism.  The Ada assertion was invisible because it was buried in the
implementation of the routine that failed.  An equivalent Eiffel routine
(if it were correct) would have had the assertion in its interface, and
so on up to the top level of the software package under discussion.  So
anyone reusing the package would have seen the assertion.  The Inquiry
specifically commented that the Ada assertion was buried so deeply that
it was effectively invisible to any review.

Where this argument falls down, I'm afraid, is that the package did not
receive its data from another software package, but from a hardware
sensor.  At this point the whole idea breaks down.  A pity.

>By the way, does Eiffel have fixed-point types? If not, presumably the
>entire code would have been obscured by manual scaling ...

No, it does not have fixed point types.  And I agree that they cannot
easily be added by library classes.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Stuart Palin]

paul.johnson@gecm.com (Paul Johnson) wrote:

>The thing is that in Eiffel the assertions are not just a run-time error
>detection mechanism, they are also a documentation and specification
>mechanism.  The Ada assertion was invisible because it was buried in the
>implementation of the routine that failed.  An equivalent Eiffel routine
>(if it were correct) would have had the assertion in its interface, and
>so on up to the top level of the software package under discussion.  So
>anyone reusing the package would have seen the assertion.  The Inquiry
>specifically commented that the Ada assertion was buried so deeply that
>it was effectively invisible to any review.

I am not at all convinced by this Paul, in our experiences with SPARK,
where formal specifications are hoisted up through the program structure
revealing dependencies of lower level routines it is all too easy to end
up with an unmanageable number of annotations (assertions).  This means
that trying to find a possible risk like the Ariane remains impractical
using this technique since it is like looking for the proverbial needle
in a haystack.

This sort of problem would seem to be exacerbated if everyone is creating
assertions for every possible thing that could go wrong.

--
Stuart Palin
Consultant Engineer
Flight Systems Division (Rochester)
GEC Marconi Avionics Ltd
[usual disclaimers to protect the company]

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <5qkun1$35r@gcsin3.geccs.gecm.com>, stuart.palin@gecm.com says...

(in reply to my argument that Eiffel assertions are propogated up
through the structure)

>I am not at all convinced by this Paul, in our experiences with SPARK,
>where formal specifications are hoisted up through the program structure
>revealing dependencies of lower level routines it is all too easy to end
>up with an unmanageable number of annotations (assertions).

In most Eiffel code this is not a problem because the classes implement
abstractions, and the assertions relate to those abstractions.

However I can certainly believe that in numerical computation with 
subranges (which in practice means anything except bignums), you get
all sorts of messy problems of the sort that Stuart describes.  I 
therefore conceed the point.

Most programmers can simply ignore arithmetic overflow issues.  Safety 
critical people can't.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ian Rae]

Stuart Palin wrote:
> 
> I am not at all convinced by this Paul, in our experiences with SPARK,
> where formal specifications are hoisted up through the program structure
> revealing dependencies of lower level routines it is all too easy to end
> up with an unmanageable number of annotations (assertions).  This means
> that trying to find a possible risk like the Ariane remains impractical
> using this technique since it is like looking for the proverbial needle
> in a haystack.

Good point; assertions tend to be used for both interface and
implementation
assumptions.

However, assertions have the nice property of playing two roles: (a) as
documentation in the source code, and (b) as run-time checks.  The
needle
that can't be seen will be identified when it jams up the baler machine.
This, of course, assumes you're making very small bales (ie. doing very 
rigorous testing).

--Ian Rae
Senior Systems Developer
Nortel IDEAS CTI Group

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <5qklt1$4el$2@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:

> Whilst I don't agree with Meyer that Eiffel would probably have prevented
> the Ariane crash

Agreed, :-)

, he does have a point.

No, he does not.  Well, actually he does - editors can be fooled into
passing off simple advertising for real articles.


> The thing is that in Eiffel the assertions are not just a run-time error
> detection mechanism, they are also a documentation and specification
> mechanism.  The Ada assertion was invisible because it was buried in the
> implementation of the routine that failed.  An equivalent Eiffel routine
> (if it were correct) would have had the assertion in its interface, and
> so on up to the top level of the software package under discussion.  So
> anyone reusing the package would have seen the assertion.  The Inquiry
> specifically commented that the Ada assertion was buried so deeply that
> it was effectively invisible to any review.

The problems with this view are truly overwhelming.  It's hard to even
know how to begin or what to say in this sort of informal setting.

Here's a sampling:

1. The sort of "assertion" in this specific case could have been
explicitly coded as for the "equivalent Eiffel routine".

2. This level of assertion (range constraint) could be specified in
the interface of the routine.

3. This level of assertion would be inherited if any types were
derived from the type specifying it (just like in Eiffel).

4. So, for this case, Eiffel brings absolutely nothing to the table
that wasn't readily available to the Ada programmers.  Nothing.  Zero.
Nada.  Zilch.

5. The engineers and programmers knew all about this capability.  In
fact such an explicit assertion with an attendant exception handler
was even in place at one point.

6. The engineers concluded that _for the context of intended use_
(Ariane IV launches) this condition _could not occur_ unless the
_physical_ system had catestrophically failed.

7. Like _good_ engineers, this therefore _useless_ explicit check was
removed in order to free up some cycles that could be used on
something that _was_ worth processing.

8. Such contextual semantics of intended use settings are extremely
problematic to codify using standard formal methods (assertions,
functional representation, etc.  things like Z, LARCH, ZD, etc.).
There is even reason to believe that this is not even _possible_, let
alone practical.

9. For some reason, many "formal method advocates" still don't get
this - despite 15+ years of overwhelming evidence to the contrary.
This obstinacy is reminescent of the GOFAI camp who thought all you
had to do to get intelligence was hang a frame system (or some other
such symbolic representation) off an NL parser.  There was a lot of
"and Bob's your Uncle" talk coming out of them too.

10. Setting reason aside and attempting to annotate "components" with
such ancillary semantic information just results in huge amounts of
difficult to manage and typically irrelevant information.  The result
is the usual "information overload" which can actually tend to
_obscure_ real problems.

11. Even trying to come up with the "correct" annotations apriori is
an extremely suspect activity.  Any given context of use is so
overwhelming complex and multifaceted, that trying to codify it by
means of such one dimensional micro level detail is a lost cause.
This is a lesson that FMs would be wise to take from the knowledge
representation school of hard knocks.

12..oo, and on and on...


> Where this argument falls down, I'm afraid, is that the package did not
> receive its data from another software package, but from a hardware
> sensor.  At this point the whole idea breaks down.  A pity.

This doesn't even scratch the surface of why this view is bogus.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Paul Johnson wrote:
> Where this argument falls down, I'm afraid, is that the package did
> not
> receive its data from another software package, but from a hardware
> sensor.  At this point the whole idea breaks down.  A pity.

Not really. Just wrap the sensor in a class that has as its main feature
a routine read_out that returns the sensor's value. The postcondition of
read_oud should include a condition on the range of possible values.

If the sensor is changed to give a larger range of possible values,
you'll immediately see that the postcondition no longer holds, and
correct the software wherever read_out is called.

This doesn't make totally sure that the error would have been prevented,
but it wouldn't have happened in this way (and that's the best we can
hope for anyway).
Besides, we haven't seen what glitches are likely to happen in Eiffel.
As Don said, the Ariane-5 paper is more marketing than technical.

> >By the way, does Eiffel have fixed-point types? If not, presumably
> the
> >entire code would have been obscured by manual scaling ...
> 
> No, it does not have fixed point types.  And I agree that they cannot
> easily be added by library classes.

That doesn't make much of a difference. The routines have to be
implemented, wether in the compiler or as a library.

And, yes, I'd definitely like to see them in Eiffel. The heritage of the
compile-to-C strategy is showing here...

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert Dewar wrote:

:By the way, does Eiffel have fixed-point types? If not, presumably the
:entire code would have been obscured by manual scaling ... And if you
:think you can add fixed-point types by simply defining packages, think
:again 

I think you're mistaken. I don't see any reason why they couldn't be added 
in much the same way as classes INTEGER and REAL. They could even be implemented
by wrapping around Ada fixed-point types. :)

What specifically do you think is the problem? If you post details, we can 
comment.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert Dewar wrote:

:In fact the assertion *was* present in the Ada code, in the form of
:a language specified check. 

Correct. This check (for a constraint_error) is a predefined assertion.

:The claim that somehow the programmer would
:have noticed the assertion in Eiffel, while missing it in Ada, is entirely
:bogus in my view.

In the absence of software engineering (as was the case here where testing 
meant launching), I think you're right. The full value of Design by Contract 
is best realised when accompanied by more traditional software engineering 
practice. The two then complement each other - one doesn't obviate the other.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Robert I. Eachus]

In article <33CBBF4B.7BAF@pseserv3.fw.hac.com> Wes Groleau <wwgrol@pseserv3.fw.hac.com> writes:

  > Here we go again with this myth.  Probably won't help, but I'll say 
  > one more time what others said over and over: telling people to 
  > assert or document everything pertinent will NOT cure the failure 
  > to recognize what's pertinent!!

  True, but that didn't apply to the Ariane 5 case.  If you resuse
software in an environment with very different requirements, and you
don't do anything validate the code against the new requirements and
in fact, don't do with the code--not even recompile it--and you don't
do any testing--to old or new requirements--nothing with the possible
exception of unadulterated good fortune can save you from the effects
of your blunders.

  The Ariane 4 code was provably correct and acted in accordance with
its design specification.  However, when used in an Ariane 5, that
spec effectively said, "Destroy the stack at T+38 seconds, but send
real good diagnostic data while doing it!"  (Actually, they had some
good fortune.  A gust of wind sooner could have caused the same
catastophe closer to the ground, where the likelihood of fatalities
would have been much higher.)
--

					Robert I. Eachus

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

Re: Safety-critical development in Ada and Eiffel

[W. Wesley Groleau x4923]

>   > one more time what others said over and over: telling people to
>   > assert or document everything pertinent will NOT cure the failure
>   > to recognize what's pertinent!!
> 
>   True, but that didn't apply to the Ariane 5 case.  If you resuse
> software in an environment with very different requirements, ....

Well, IMHO, a difference in requirements is pertinent, and being 
told there is no difference is very nearly failing to recognize 
something pertinent!  :-)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> If even this small overhead is unacceptable, you can force static binding
> :> where necessary by freezing routines.
> :> Although you forgo the flexibility of
> :> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
> :> synonyms - these allow you to declare a routine under different names.
> :
> :But I can do this in Ada, as well, so I don't see the benefit.
> 
> I'm not saying there is any extra benefit - merely that you don't have to
> wear the overhead of dynamic binding if you're desperate to maximise efficiency.
> Tucker mentioned that overhead. I'm saying it isn't an issue.

But you also said that it was required to use that part of Eiffel
inheritance not
available in Ada. In this statement, you seem to be saying that if I
want an
efficient safety-critical system (which I always do), I have to give us
some of
that extra inheritance. Do I need the full Eiffel inheritance model, or
don't I?

> 
> BTW, how do call a procedure under different names in Ada?

Via the "rename" statement.

> 
> : :Does this "pre-allocated memory pool" mean that you will know exactly
> :> :what address
> :> :each object's data will reside at, or merely that you dynamically
> :> :allocate memory
> :> :at initialization and do not dynamically allocate after initialization
> :> :is complete?
> :>
> :> The latter. You don't actually need to know *where* objects are allocated,
> :> merely that there is sufficient memory to allocate them.
> :
> :Actually, in my systems, I do need to know where they are allocated, so
> :that
> :I can examine them from the hideously crude display in the cockpit
> :during
> :troubleshooting.
> 
> That *is* hideously crude (and brings back some bad memories). Depending on how
> crude you mean, maybe a primitive tool could give you a map of where objects get
> put in memory. If you mean incredibly crude, use non-reference (expanded in
> Eiffel) types and use a linker-generated memory map.

Both approaches require that the memory address be known before
execution time,
however, so I still care where objects are located. I also care for
other reasons,
such as memory-mapped I/O, of course.

> 
> :> Maybe general assertions are more common than you imagine. However, I agree
> :> that range constraints are roughly covered by Ada subtypes. I use them liberally
> :> for just that purpose.
> :
> :Maybe, but again, I would like to see how these complex assertions are
> :used.
> 
> You would use them anywhere that a piece of code makes assumptions. For example,
> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> you apply Ariane 5 dynamics to it.

This is why my blood pressure goes up!

The _Ada_ implementation did generate an assertion violation the very
first time
Ariane 5 dynamics were applied to it. Unfortunately, the very first time
Ariane 5
dynamics were applied to it was at LANUCH!

They were not applied earlier, because the contractor assumed that the
Ariane 5
dynamics were the same as the Ariane 4, so why spend the money testing
to the same
conditions already tested earlier? (They were wrong, of course, but they
didn't know
that at the time).

The other part of the problem was that the _response_ to the assertion
violation was
wrong. The designer assumed the assertion would occur due to a hardware
failure, not
a software requirements failure, and so the handler shut down the
"offending" hardware,
rather than attempting some other action (e.g. replacing the
out-of-range value with
a "safe" value). Frankly, I don't know that I would have written the
handler differently
myself.

This is all clearly documented in the final report, available on the
Web.

According to Meyer, et. al. Eiffel programmers would have written the
handler
differently, and also they would have known to do the testing
differently (even though
the requirements specification said that the tests need not change).
However, their
explanation as to why this is true is far from convincing (basically,
that "Eiffel
programmers believe in quality" or some such nonsense). Their "analysis"
is also
on the Web. I've asked them to post my rebuttal to their paper, but I
don't know
if they ever did.

This is why I dislike people with no background in safety-critical
flight systems discussing
such issues. They believe that "software is software." and apply the
expertise in their
domain to mine. They usually do about as good a job as when I try to
discuss compiler
design :)

> 
> :Again, the code I've seen to date doesn't seem to use them that much.
> 
> If you're looking in Ada code, you're looking in the wrong place because few
> Ada developers recognise there are additional benefits from using them in
> addition to static typing and the predefined contracts already in Ada
> (the conditions under which predefined exceptions - eg. Constraint_Error -
> are raised).

No - I'm looking at Eiffel code. (Why would I look at Ada code to
determine how
Eiffel is used?)

> Static typing gives you static contract checking. Assertions (predefined and
> user-defined give you dynamic contract checking *during development*. What
> most Ada software engineers miss out on is the user-defined variety which
> bring a non-trivial benefit to reliability and reuse.

Not this Ada engineer! I have dynamic assertions all over the place in
my
tools!

My problem, again, is in the fundamental nature of dynamic assertions
for safety-critical
embedded systems, which have some unique risks, whether you (a) leave
them in after
development, or (b) take them out after developmental testing, but
before usage.

> 
> :> Correct me I misunderstand you.. Are you wondering whether contracting
> :> helps you to identify more bugs? I can offer my own experience which has
> :> firmly convinced me of this.
> :
> :Contracting definitely identifies more bugs. However, my concern with
> :Eiffel
> :assertions (and Ada assertions, for that matter) is that, once raised,
> :it's
> :not always clear what to do about them.
> 
> They are only turned on during development, so what you do is fix the underlying
> problem which is usually not difficult to find if you've used them systematically.
> Even if you haven't (I was the only one of a team of 5 using them in our recent
> development cycle), they still tell you more than you would otherwise be told.

I am aware of at least one project developing an embedded missile
controller,
that did exactly what you describe (in Ada). Here's what happened:

1. Their timings changed, which introduced some subtle differences in
the
relationships between tasks and external interrupts. Some of these
subtle
differences invalidated their original testing.

2. Their object code changed (obviously), which required reanalysis of
their
object-code branch coverage.

3. At least one compiler bug was introduced, which was definitely
unsettling.

What safety-critical system did you develop where you turned off
assertions
afer development? What standard (DO-178?) did you use for certification?

The other prong of this is that, while assertions are keen for catching
design problems, I haven't seen much evidence that they catch high-level
requirements problems (not surprising, since the code was presumably
written
to match the requirements). In 13 years of developing safety-critical
embedded systems, our process tends to handle design problems fairly
early.
It's those high-level requirements problems where we need the most help.

> 
> Good design complemented by static typing and Design by Contract is unbeatable,
> IME.
> 
> :In a safety-critical system such
> :as
> :we build, you can't just generate a core dump, or ask the user what to
> :do next.
> :You have to generate a correct response to the assertion failure, and
> :you have
> :to do it very quickly.
> 
> Right. However, only an incorrect program will raise assertion violations at
> runtime. As you systematically identify and fix the errors causing them during
> development, you can turn assertions off with confidence when the system
> goes live. Then, any errors you may have missed will be handled by exception
> handlers in the usual way.
> 
> :Static assertion checks, of course, can be
> :detected and
> :corrected during development, which is why I like Ada's strong static
> :type checking.
> 
> I agree completely. Static typing is great but it isn't the *whole* story.
> 
> :There is a school of thought that says to add in assertions, test the
> :system, and
> :then remove/suppress the exceptions. I have seen too many cases of code
> :that works
> :with the assertions active, and then breaks (due to timing differences,
> 
> Yes, timing *is* something to be concerned about when applied to realtime
> systems. That's why I suggested not using assertions in the hard realtime
> threads of a process. BTW, software designed using DBC may actually run *faster*
> than code without it because you get to strip out all the defensive validity
> checks. You have already ascertained during development that operations are
> called in valid contexts so you don't have to check the context.

But almost all of our safety-critical threads are hard realtime threads!
That's a HUGE limitation for our systems!

> 
> :or more
> :likely code generation errors) to have much confidence in this approach.
> 
> If that's a problem, you need to get your vendor to clean their act up.

Easier said than done! :)

What is the process to certify Eiffel compilers as being acceptably
mature
(code generation-wise) for safety-critical systems? Is all testing
performed
with assertions on and assertions off in all test cases?

> 
> :Another consequence of using assertions is that you have to develop and
> :test the
> :assertions.
> 
> Correct. My initial reaction when I started using them was "Gee, I've got to
> do this extra work on top of writing the "real" code! However, I found I was
> spending about a third of the time integrating compared with my colleagues
> which meant I was saving time overall and producing more reliable code to boot.
> 
> :As a result, you need confidence that the benefits of the
> :assertions
> :outweigh the dilution of your test effort.
> 
> IME, they do.

However, it sounds like you're talking about a non-safety-critical
system, and
certainly not a hard real-time embedded safety-critical systems. In that
case,
I agree. For tools, simulations, etc. I would use all of the assertions
I could.

However, what about the topic of this thread (safety-critical systems)?
It sounds
like there's a lot of limitations as to using (and inheriting)
assertions for
this environment.

> 
> :One of the advantages of
> :Ada's simpler
> :approach (at least, it seems simpler to me) to simple
> :pre/post-conditions (range
> :checks in particular) is that the cost of adding them is somewhat
> :reduced.
> 
> I disagree. It takes me about the same amount of time to specify an Ada
> subtype as it does to specify a more general assertion. Even if the general
> assertion is a function, I would more than likely need to write it anyway so
> would have expended the effort anyway.
> 
> :However,
> :in both languages, overuse of assertions may be just as bad as underuse.
> 
> It is possible to overuse them but 99% of developers err on the othger side. :)
> 
> :(As you can tell, I'm somewhat of an assertions heretic.
> 
> That's fine but have a go at using them where appropriate. I'm sure you'll
> become convinced.
> 
> :However, I will
> :say that
> :for non-real-time, non-safety-critical systems, they are outstanding. My
> :tool code
> :is lousy with them.)
> :
> :> Consequently, when we (a team of 5) recently
> :> reached the end of a 5 month long development effort of incremental coding
> :> and integration testing, the parts of the system that used contracting work
> :> flawlessly apart from problems resulting from misinterpretation of requirements.
> :
> :Most of the problems we see in formal testing are from misinterpretation
> :of
> :requirements - which is another issue I have with assertions as a magic
> :safety wand.
> 
> No use of assertions will stop you misinterpreting requirements. They're not
> a magic wand but they *will* help you remove a class of errors you would
> otherwise miss.
> 
> :Of course, Bertand Meyer's Eiffel website insists that even
> :misinterpretation of
> :requirements (Ariane V) will be a problem no longer when Eiffel is used!
> 
> Come on. He's not saying that.

Read his analysis of Ariane V. He says _exactly_ that, and has defended
saying that in multiple newsgroups. A smart person, but not someone
who knows my domain particularly well.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jean-Marc Jezequel]

In article <33CC0548.4099@flash.net>, Ken Garlington <keg0@flash.net> writes:
>Don Harrison wrote:

>> You would use them anywhere that a piece of code makes assumptions. For example,
>> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
>> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
>> you apply Ariane 5 dynamics to it.
>
>This is why my blood pressure goes up!
>
>The _Ada_ implementation did generate an assertion violation the very
>first time Ariane 5 dynamics were applied to it. Unfortunately, the very first time
>Ariane 5 dynamics were applied to it was at LANUCH!

>They were not applied earlier, because the contractor assumed that the
>Ariane 5 dynamics were the same as the Ariane 4, so why spend the money testing
>to the same conditions already tested earlier? (They were wrong, of course, but they
>didn't know that at the time).

At the risk of repeating myself, and reopening a thread beaten to death,
the all point of design by contract (DBC) is to
make this kind of assumptions explicit. Ariane 5 is just a nice striking example
of working with assumptions that are true at a point in time (Ariane 4) and no longer
later on (Ariane 5). I think we agreed on this previously.

To sum up your point, you think that DBC, i.e. expressing hidden assumptions with 
Eiffel-like assertions would not have been practicable in this case.
Others think it would have...

You seem to be a specialist in flight software. We are not. But specialists might,
from time to time, learn something from people with a broader perspective
(this is a general statement, I do not claim in particular that I have a broader
perspective than you, or anyone else for that matter;-).

Basically, our arguments failed to convinced you. Yours failed to convince us. 
That's life, and I hope readers can make their mind themselves instead of
relying on the one of us who shouts louder.

>The other part of the problem was that the _response_ to the assertion
>violation was wrong. The designer assumed the assertion would occur due to a hardware
>failure, not a software requirements failure, and so the handler shut down the
>"offending" hardware, rather than attempting some other action (e.g. replacing the
>out-of-range value with a "safe" value). Frankly, I don't know that I would have written the
>handler differently myself.

Agreed, that's a different problem altogether.

>According to Meyer, et. al. Eiffel programmers would have written the
>handler differently, and also they would have known to do the testing
>differently (even though the requirements specification said that the tests need not change).
>However, their explanation as to why this is true is far from convincing (basically,
>that "Eiffel programmers believe in quality" or some such nonsense). Their "analysis"
>is also on the Web. I've asked them to post my rebuttal to their paper, but I
>don't know if they ever did.

Just for the record, I'm still waiting for your rebuttal paper to put it on my web alongside
with the Computer article. 

PS: Ken's post was brought to my attention by a colleague: I don't have time to check the news
very often these days, and anyway I won't follow-up on this thread to avoid reopening the interminable
Ariane thread.

-- 
Jean-Marc Jezequel               Tel : +33 299 847 192         
IRISA/CNRS                       Fax : +33 299 847 171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> In article <33CC0548.4099@flash.net>, Ken Garlington <keg0@flash.net> writes:
> >Don Harrison wrote:
> 
> >> You would use them anywhere that a piece of code makes assumptions. For example,
> >> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> >> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> >> you apply Ariane 5 dynamics to it.
> >
> >This is why my blood pressure goes up!
> >
> >The _Ada_ implementation did generate an assertion violation the very
> >first time Ariane 5 dynamics were applied to it. Unfortunately, the very first time
> >Ariane 5 dynamics were applied to it was at LANUCH!
> 
> >They were not applied earlier, because the contractor assumed that the
> >Ariane 5 dynamics were the same as the Ariane 4, so why spend the money testing
> >to the same conditions already tested earlier? (They were wrong, of course, but they
> >didn't know that at the time).
> 
> At the risk of repeating myself, and reopening a thread beaten to death,
> the all point of design by contract (DBC) is to
> make this kind of assumptions explicit.

Which would not have happened in the Ariane V case.

> Ariane 5 is just a nice striking example
> of working with assumptions that are true at a point in time (Ariane 4) and no longer
> later on (Ariane 5). I think we agreed on this previously.

Yes. However, the assumption would not have been documented via an
Eiffel assertion,
as I claimed and you/Meyer never refuted (except to exclaim,
"casuistry!").

> 
> To sum up your point, you think that DBC, i.e. expressing hidden assumptions with
> Eiffel-like assertions would not have been practicable in this case.
> Others think it would have...

The distinction, of course, is that I gavce specific reasons why it
would not
have happened. Please post the evidence stating that the assertion would
have been
added (beyond the bizarre "Eiffel programmers are more careful"
argument).


> You seem to be a specialist in flight software. We are not. But specialists might,
> from time to time, learn something from people with a broader perspective
> (this is a general statement, I do not claim in particular that I have a broader
> perspective than you, or anyone else for that matter;-).

Unfortunately, the reverse is never true. Generalists never listen to or
learn from
specialists.

Consider the work of "generalists" that is incorporated into my code
today: Ada (Ichbiah
et. al.), object-based design principles (Gomaa/SPC, which in turn is
based on a lot
of previous work), safety-critical design (Levison and many others),
testing practices
(Beizer, et. al.)... there are many examples.

In your work on Ariane V, what specialists in the flight software field
(from
Arianespace or elsewhere) did you use to review your paper prior to its
publication?

After its publication, how many specialists in this field publicly (or
privately)
supported your position? I certainly was not the only one to object
publicly!

> Basically, our arguments failed to convinced you. 

Unfortunately, you failed to even discuss some of the points I (and
others) made.

> Yours failed to convince us.
> That's life, and I hope readers can make their mind themselves instead of
> relying on the one of us who shouts louder.

Yes, perhaps other criteria would be better. What would you suggest?
Company
revenues?

I would have thought practical experience would be a strong
determinant...

> >The other part of the problem was that the _response_ to the assertion
> >violation was wrong. The designer assumed the assertion would occur due to a hardware
> >failure, not a software requirements failure, and so the handler shut down the
> >"offending" hardware, rather than attempting some other action (e.g. replacing the
> >out-of-range value with a "safe" value). Frankly, I don't know that I would have written the
> >handler differently myself.
> 
> Agreed, that's a different problem altogether.

But an important one, if the assertion is left in the code. If the
assertion is removed
from the code, then other risks emerge.

> 
> >According to Meyer, et. al. Eiffel programmers would have written the
> >handler differently, and also they would have known to do the testing
> >differently (even though the requirements specification said that the tests need not change).
> >However, their explanation as to why this is true is far from convincing (basically,
> >that "Eiffel programmers believe in quality" or some such nonsense). Their "analysis"
> >is also on the Web. I've asked them to post my rebuttal to their paper, but I
> >don't know if they ever did.
> 
> Just for the record, I'm still waiting for your rebuttal paper to put it on my web alongside
> with the Computer article.

I thought I sent you the summary from the previous thread. I apologize.
I will go into
DejaNews and re-send it this weekend.

> 
> PS: Ken's post was brought to my attention by a colleague: I don't have time to check the news
> very often these days, and anyway I won't follow-up on this thread to avoid reopening the interminable
> Ariane thread.

Unfortunately, it's already been re-opened. As I feared, people are
using your paper to
"prove" the worth of DBC/Eiffel in safety-critical systems, although no
one has yet
published a list of such systems that have been written in Eiffel.

> 
> --
> Jean-Marc Jezequel               Tel : +33 299 847 192
> IRISA/CNRS                       Fax : +33 299 847 171
> Campus de Beaulieu               e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Safety-critical development in Ada and Eiffel

["Paul E. Bennett"]

In article <33CD6512.2404@flash.net> kennieg@flash.net "Ken Garlington" writes:

[Lots of stuff re-opening the Ariane/DBC/Eiffel arguments deleted]
 
> Unfortunately, it's already been re-opened. As I feared, people are
> using your paper to "prove" the worth of DBC/Eiffel in safety-critical 
> systems, although no one has yet published a list of such systems that 
> have been written in Eiffel.

It is a shame that Les Hatton is not on this ng. He is a very interesting 
character who has spent quite some time examining the effect of language, 
project size, complexity and domain expertise on the outcome of various
projects. From his results (and supported by numerous other papers) it
appears that the most important factor in understanding a project is the
level of domain expertise in the project. The language used had very little
effect on the projects studied in terms of quality.

The other main determinate of project outcome is the nature of the projects 
management. Domain expertise might be difficult to build into any programming 
language unless you are willing to invest very heavily in your programmers 
domain specific tools which will need construction by domain experts anyway.

On the other hand, improving the project management can be done with improved
management training, provision of general and specific management tools and
instillation of "High Integrity Culture" within an organisation.

Now it should be time to end the language wars and look at what we can all 
learn from each other.

-- 
Paul E. Bennett ................... <peb@transcontech.co.uk>
Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861                  <enquiry@transcontech.co.uk>
Going Forth Safely

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

<<It is a shame that Les Hatton is not on this ng. He is a very interesting
character who has spent quite some time examining the effect of language,
project size, complexity and domain expertise on the outcome of various
projects. From his results (and supported by numerous other papers) it
appears that the most important factor in understanding a project is the
level of domain expertise in the project. The language used had very little
effect on the projects studied in terms of quality.
>>


Well I certainly disagree strongly with Les' quite bogus conclusions about
language complexity drawn from the number of isses raised with respect to
the standard. I can't comment on his other observations. There is certainly
a body of literature showing that language *does* matter, and particularly
the abstraction level of a language matters. 

Actually I think these studies are all dubious, it is almost impossible
to do controlled studies of any kind, so this kind of work ends up being
very soft, almost as bad as a lot of wooly social science stuff. People
almost always seem to find the data that supports their preheld conceptions,
always an indication that you are treading on flaky areas from a scientific
point of view.

The stupidity of all the Ariane 5 analysts.

[Thaddeus L. Olczyk]

Frankly I'm getting a little tired of all the stupidity of the language
enthusiasts
and methodologists who are out there saying "Ariane 5 crashed because they
didn't use my language or my methodology". They are all ignoring one basic 
fact: the backup and primary systems were identical. Effectively this meant
that most bugs or generic hardware defects were likely to be duplicated,
eliminating
most of the safety that a backup system provides.

While not strongly conversant in the design of fault tolerant systems, I do
know
that some systems use backups which are the same and others use backups
which are entirely different ( different hardware, software, and
methodology ).
I believe that it doesn't take a rocket scientist to figure out that among
the later
are thingfs like: missle launching systems, remote facilities and rockets.

Re: The stupidity of all the Ariane 5 analysts.

[Bertrand Meyer]

When someone resorts to changing the subject header of
a thread to "The stupidity of all" those who have analyzed
an issue and come to different views, it's a pretty
good sign that he has run out of technical arguments.

To repeat once again the basic point made in the
paper by Jean-Marc Jezequel and myself: it is dangerous
and unjustifiable, especially in a mission-critical setting,
to reuse a software element without a specification.

From the beginning to the end of the software lifecycle,
Design by Contract encourages associating
such specifications with everything that you write.  
The method applies on at least four levels:
getting the stuff right in the first place, by
writing the software elements (the description of
*how* things are done) together with their contracts
(*what* they are supposed to achieve); documenting
them, through automatic extraction of contracts
as the basic information on a class; using the contracts
as one of the principal guides to reuse; and applying
them to debugging, which becomes less of a blind chase
and more of a focused analysis of possible discrepancies
between intents (the contracts) and reality (the
implementations).

None of this automatically guarantees perfection, but it
sure helps, as reported in these threads by
every poster who had actually used Eiffel, where the
ideas of Design by Contract are most directly realized.
It is true that to someone who has not really tried it
some of the benefits may appear exaggerated, but they're
real. Just one case in which an incorrect call to a
routine produces a violated precondition (caught
right away at testing time, whereas it could in
another approach have gone undetected for ages,
and caused painful bugs) justifies the investment.
In Eiffel development, this happens all the time. 

The Ariane case provides a textbook example of the dangers
of not using contracts. Of course it is easy to dismiss
this example through below-the-belt arguments, such as
 
	- "Jezequel and Meyer are not aerospace industry
	  experts." True, but it doesn't seem the experts
	  did so well in that case (and this is not the
	  first major example of aerospace software failure
	  either), so perhaps it's time to listen to
	  others. Besides, the official report
	  is clear and detailed enough to enable 
	  software professionals, aerospace experts or
	  not, to form their own judgment.

	- "This is only a pitch for Eiffel". The paper by
	  Jezequel and myself says explicitly that the
	  Ariane disaster was not due to a language problem.
	  In spite of this clear and obvious statement some of
	  the Ada enthusiasts in these newsgroups have
	  mistakenly taken the mention of Ariane as a personal
	  affront on their language. The pitch, if any, is for
	  the method of Design by Contract. That this method is
	  directly reflected in Eiffel as a language, and less
	  easy to apply in Ada, is a fact (and presumably
	  in the case of Ada 95 a conscious design decision),
	  not something to be held against the Eiffel community.

	- "Design by Contract is being promoted as a cure-all."
	  It's not (not a cure-all, and not promoted as such).
	  But it makes a major contribution.

All this is rhetorics and cannot succeed to obscure the basic
claim that systematic use of Design by Contract would probably
have avoided the crash. Of course like any reconstruction of
the past this conjecture cannot be proved, but there
is enough evidence in the official report to support
it. One can also object that other techniques would also
have achieved the same goal, such as heavy-artillery 
a posteriori quality assurance, but they seem far more difficult
and costly than integrating Design by Contract, a simple
and easy-to-apply idea, into the design, implementation,
documentation, reuse and validation process.

Some of the negative reactions seem to recall arguments
that were used against the proponents of structured programming
in the 70s, and against those of object technology in the 80s.
They are probably inevitable (and in part healthy, as they
force the methodologists to clarify their ideas, refine them,
and avoid overselling). But when a useful methodological
principle surfaces, all the rhetoric in the world will
not prevent its diffusion.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D2827B.41C67EA6@eiffel.com>, Bertrand.Meyer@eiffel.com says...
>
>To repeat once again the basic point made in the
>paper by Jean-Marc Jezequel and myself: it is dangerous
>and unjustifiable, especially in a mission-critical setting,
>to reuse a software element without a specification.

  We "aerospace" people agree.


>All this is rhetorics and cannot succeed to obscure the basic
>claim that systematic use of Design by Contract would probably
>have avoided the crash.

  The problem with this is that you are preaching to the choir.
Long long ago, before Eiffel, the general concept of capturing
system requirements in a spec document, flowing down to a software
requirements document, conducting detailed design reviews with the
requirment documents as resources/authorities (or getting them 
updated) and finally having software qualification tests done to 
prove performance to the software requirements spec has been 
practiced by the "aerospace" industry.  The "crash" resulted 
because of a failure to fully follow this existing practice.  
Your papers about Eiffel and Design By Contract are just, IMO,
another way to implement the concept of developing software that
must comply to requirements.

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert S. White wrote:
> 
> The "crash" resulted
> because of a failure to fully follow this existing practice.

Yes, I agree. (I decided not to address the statement in the Eiffel
paper that says the opposite, it seemed to be piling on.)

Hope you get a chance to review my draft critique. Geoff Eldridge
<geldridg@progsoc.uts.edu.au> was kind enough to create an HTML
version at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

BTW, I just noticed the flaws in the example Eiffel code at the
last minute (midnight Saturday, in fact). Did you and everyone
else know it was wrong, and just not say anything, or did we
all overlook the errors?

 _____________________________________________________________________
> Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D3F2CB.61DC@flash.net>, kennieg@flash.net says...

>BTW, I just noticed the flaws in the example Eiffel code at the
>last minute (midnight Saturday, in fact). Did you and everyone
>else know it was wrong, and just not say anything, or did we
>all overlook the errors?


Do you mean what you addres in your Critique's paragraph 3.1.1 about
Meyer's Eiffel paper's solution code:

"...any software element that has such a fundamental constraint should 
state it explicitly, as part of a mechanism present in the programming 
language, as in the Eiffel construct

      convert (horizontal_bias: INTEGER): INTEGER is
            require
                  horizontal_bias <= Maximum_bias
            do
                  ...

            ensure
                  ...

            end

where the precondition states clearly and precisely what the input must 
satisfy to be acceptable."

  Yes it looks like the above code should do a floating point absolute
value on horizontal_bias before it checks against Maximum_bias.  But
I consider that a _typical_ coding error that is normally found by software
code inspections or unit level tests - whoops - DBC/Eiffel does _not_
find this error!  And yes, the test _must_ be done while the value is
still expressed in floating point _before_ conversion to integer...details,
details.  Stuff we encounter all of the time in our problem domain.

  One could argue that the above is just a nit (flawed example) and 
the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
conventional "aerospace industry software engineering process" is 
the real issue.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
                  (newsgroups trimmed to contain the "language wars")

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Robert White said

<<  One could argue that the above is just a nit (flawed example) and
the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
conventional "aerospace industry software engineering process" is
the real issue.
>>

Unfortunately the Ariane crash was the result of just such a nit!

I would think experience would teach us to be very suspicious of any
claims by anyone to have a silver bullet panacea wjhen it comes to
software engineering for large systems.

However tools and techniques that help, even a little bit, are welcome
even if they are not a panacea (I consider Ada to be in this category,
and I always find it annoying when people advertise Ada as being
a silver bullet panacea).

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert Dewar wrote:
> 
> Robert White said
> 
> <<  One could argue that the above is just a nit (flawed example) and
> the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
> conventional "aerospace industry software engineering process" is
> the real issue.
> >>
> 
> Unfortunately the Ariane crash was the result of just such a nit!
> 
> I would think experience would teach us to be very suspicious of any
> claims by anyone to have a silver bullet panacea wjhen it comes to
> software engineering for large systems.
> 
> However tools and techniques that help, even a little bit, are welcome
> even if they are not a panacea (I consider Ada to be in this category,
> and I always find it annoying when people advertise Ada as being
> a silver bullet panacea).

I agree with this, but I also think every tool and technique has both
advantages _and risks_. Failing to understand the risks, and where they
are (and aren't) important, can lead to extremely dangerous choices made
with the best of intentions. I view executable assertions (Ada, Eiffel,
etc.) in this category. In some environments, they are clear wins. In
other
environments, I think it is at least debatable whether their advantages
outweigh their risks.

Complicating this factor is that many people confuse the abstract Good
Thing
(e.g. well-documented assumptions) with a specific implementation of the
Good Thing. They consider the Good Thing so obvious that they don't
consider
(a) what Bad Things may also be associated with the _implementation_ --
the
proponents of the implementation aren't always candid about this part
(or are
sometimes just blind to it) and (b) whether, for a given project, there
are better
ways to achieve the Good Thing.

As you've said in the past, Computer Science is in part a misnomer in
that
there doesn't seem to be much in the way of controlled experiments. So,
a
lot of these risk/reward analyses are based on incomplete data, at best.
This doesn't mean that they shouldn't be done, however. Ignoring the
risks
(or worse, dismisssing them as "they just haven't seen the light yet,"
as
Mr. Meyer did recently) is not smart in any environment, and certainly
not
in safety-critical systems.

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> I would think experience would teach us to be very suspicious of any
> claims by anyone to have a silver bullet panacea wjhen it comes to
> software engineering for large systems.
> 
> However tools and techniques that help, even a little bit, are welcome
> even if they are not a panacea (I consider Ada to be in this category,
> and I always find it annoying when people advertise Ada as being
> a silver bullet panacea).

I would go farther; I am suspicious of anyone who advocates a particular
languages and can't tell me anything in the language that he dislikes.
If
he can't identify flaws, either he's too inexperienced to rely on or 
isn't perceptive enough. *any* programming language will have warts, and
a real professional will recognize them and have strategies for dealing 
with them.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Shmuel says

<<I would go farther; I am suspicious of anyone who advocates a particular
languages and can't tell me anything in the language that he dislikes.
If
he can't identify flaws, either he's too inexperienced to rely on or
isn't perceptive enough. *any* programming language will have warts, and
a real professional will recognize them and have strategies for dealing
with them.
>>

Of course, that goes without saying, but did you ever meet anyone who was
in that category whose ideas you would otherwise respect. I know some
people who display this kind of ignorance, but they are not the kind of
people I would take seriously.

You can say the same thing about operating systems of course, for example
anyone who cannot point out the flaws in XXX, simply indicates that they
do not know the system very well, or that they lack the experience to
know that improvements are possible

(XXX = NT, Unix, Win95, OS/2, VMS etc etc)

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> You can say the same thing about operating systems of course, 

In fact, I *do* say the same sort of thing about operating systems. ;-)

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Larry Kilgallen]

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

> You can say the same thing about operating systems of course, for example
> anyone who cannot point out the flaws in XXX, simply indicates that they
> do not know the system very well, or that they lack the experience to
> know that improvements are possible
> 
> (XXX = NT, Unix, Win95, OS/2, VMS etc etc)

I think blindness to flaws has more to do with inexperience in
_other_ environments than in the one under discussion.

If my experience is limited to languages without uplevel addressing
(e.g., Bliss, C) I will not see that as a shortcoming the way I
would if I had used other languages (Ada, Pascal).

Larry Kilgallen

Warts was Re: The stupidity of all the Ariane 5 analysts.

[Richard Irvine]

Shmuel (Seymour J.) Metz wrote:
> 
> snip
> 
> I would go farther; I am suspicious of anyone who advocates a particular
> languages and can't tell me anything in the language that he dislikes.
> If
> he can't identify flaws, either he's too inexperienced to rely on or
> isn't perceptive enough. *any* programming language will have warts, and
> a real professional will recognize them and have strategies for dealing
> with them.
> 

For the benefit of the inexperienced and unperceptive amongst us (we
also have to earn a living) I would be fascinated to know what the real
professionals who read this newsgroup consider their favourite Ada
"warts" and their strategies for dealing with them.

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Richard Irvine asks

<<For the benefit of the inexperienced and unperceptive amongst us (we
also have to earn a living) I would be fascinated to know what the real
professionals who read this newsgroup consider their favourite Ada
"warts" and their strategies for dealing with them.
>>

I guess you are a new reader to this group :-)

If you stick around for a while, you will see that discussions about
what various people consider "warts" is a major topic of conversation
here.

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Richard Irvine wrote:
> 
> For the benefit of the inexperienced and unperceptive amongst us (we
> also have to earn a living) I would be fascinated to know what the real
> professionals who read this newsgroup consider their favourite Ada
> "warts" and their strategies for dealing with them.

I haven't had a chance to deal with Ada 95 yet, but if you browse the
archives
from AJPO on the Ada revision you will see a lot of problem areas in Ada
83,
many of which have been fixed in Ada 95. Of course, new problems may
have been
introduced in the process, but I suspect that when I have a chance to
use 95 
that I will concluded that the language has been improved.

Of course, there are profound disagreements as to whether specific
features are
indeed warts, and you must always consider the language in the context
of the
available alternatives. I submitted a large number of change requests
during the
refision process, for what I considered to be serious defects and
omissions, yet
I would far rather use Ada 83 than C.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Brian Rogoff]

On 7 Aug 1997, Fred Long wrote:
> Richard Irvine wrote:
> > 
> > For the benefit of the inexperienced and unperceptive amongst us (we
> > also have to earn a living) I would be fascinated to know what the real
> > professionals who read this newsgroup consider their favourite Ada
> > "warts" and their strategies for dealing with them.
> 
> John Barnes gave a talk at an Ada Uk Conference a few years ago
> entitled (something like) "Removing Ada's Warts".  I think it was
> published in Ada User.  (Sorry, I don't have the exact reference to hand.)

I'd be interested in reading it, if you can dig up the reference. Another 
good source (IMO of course) for Ada flaws is at 

	ftp://ftp.netcom.com/pub/hb/hbaker/

where several of the papers discuss memory management in Ada, and point out 
numerous flaws (of varying severity) in the language. My "favorite" one is 
this (from "Safe and Leakproof Resource Management using Ada83 Limited
Types", among others)

	The inability in Ada83 to export from the defining package of a
	private type a generic unit which takes a formal object of the
	private type is a very irritating restriction which appears to be
	due to a nasty pun in the Ada83 standard which makes formal objects
	appear to be real objects, at least in their syntax. Since real
	objects of the private type cannot be exported from the defining
	package due to a combination of other silly and irritating rules of
	Ada83, formal objects are also verboten. At the same time that Ada9X
	removes the restrictions on generic formal IN parameters, Ada9X 
	should also eliminate this restriction, so that more powerful 
	generic units can be exported by the package defining a private
	type. 

I posted an example of such a problem about a month ago. I am writing an 
STL like library in Ada which uses the "active" iterator approach. For
example, a generic Set could be written as 

generic
    type Element_Type is private;
    with function "<" ( Left, Right : Element_Type ) return Boolean is <>;
package AGL.Sets is
    type Set_Type is private;
    type Value_Type is private;
    function Is_Member ( Set : Set_Type; Key : Value_Type ) return Boolean;
    ... etc. ...
end AGL.Sets;

and a child package Iterators which instantiates its own textually nested 
generic signature packages corresponding to the kinds of traversal it
supports

generic
package AGL.Sets.Iterators is
    type Iterator_Type is private;

    function Start ( Set : Set_Type ) return Iterator_Type;
    function Finish ( Set : Set_Type ) return Iterator_Type;

    ... etc. ...

    -- ILLEGAL! These signatures can't be instantiated here!!!

    package Forward_Iterators is
      new AGL.Forward_Iterators(Value_Type, Iterator_Type, Value_Ptr,
                                Next, Get_Value, Set_Value, Get_Pointer);

    package Bidirectional_Iterators is
      new AGL.Bidirectional_Iterators(Value_Type,Iterator_Type,Value_Ptr,
                                      Next,Prev,Get_Value,Set_Value,
                                      Get_Pointer,"=");

end AGL.Sets.Iterators;
 
So what do we do about this problem? There are numerous workarounds, which 
involve creating a new package which instantiates the signature packages 
after Sets and Sets.Iterators. The choice is between instantiating the 
Sets and Sets.Iterators inside this new package, or passing in an
instantiated Sets (and maybe Sets.Iterators) as generic formal package 
parameters. A clumsy workaround IMO, but a workaround nonetheless.

I am curious about why this problem was not fixed in Ada 95. I've found
that null bodied "signature" packages are very useful for providing an 
interface to plug into generic package parameters, but the freezing rules 
force me into contortions like the above. If there were some way to 
interleave public and private sections in a package spec, these contortions 
would not be necessary. 

I should also note that while I agree with many of the criticisms made by 
Henry Baker in those papers, I don't share his very negative view of Ada. 
Scheme, SML, and Forth also suck, like Ada, but in different ways. 

-- Brian

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Jon S Anthony]

In article <Pine.SGI.3.95.970807191944.13419A-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> I'd be interested in reading it, if you can dig up the reference. Another 
> good source (IMO of course) for Ada flaws is at 
> 
> 	ftp://ftp.netcom.com/pub/hb/hbaker/

Agreed.

> numerous flaws (of varying severity) in the language. My "favorite" one is 
> this (from "Safe and Leakproof Resource Management using Ada83 Limited
> Types", among others)

That's not nearly as bad as the one about how limited types are not
required to be passed by reference.  A flaw that was continued into
Ada95 (with only partial mitigation).

> I posted an example of such a problem about a month ago. I am writing an 

The one I site, shows up in the GC stuff - I guess which is more
"favorite" depends on what your working on :-)

> I should also note that while I agree with many of the criticisms
> made by Henry Baker in those papers, I don't share his very negative
> view of Ada.  Scheme, SML, and Forth also suck, like Ada, but in
> different ways.

Absolutely agree!  Henry has his own blinders and they apparently keep
him from seeing the truth about these (and Lisp in general).

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Brian Rogoff]

On 8 Aug 1997, Jon S Anthony wrote:
> In article <Pine.SGI.3.95.970807191944.13419A-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:
> That's not nearly as bad as the one about how limited types are not
> required to be passed by reference.  A flaw that was continued into
> Ada95 (with only partial mitigation).
> 
> > I posted an example of such a problem about a month ago. I am writing an 
> 
> The one I site, shows up in the GC stuff - I guess which is more
> "favorite" depends on what your working on :-)

Actually, I agree that your 'fave' is nastier. There is an idiomatic
workaround to my "problem" (lack of interleaving), you just create a 
dummy package each time which simulates a sequence of alternating public 
and private parts. It is an ugly (IMO) yet fairly straightforward 
workaround. I don't know of a good workaround for you yet.

-- Brian

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Matthew Heaney]

In article <Pine.SGI.3.95.970807191944.13419A-100000@shellx.best.com>,
Brian Rogoff <bpr@shellx.best.com> wrote:


>generic
>package AGL.Sets.Iterators is
>    type Iterator_Type is private;
>
>    function Start ( Set : Set_Type ) return Iterator_Type;
>    function Finish ( Set : Set_Type ) return Iterator_Type;
>
>    ... etc. ...
>
>    -- ILLEGAL! These signatures can't be instantiated here!!!
>
>    package Forward_Iterators is
>      new AGL.Forward_Iterators(Value_Type, Iterator_Type, Value_Ptr,
>                                Next, Get_Value, Set_Value, Get_Pointer);
>
>    package Bidirectional_Iterators is
>      new AGL.Bidirectional_Iterators(Value_Type,Iterator_Type,Value_Ptr,
>                                      Next,Prev,Get_Value,Set_Value,
>                                      Get_Pointer,"=");
>
>end AGL.Sets.Iterators;
> 
>So what do we do about this problem? There are numerous workarounds...


Here's one, though I haven't tried to compile it.  This issue is that the
full view of the type needs to have been defined prior to instantiation of
the generics.

generic
package AGL.Sets.Iterators is

   package Iterator_Parents is

      type Iterator_Parent is private;

      <primitive ops here>
   
   private
      type Iterator_Parent is ...;

   end Iterator_Parents;

   type Iterator is new Iterator_Parents.Iterator_Parent;

   <instantiations here>

end;

Won't this solve the problem?

Yes, it seems that being able to interleave private and public sections
would be a convenient feature, because you could do this:

generic
package AGL.Sets.Iterators is

   type Iterator is private;

   <primitive ops>

private 

   type Iterator is ...;  -- full view

public

   <instantiations go here, now that full view has been seen>

end;

but you can get almost that effect using nested packages.  It's the same
trick you do in Ada 83 to be able to derive from a type declared in the
same package spec.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Brian Rogoff]

On Sun, 10 Aug 1997, Matthew Heaney wrote:
> In article <Pine.SGI.3.95.970807191944.13419A-100000@shellx.best.com>,
> Brian Rogoff <bpr@shellx.best.com> wrote:
> 
> > ... example deleted ...[[[[[[[[[[ 
> >So what do we do about this problem? There are numerous workarounds...
> 
> 
> Here's one, though I haven't tried to compile it.  This issue is that the
> full view of the type needs to have been defined prior to instantiation of
> the generics.
> 
> ... nested package example deleted...
> 
> Won't this solve the problem?

Sure, as I said either nesting (83 or 95) or passing in the packages as
formal parameters (in Ada 95) will work. If you imagine that we actually 
had an Ada with interleaved sections, the transformation to actual Ada 
consists of breaking the interleaved package into lots of little packages 
and instantiating them in the order that they appear in the interleaved 
version. That instantiation can be inside a package, if you use textual 
nesting, or outside, in which case you'd pass them in. 

> Yes, it seems that being able to interleave private and public sections
> would be a convenient feature, because you could do this:

Yeah, I think it would be an improvement too. I still wouldn't chuck Ada 95 
over this flaw though.

> generic
> package AGL.Sets.Iterators is
> 
>    type Iterator is private;
> 
>    <primitive ops>
> 
> private 
> 
>    type Iterator is ...;  -- full view
> 
> public
> 
>    <instantiations go here, now that full view has been seen>
> 
> end;
> 
> but you can get almost that effect using nested packages.  It's the same
> trick you do in Ada 83 to be able to derive from a type declared in the
> same package spec.

As I'm a relative Ada newbie, I'm not familiar with Ada 83 tricks, only Ada
95. 

When I first started looking at Ada a few years ago, I knew that it must
really be awful, because everyone said so. As I became  more familiar with
the language and its "warts", I realized that "everyone" was just like me,
disparaging this language without knowing it. I find these discussions of 
perceived flaws and workarounds very helpful, and now I almost always end
up liking Ada even more after every "wart".

-- Brian 
  

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Brian Rogoff wrote:
> 
> When I first started looking at Ada a few years ago, I knew that it must
> really be awful, because everyone said so. 

There are several pitfalls in that. First, it's almost impossible to
know what
everybody is saying, so you rely on a random sample that may or may not
be representative. Second, the people that you hear may or may not know
what 
they're talking about. And finally, you may or may not understand what
they're 
actually saying: "be carefull of using x in Ada because it's dangerous"
is 
*not* the same as "Ada is awfull."

If you're teaching a programming language, it is part of your
responsibility 
to warn your student of potential problems. It is not part of your job
to 
sell him on the virtues of the language. If you train him to have safe
habits,
he's more likely to decide that he likes the language than if he
continually 
shoots himself in the foot.

> -- Brian
> 

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Robert A Duff]

In article <JSA.97Aug8161709@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>That's not nearly as bad as the one about how limited types are not
>required to be passed by reference.  A flaw that was continued into
>Ada95 (with only partial mitigation).

I would say *substantial* mitigation.  I mean, if you want it to be
passed by reference, export a limited private type, and make the full
type "limited record".

Everyone should follow this coding convention, in Ada 95: If a limited
private type is completed with a record type, make the record type
limited, too.

I'm not sure how we could have done better, without damaging upward
compatibility, and/or damaging privacy of private types.  I mean, you
can't say "all limited types are passed by ref", because a limited type
may be completed by an integer type, and integer types are passed by
value.  Surely you don't suggest that the view of the type at the call
site should determine whether it's passed by copy or by ref!  (So that a
single subprogram has multiple calling conventions.)

By the way, it's not clear to me that you *want* pass-by-ref for limited
elementary types, such as pointers.  An earlier version of Ada 9X had
limited access types (quite useful!), but they were passed by copy, if I
remember.  You couldn't assign them, though.

- Bob

Re: Warts was Re: The stupidity of all the Ariane 5 analysts.

[Jon S Anthony]

In article <EEMC8t.8J8@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <JSA.97Aug8161709@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >That's not nearly as bad as the one about how limited types are not
> >required to be passed by reference.  A flaw that was continued into
> >Ada95 (with only partial mitigation).
> 
> I would say *substantial* mitigation.

Shrug.  Not IMO.


>  I mean, if you want it to be passed by reference, export a limited
> private type, and make the full type "limited record".

Can work some of the time, but definitely not all of the time.


> Everyone should follow this coding convention, in Ada 95: If a
> limited private type is completed with a record type, make the
> record type limited, too.

That sounds reasonable but doesn't have anything to do with the issue.


> I'm not sure how we could have done better, without damaging upward
> compatibility,

Yes, and?  Afterall, there were other non-upward compatible
changes. Yeah, I know, you don't think this one has/had the right
tradeoffs.  But others clearly disagree.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The stupidity of all the Ariane 5 analysts.

[Don Harrison]

This is a response to something posted to comp.lang.ada but not comp.lang.eiffel..

"Shmuel (Seymour J.) Metz" wrote:

:Robert Dewar wrote:
:> 
:> I would think experience would teach us to be very suspicious of any
:> claims by anyone to have a silver bullet panacea wjhen it comes to
:> software engineering for large systems.
:> 
:> However tools and techniques that help, even a little bit, are welcome
:> even if they are not a panacea (I consider Ada to be in this category,
:> and I always find it annoying when people advertise Ada as being
:> a silver bullet panacea).

Me too. :)

:I would go farther; I am suspicious of anyone who advocates a particular
:languages and can't tell me anything in the language that he dislikes.

Presumably, you're talking about me. :)

If you think I never have any criticisms of Eiffel, you're mistaken. What may 
surprise you even more is that I sometimes have positive things to say about
Ada! - for example, two recent posts to comp.lang.eiffel under the subject
"Ennumerations in Eiffel" (31.7.97 and 1.8.97). These included two criticisms
of Eiffel and one positive comment about Ada.

Also, was my agreement with criticisms of Eiffel WRT use of assertions and GC
in hard realtime software a glowing endorsement of Eiffel? I think not.

:If he can't identify flaws, either he's too inexperienced to rely on or 
:isn't perceptive enough. 

Thank you. :)

:*any* programming language will have warts, 

Eiffel has its flaws; it's just that Ada has about 50 times more. :)

:and a real professional will recognize them and have strategies for dealing 
:with them.

Agree.


BTW, one the few areas where Ada is streets ahead of Eiffel (and most languages), 
IMO, is standardisation. While Eiffel does have a standard language and libraries, 
not all vendors comply with them. Part of the problem is that there is no 
official certification of Eiffel compilers and, hence, no validation suite as 
there is in Ada. Obviously, this causes portability problems. 

Just because someone is biased, doesn't mean they can't also be honest and 
objective. Also, one can be biased with or without justification.


P.S. It shows considerably more intestinal fortitude to criticise someone to 
their face rather than where you don't think they'll hear you. Even if they 
don't agree with what you have to say, they may at least respect you for not
saying it behind their back. :(


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: The stupidity of all the Ariane 5 analysts.

[Shmuel (Seymour J.) Metz]

Don Harrison wrote:
>
> Presumably, you're talking about me. :)

Assuming that your name is legion ;-)
 
> P.S. It shows considerably more intestinal fortitude to criticise someone to
> their face rather than where you don't think they'll hear you. Even if they
> don't agree with what you have to say, they may at least respect you for not
> saying it behind their back. :(

Let's see; I post a public message in a forum in which you have been 
participating, and that constitutes saying it behind your back? If you
think 
that I should have sent you an E-mail, plenty of people have been flamed
for 
doing just that, on the grounds that is was an additional copy of a
message that
would already have been read by virtue of having been posted. I am
generally 
very sparing of cc headers in Usenet, and see nothing in my message to
justify ending you an extra copy.

Further, since the comment applied to multiple messages in the thread, I
would 
have had to search out all of the others to get their addresses and
include them 
on the cc header. Or did you think that you were more important than the
others?
 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

BTW, why on earth would I include a signature block if I were attempting
to 
criticize someone behind their back?

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Robert S. White wrote:
> 
> In article <33D3F2CB.61DC@flash.net>, kennieg@flash.net says...
> 
> >BTW, I just noticed the flaws in the example Eiffel code at the
> >last minute (midnight Saturday, in fact). Did you and everyone
> >else know it was wrong, and just not say anything, or did we
> >all overlook the errors?
> 
> Do you mean what you addres in your Critique's paragraph 3.1.1 about
> Meyer's Eiffel paper's solution code:
> 
> "...any software element that has such a fundamental constraint should
> state it explicitly, as part of a mechanism present in the programming
> language, as in the Eiffel construct
> 
>       convert (horizontal_bias: INTEGER): INTEGER is
>             require
>                   horizontal_bias <= Maximum_bias
>             do
>                   ...
> 
>             ensure
>                   ...
> 
>             end
> 
> where the precondition states clearly and precisely what the input must
> satisfy to be acceptable."
> 
>   Yes it looks like the above code should do a floating point absolute
> value on horizontal_bias before it checks against Maximum_bias. 

Yes, this is what I mean.

> But
> I consider that a _typical_ coding error that is normally found by software
> code inspections or unit level tests - whoops - DBC/Eiffel does _not_
> find this error!  And yes, the test _must_ be done while the value is
> still expressed in floating point _before_ conversion to integer...details,
> details.  Stuff we encounter all of the time in our problem domain.

It would have been found if the design made it clear a different
solution
was necessary, or "common sense" was used in this example.

>   One could argue that the above is just a nit (flawed example) and
> the overall premise of DBC/Eiffel as a "silver bullet" panacea versus
> conventional "aerospace industry software engineering process" is
> the real issue.

However, I think there's a fundamental point made by this "nit." Several
people read the paper; in fact, I saw one example in DejaNews last year
where someone posted the Ada version of this code... incorporating the
same mistakes! No one, as far as I could tell, saw this "obvious" error
in three lines of code despite many months of opportunity. What does
this
say about the credibility of manual inspections at the source code level
in picking up errors of this type during the reuse of software?

> _____________________________________________________________________
> Robert S. White         -- An embedded systems software engineer
>                   (newsgroups trimmed to contain the "language wars")

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <33D69CAF.19F1@flash.net>, kennieg@flash.net says...

> Robert S. White wrote:
>> I consider that a _typical_ coding error that is normally found by software
>> code inspections or unit level tests

>It would have been found if the design made it clear a different
>solution
>was necessary, or "common sense" was used in this example.

  Perhaps I should have provided more detail about our industry
software engineering process.  During the detail design review of 
the software module, Test Cases, for doing the module unit level
tests are also presented.  One of the checklist items for the test
cases is to ensure that the module is tested at boundry conditions
and beyond boundry conditions - both for the positive and negative
extremes in the case of a signed value.  This type of software
design process with inspections using checklists even against the
test cases is a way to spread out that very rare/precious commondity
called "common sense".
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Ariane 5,Eiffel, Ada.

[Alan Brain]

Robert S. White wrote:
> 
> In article <33D3F2CB.61DC@flash.net>, kennieg@flash.net says...
> 
> >BTW, I just noticed the flaws in the example Eiffel code at the
> >last minute 

> 
> "...any software element that has such a fundamental constraint should
> state it explicitly, as part of a mechanism present in the programming
> language, as in the Eiffel construct
> 
>       convert (horizontal_bias: INTEGER): INTEGER is
>             require
>                   horizontal_bias <= Maximum_bias
>             do
>                   ...
> 
>             ensure
>                   ...
> 
>             end
> 
> where the precondition states clearly and precisely what the input must
> satisfy to be acceptable."
> 
>   Yes it looks like the above code should do a floating point absolute
> value on horizontal_bias before it checks against Maximum_bias.  But
> I consider that a _typical_ coding error that is normally found by software
> code inspections or unit level tests - whoops - DBC/Eiffel does _not_
> find this error!  And yes, the test _must_ be done while the value is
> still expressed in floating point _before_ conversion to integer...details,
> details.  Stuff we encounter all of the time in our problem domain.

...which even Ada-83 would have caught. That's the whole point: Ada, of
whatever dielect, catches many of these problems. And it's these
problems that are often found in the problem domain.

Sounds as if an Eiffel-II would be good. This woul have strong typing a
la Ada-95, so you could have (something similar to)

type IntegerBiasType is Integer range MinimumBias..MaximumBias;

and thus have

       convert (horizontal_bias: IntegerBiasType): INTEGER is
             require
                   withinrange<horizontal_bias> 
             do
                   ...
 
             ensure
                   ...
 
             end

Or similar. Meanwhile, this discussion has convinced me that
design-by-contract is certainly worth consideration as a useful addition
to Ada-0x.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: The stupidity of all the Ariane 5 analysts.

[Robert Dewar]

Bertrand said

<<>All this is rhetorics and cannot succeed to obscure the basic
>claim that systematic use of Design by Contract would probably
>have avoided the crash.
>>

Well all sorts of things would have avoided the crash. One can also say
that systematic proof of correctness, or systematic code review, or
in fact almost any steps to be a bit more careful in this particular
area, would have avoided the crash. As usual, a disaster of this type
is a chain of occurrences, and fixing any one of them would have avoided
the problem.

Certainly the notion of clear interfaces and interface requirements
(I find the use of the capitalized "Design by Contract" a little 
pretentious, since I see no new concept there that justifies a new
technical term) is one which we can all agree on.

The argument that the use of Eiffel would have prevented the problem is
entirely unconvincing, and has the unfortunate effect of encouraging
people to think that the entire argument is just empty language advocacy.


When there is a major screwup in software (some examples, the long lines
failure at AT&T, the Denver baggage handling, the overnight funds transfer
disaster in an NY bank etc), there is a natural tendency for over
enthusiastic pushers of a particular language to try to argue that
their particular pet language would have guaranteed freedom from the
problem.

Such arguments are never convincing, because even if it *were* the case
that the particular problem at hand might *possibly* have had a better
chance of being avoided writing in language X, extending this to the
allegation that the use of language X would in general have been beneficial
stretches credibility. In particular, in a large complex system of this
type, the language and all other components have to meet all kinds of
complex requirements, and people who know nothing at all about the whole
application have no idea whatsoever if their pet language would in fact
meet the criteria.

If Bertrand is saying:

(a) The Ariane problem (at least little piece of it) is a good example of
why designing interfaces that are complete with respect to establishing
a requirements contract for clients is a good idea.

(b) One of the attractive features of Eiffel is that it supports this
concept directly and encourages programmers to use this approach.

Then the argument is entirely reasonable, and one that I cannot see
anyone objecting to. But the way the argument is stated, it reads as
though he is saying:

If Eiffel had been used for the Ariane project, it would not have crashed.

And I find that claim entirely unjustified, and it detracts from the
important underlying point.

No language can force people to do things right, and to a large extent
no language prevents people from doing things right. What a language
can do is to encoruage a style of programming and thinking that helps
people find their way to doing things right a little more easily.


This is indeed the principle behind the Ada design, and a lot of the
reason that Ada is successful in practice is precisely because it
encourages "good thinking". 

But when people said "if only the Denver baggae system had been written
in Ada, I would be flying to the new airport today", this crossed the
line into non-credible language advocacy.

Similarly, a lot of the thinking behind the Eiffel design is also
to encourage "good thinking", and in that sense Ada and Eiffel are
kindred spirits in their approach to language design, though they
make different choices about what is important to encourage.

However, when the Eiffel advocacy crosses the line to saying that a large
complex system, if written in Eiffel, would have succeeeded where otherwise
it failed, again this crosses the line into non-credible language advocacy.

I am, as everyone knows, a strong advocate of the use of Ada. However, I
take a lot of care NOT to make exaggerated claims, since I don't think
this helps at all. What Ada (or any other language) can do, is to push
programmers up a little bit on the quality and productivity scales.

A little bit may not sound like much, but these scales are logarithmic
scales in which the productivity of programmers and the quality of the
code they right varies over orders of magnitudes, so a "little bit" can
add up to very substantial savings in costs, and very substantial
improvements in quality in practice. 

Re: The presuppositions of all the Ariane 5 analysts.

[Samuel Mize]

Robert Dewar wrote:
> 
> Bertrand said
> 
> <<>All this is rhetorics and cannot succeed to obscure the basic
> >claim that systematic use of Design by Contract would probably
> >have avoided the crash.
> >>
> 
> Well all sorts of things would have avoided the crash. One can also say
> that systematic proof of correctness, or systematic code review, or
> in fact almost any steps to be a bit more careful in this particular
> area, would have avoided the crash.

This seems to touch the central core of the disagreement.  Mr.
Meyer published a paper which said (paraphrasing wildly):

1) DBC would probably have prevented the crash.
2) Only Eiffel properly supports DBC.
3) Draw your own conclusions.

I think it's fair to infer that the author considers this a
normal, adequately managed non-DBC project.  I don't know if
he states this outright, but it would be nugatory indeed to
suggest that a new method would help when the previous methods
were not being properly applied.  It's rather like claiming
that a new version of GPS, used properly, would have prevented
the Exxon Valdez crash.  That's true, but normal navigation
aids, used properly, would have prevented it too.

Stating ONLY that the new item would have prevented the crash
is a misleading half truth.

So even if Meyer's paper is technically correct to suggest
that rigorous DBC would "probably" have located the error,
it is disingenuous to state ONLY that, without pointing out
that common methods of analysis or test would ALSO have
located the error.

It also seems fair to say that, if DBC had been used as
thoroughlessly as other methods were, it probably would NOT
have detected the problem.

Samuel Mize

Re: The presuppositions of all the Ariane 5 analysts.

[Ken Garlington]

Samuel Mize wrote:
> 
> Robert Dewar wrote:
> >
> > Bertrand said
> >
> > <<>All this is rhetorics and cannot succeed to obscure the basic
> > >claim that systematic use of Design by Contract would probably
> > >have avoided the crash.
> > >>
> >
> > Well all sorts of things would have avoided the crash. One can also say
> > that systematic proof of correctness, or systematic code review, or
> > in fact almost any steps to be a bit more careful in this particular
> > area, would have avoided the crash.
> 
> This seems to touch the central core of the disagreement.  Mr.
> Meyer published a paper which said (paraphrasing wildly):
> 
> 1) DBC would probably have prevented the crash.
> 2) Only Eiffel properly supports DBC.
> 3) Draw your own conclusions.
> 
> I think it's fair to infer that the author considers this a
> normal, adequately managed non-DBC project.  I don't know if
> he states this outright, 

I believe the words for which you are aearching are:

"Everything indicates that the software process was carefully
organized and planned. The ESA's software people knew what
they were doing and applied widely accepted industry practices
.... it is clear from its report that systematic documentation,
validation and management procedures were in place....
The contention often made in the software engineering literature
that most software problems are primarily management problems is
not borne out here."

I considered addressing this in section 5 of my critique, but it
is so obviously at odds with the inquiry's report that it seemed
overkill. Maybe it's worth a brief paragraph.

> but it would be nugatory indeed to
> suggest that a new method would help when the previous methods
> were not being properly applied.  It's rather like claiming
> that a new version of GPS, used properly, would have prevented
> the Exxon Valdez crash.  That's true, but normal navigation
> aids, used properly, would have prevented it too.
> 
> Stating ONLY that the new item would have prevented the crash
> is a misleading half truth.

Outside the paper, both authors have made it clear that they
assumed everyone understood that all of the other problems would
have to be fixed as well. Jezequel, in one of the last posts during
the discussion of this paper last year, said words to the effect
"Was it really that important to have this long discussion, just to
make this obvious point?" Unfortunately, the paper itself does not
make this clear.

> 
> So even if Meyer's paper is technically correct to suggest
> that rigorous DBC would "probably" have located the error,
> it is disingenuous to state ONLY that, without pointing out
> that common methods of analysis or test would ALSO have
> located the error.
> 
> It also seems fair to say that, if DBC had been used as
> thoroughlessly as other methods were, it probably would NOT
> have detected the problem.
> 
> Samuel Mize

Re: The presuppositions of all the Ariane 5 analysts.

[Luther Hampton]

Samuel Mize wrote:
> 
> Robert Dewar wrote:
> >
> > Bertrand said
> >
> > <<>All this is rhetorics and cannot succeed to obscure the basic
> > >claim that systematic use of Design by Contract would probably
> > >have avoided the crash.
> > >>
> >
> > Well all sorts of things would have avoided the crash. One can also say
> > that systematic proof of correctness, or systematic code review, or
> > in fact almost any steps to be a bit more careful in this particular
> > area, would have avoided the crash.
> 
> This seems to touch the central core of the disagreement.  Mr.
> Meyer published a paper which said (paraphrasing wildly):
> 
> 1) DBC would probably have prevented the crash.
> 2) Only Eiffel properly supports DBC.
> 3) Draw your own conclusions.
> 
> I think it's fair to infer that the author considers this a
> normal, adequately managed non-DBC project.  I don't know if
> he states this outright, but it would be nugatory indeed to
> suggest that a new method would help when the previous methods
> were not being properly applied.  It's rather like claiming
> that a new version of GPS, used properly, would have prevented
> the Exxon Valdez crash.  That's true, but normal navigation
> aids, used properly, would have prevented it too.
> 

There is nothing in your paraphrase to support the contention that
"only" Design by Contract would have averted the problem.  (1) states
that DBC would do the trick, but it does not say that *only* DBC would
have solved the problem.

> Stating ONLY that the new item would have prevented the crash
> is a misleading half truth.
> 

I don't think that's what he said.  I assume you are still claiming he
said only DBC would have prevented the problem, he didn't.  Statement
(2), that Eiffel is the only language which supports DBC, is much more
controversial.  Meyer makes no secret of the fact that he considers
Eiffel the solution to many software development problems.  He has not
claimed to be objective, he is pointing out that a feature of Eiffel
would have helped here. This is (Eiffel/self-)promotion, but I think it
is acceptable disourse inside the newsgroup.     

> So even if Meyer's paper is technically correct to suggest
> that rigorous DBC would "probably" have located the error,
> it is disingenuous to state ONLY that, without pointing out
> that common methods of analysis or test would ALSO have
> located the error.
>
See above.
 
> It also seems fair to say that, if DBC had been used as
> thoroughlessly as other methods were, it probably would NOT
> have detected the problem.
> 
Agreed.  No method/language/tool can be effective if it is not properly
employed.  As you pointed out earlier, the major fault for the failure
appaers to lie with the management, which apparently didn't enforce the
procedures that were in place.  That is not to say, however, that Eiffel
or DBC might have helped.

Re: The presuppositions of all the Ariane 5 analysts.

[Ken Garlington]

Luther Hampton wrote:
> 
> > Stating ONLY that the new item would have prevented the crash
> > is a misleading half truth.
> 
> I don't think that's what he said.  I assume you are still claiming he
> said only DBC would have prevented the problem, he didn't.

See section 2, bullet (c), in

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

for a discussion of why it appears he did, in fact, claim that
DBC/Eiffel by itself would have been adequate.

>  Statement
> (2), that Eiffel is the only language which supports DBC, is much more
> controversial.  Meyer makes no secret of the fact that he considers
> Eiffel the solution to many software development problems.  He has not
> claimed to be objective...

Actually, he (and his co-author) has claimed in various threads that
his analysis is not specific to Eiffel, although the paper takes the
position you suggest.

> Agreed.  No method/language/tool can be effective if it is not properly
> employed.  As you pointed out earlier, the major fault for the failure
> appaers to lie with the management, which apparently didn't enforce the
> procedures that were in place.  That is not to say, however, that Eiffel
> or DBC might have helped.

There were also other factors, beyond "poor management," that could have
played a factor in defeating DBC/Eiffel. This is discussed in more
detail
on the web page referenced above.

Re: The presuppositions of all the Ariane 5 analysts.

[Samuel Mize]

Luther Hampton wrote:
> 
> Samuel Mize wrote:
...
> > 1) DBC would probably have prevented the crash.
> > 2) Only Eiffel properly supports DBC.
> > 3) Draw your own conclusions.
> >
> > I think it's fair to infer that the author considers this a
> > normal, adequately managed non-DBC project.  I don't know if
> > he states this outright, but it would be nugatory indeed to
> > suggest that a new method would help when the previous methods
> > were not being properly applied.  It's rather like claiming
> > that a new version of GPS, used properly, would have prevented
> > the Exxon Valdez crash.  That's true, but normal navigation
> > aids, used properly, would have prevented it too.
> >
> 
> There is nothing in your paraphrase to support the contention that
> "only" Design by Contract would have averted the problem.  (1) states
> that DBC would do the trick, but it does not say that *only* DBC would
> have solved the problem.

You're right, it isn't in my paraphrase.  It isn't directly stated,
but is heavily implied, when he says:

   The ESA's software people knew what they were doing
   and applied widely accepted industry practices.
   ...
   The contention often made in the software engineering literature
   that most software problems are primarily management problems is
   not borne out here.  The problem is technical.

This directly states that accepted industry practices were applied,
and that the problem was technical.  Tell me this doesn't imply that
accepted practices caused/allowed the problem.

Unfortunately, both statements are demonstrably false, based on
the inquiry.

Consider also these quotes:

   Several earlier columns in IEEE Computer have emphasized the
   importance of Design by Contract for constructing reliable
   software. A $500-million software error provides a sobering
   reminder that this principle is not just a pleasant academic ideal. 


   To attempt to reuse software without Eiffel-like assertions is to
   invite failures of potentially disastrous consequences.


   For reuse to be effective, Design by Contract is a requirement.
   Without a precise specification attached to each reusable component
   -- precondition, postcondition, invariant -- no one can trust a
   supposedly reusable component. 


Mr. Meyer is clearly saying that DBC/Eiffel, and ONLY DBC/Eiffel,
would prevent such a crash.

Sam Mize

Re: The stupidity of all the Ariane 5 analysts.

[W. Wesley Groleau x4923]

> Your papers about Eiffel and Design By Contract are just, IMO,
> another way to implement the concept of developing software that
> must comply to requirements.

He/they start from the (obviously debatable) belief that 
"'ideas of Design by Contract are most directly realized' in Eiffel" 
and then make an unjustified jump to 
"if it doesn't look like Eiffel, it doesn't do Design By Contract."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: The stupidity of all the Ariane 5 analysts.

[Ian Begg]

On Sun, 20 Jul 1997 14:26:19 -0700, Bertrand Meyer
<Bertrand.Meyer@eiffel.com> wrote:

<snip>

>To repeat once again the basic point made in the
>paper by Jean-Marc Jezequel and myself: it is dangerous
>and unjustifiable, especially in a mission-critical setting,
>to reuse a software element without a specification.

My personal opinion, I would add ".... or, probably more importantly,
without fully testing that software element in the environment it is
being re-used into, i.e. under the conditions it is expected to be
used in."  My understanding is that the expected flight profile was
not flown as part of the integration or acceptance testing, and that
had this been done the problem would (probably) have been found.  This
is what I mean by testing in the environment it is being re-used into.

<snip>

>	- "This is only a pitch for Eiffel". The paper by
>	  Jezequel and myself says explicitly that the
>	  Ariane disaster was not due to a language problem.
>	  In spite of this clear and obvious statement ...

Even clear and obvious statements have to be assessed to decide on the
intent of the author/speaker, for instance is he saying this because
he means it or because he's trying to pull the wool over our eyes.  [I
have not read your report so have no idea how to answer in this case,
everyone must make their own decision.  The author must ensure they
don't leave themselves open to the wrong interpretation.]

>                                                                                ... some of
>	  the Ada enthusiasts in these newsgroups have
>	  mistakenly taken the mention of Ariane as a personal
>	  affront on their language. The pitch, if any, is for
>	  the method of Design by Contract. 

How many languages support Design by Contract as part of the language
as in the case of Eiffel?  I don't have experience of a broad range of
languages so I can't answer this.  However, if the answer is only
Eiffel, (plus perhaps some other non relevant langauges) then it is
not difficult to see how people might interpret your motives as "OK we
can't be so obvious as to say Eiffel is the answer, but if we say
Design by Contract is the answer, people will need to find a language
to support it, hence Eiffel."  You are the only person who knows your
real motives, but the discussions going on suggest some people are
interpreting your motives in this way.

<snip>

>    One can also object that other techniques would also
>have achieved the same goal, such as heavy-artillery 
>a posteriori quality assurance, but they seem far more difficult
>and costly than integrating Design by Contract, a simple
>and easy-to-apply idea, into the design, implementation,
>documentation, reuse and validation process.

How easy is this to apply in non Eiffel implementations?  I guess it
needs extra work by the engineers, in an area most are probably not
familiar with and will hence need training, and success is dependent
on setting up good procedures to enforce its use etc.  Compare the
cost of that with doing integration and acceptance testing under
anticipated use conditions which should be done anyway and I come to
the conclusion use of Design by Contract was not the best way of
preventing this accident.

This is all of course my own personal opinion, and none of it should
be read as an 'attack' on anyone elses opinions, only a difference of
opinion.  Sorry if this is repeating stuff from the original thread(s)
which I have not been tracking closely.

Ian Begg

Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.)

[Jim Cochrane]

In article <33d38a16.195337670@news.geccs.gecm.com>,
Ian Begg <ian.begg@gecm.com> wrote:
>On Sun, 20 Jul 1997 14:26:19 -0700, Bertrand Meyer
><Bertrand.Meyer@eiffel.com> wrote:
>  ...
>> ...
>>    some of
>>	  the Ada enthusiasts in these newsgroups have
>>	  mistakenly taken the mention of Ariane as a personal
>>	  affront on their language. The pitch, if any, is for
>>	  the method of Design by Contract. 
>
>How many languages support Design by Contract as part of the language
>as in the case of Eiffel?  I don't have experience of a broad range of
>languages so I can't answer this.  However, if the answer is only
>Eiffel, (plus perhaps some other non relevant langauges) then it is
>not difficult to see how people might interpret your motives as "OK we
>can't be so obvious as to say Eiffel is the answer, but if we say
>Design by Contract is the answer, people will need to find a language
>to support it, hence Eiffel."  You are the only person who knows your
>real motives, but the discussions going on suggest some people are
>interpreting your motives in this way.

I have changed the subject line for this post becuase it is about the
usefulness design by contract and does not address whether it would have
helped with the Ariane 5 mishap.

Regardless of what Dr. Meyer's motives are, I think there are some
basic assumptions underlying this discussion that some people are
implicitly questioning.  The basic assumptions, as I see them, are:

1. Documenting precise specifications in the form of pre- and post-conditions
and class invariants for all component interfaces and making this
documentation easily available to anyone using the components will help
in producing systems that fulfill their requirements correctly.

2. Coding as many of these specifications as possible helps in ensuring
their precision and allows them to be checked while testing, further
increasing the chances that the systems developed in this manner will
fulfill their requirements correctly.

3. Using a language and environment that directly supports both the
documentation and the coding of these specifications will make the
specification process easier, more complete, and less error prone, thus
further increasing the chances that the systems developed in this manner
will fulfill their requirements correctly.


One point of the discussion, I believe, is that the method implied in
the above assumptions is a tool to use along with other valuable tools in
producing high-quality software; it does not replace other usefull tools
such as a good test method and plan - rather, it complements them.

Now perhaps I am biased and am not aware of valid counterarguments, but
I am not able to see how the method that would result from making use
of these assumptions, called design-by-contract in this discussion, would
not significantly increase the quality of a system of substantial size, in
the sense of producing a system that correctly fulfills its requirements.

Assuming that their are no valid counterarguments (if there are, I'm sure
people will post them), the discussion comes down to how practical it
is to implement and use an environment that supports design by contract.

As far as assumption 1., applying precise specifications for component
interfaces, the usefullness and practicality of this technique seems
obvious and just visualizing the consequences of not doing this (for
example, increased time spent figuring out what a component does,
developers' time wasted informing other developers what the interface
specification of a component is, errors in coding due to misunderstanding
an undocumented specification) should be enough to convince anyone that it
would be foolish not to apply this technique on any significant project.

The practicality of applying assumptions 2 and 3 is perhaps not as
obvious as the first assumption, but strong reasons do exist to support
their practicality.  First, coding interface specifications combined
with a good test plan will increase the chance of uncovering defects
and decrease the cost of fixing them (since it is well known that
the later a defect is found, the more it will cost to fix).  Also, using an
environment that provides rich support for the documenting and coding
of interface specifications will make it easier and less time consuming
and thus more practical for developers to use this technique.  Finally,
using such an environment would provide an infrastructure that would
allow development organizations to make the technique of design
by contract a formal part of the development process and thus make the
components of this technique - precise, complete, and testable
specifications - a part of the culture of the development organization,
so that the techniques used to produce high quality software become
habitual (in a positive sense), rather than being something foreign that
is forced upon the developers.

As I see it, Eiffel is simply an evolutionary step in the maturing
fields of computer science and software engineering.  By directly
supporting design by contract it increases the chances that a team
of capable developers will produce a quality product.  My guess is that
other languages (besides Eiffel and Sather, the only ones I'm aware of
that directly support design by contract) will appear that also support
this technique and that chances are that at least one of them will
become mainstream (in the sense of being perhaps as well-known as Java
is today, hopefully without the hype).  Some of these languages may
provide even more complete and sophisticated support for design by contract
than Eiffel and Sather.  It will be interesting to see what languages
and techniques are being used 20 or 30 years from now (for those of us
who are not retired or dead, that is :-) ).


Jim Cochrane
jtc@dimensional.com

Re: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.)

[Jon S Anthony]

In article <5r1drj$8ih@jupiter.milkyway.org> jtc@jupiter.milkyway.org (Jim Cochrane) writes:


> I have changed the subject line for this post becuase it is about the
> usefulness design by contract and does not address whether it would have
> helped with the Ariane 5 mishap.


I'm not saying that assertions don't more or less help a bit.  In many
cases they can, and it is a nice feature that Eiffel does a pretty
good job of supporting them.  But, they are not any good (well any
_much_ good) at capturing the intended context of use of whatever they
annotate.  In this sense, they don't buy you much with respect to the
so-called "contract" and, in fact, can actually lead you astray and
_cause_ problems if you take them too seriously.

This is _not_ news - it is old hat in the "formal methods" and reuse
field.  It is also basically the same thing as the problem of "natural
kinds" in knowledge representation.  Often it is not too hard to come
up with _some_ reasonable set of necessary conditions.  OTOH, it is
typically impossible to come up with a set of sufficient conditions
for all contexts of potential use.  Generally, it won't even be
possible to apriori come up with this set of contexts.

What are the necessary and sufficient conditions to call something an
"elephant" (to use an old worn out example [1])??  What are the
necessary and sufficient conditions to say that X is a usable inertial
reference component for a launch vehicle?  Ken Garlington got at this
a bit when for the X in question here, he stated the context of
intended use as "A vehicle with the Ariane IV flight profile".  Now,
you can say that is not particularly precise - but it is at least
_accurate_.  What is the "precise" set of necessary and sufficient
conditions which completely captures that statement?  What is the
precise set of necessary and sufficent conditions which completely
captures the notion of "elephant"?

Precision without accuracy is a well known form of false knowledge,
and anyone fool enough to allow himself to be comforted simply because
he has stated a whole wadge of precise conditions is going to end up
in big trouble.  It's this sort of pretentious arrogance that _will_
lull you into a false sense of security.


> implicitly questioning.  The basic assumptions, as I see them, are:
> 
> 1. Documenting precise specifications in the form of pre- and post-conditions
> and class invariants for all component interfaces and making this
> documentation easily available to anyone using the components will help
> in producing systems that fulfill their requirements correctly.
> 
> 2. Coding as many of these specifications as possible helps in ensuring
> their precision and allows them to be checked while testing, further
> increasing the chances that the systems developed in this manner will
> fulfill their requirements correctly.
> 
> 3. Using a language and environment that directly supports both the
> documentation and the coding of these specifications will make the
> specification process easier, more complete, and less error prone, thus
> further increasing the chances that the systems developed in this manner
> will fulfill their requirements correctly.


Yes, though the indications are that Meyer believes this will do more
than simply "help a bit" - he pretty much seems to believe that this
will solve the problem of reuse.  It won't.  Also, I'd add one more
that seems to be implicit: software is a kind of mathematics.  It's
not.  Software systems are much closer to elephants than to first
order systems or some such.  And no amount of wishing otherwise is
going to change this.  Those who disregard this do so at their (and
_our_) risk.  This is part of why as a pilot (and a mathematician) I
am much more comfortable with people like Ken Garlington designing and
implementing flight control software than people like Meyer.

Yes, I agree these are pretty much the assumptions.  But they are
_stunningly_ naive.


/Jon

[1] Brachman, R.J.; "I Lied about the Trees" Or, Defaults and Definitions
in Knowledge Representation, in The AI Magazine, Fall 1985
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.)

[Ken Garlington]

Jim Cochrane wrote:
> 
> Now perhaps I am biased and am not aware of valid counterarguments, but
> I am not able to see how the method that would result from making use
> of these assumptions, called design-by-contract in this discussion, would
> not significantly increase the quality of a system of substantial size, in
> the sense of producing a system that correctly fulfills its requirements.

For counterarguments, see:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Bertrand Meyer wrote:
> 
> To repeat once again the basic point made in the
> paper by Jean-Marc Jezequel and myself: it is dangerous
> and unjustifiable, especially in a mission-critical setting,
> to reuse a software element without a specification.

Geoff Eldridge <geldridg@progsoc.uts.edu.au> was kind enough
to post my draft critique of your paper in HTML format at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

Let me know if you have any comments before I submit the final
version to you at the end of the month. Thank you.

Re: The stupidity of all the Ariane 5 analysts.

[Al Christians]

It occurs to me that DBC is less than 100% applicable in this case.  As
I read it, contracts constrain the terms of interaction between clients
and servers, and as I recall, the server should expose to the client all
the methods it uses to evaluate preconditions, so that the client can
verify its compliance before requesting the service.  In the case of the
Ariane, however, the client was hardware, some kind of dumb sensor that
took physical measurements and sent them into the machine, with no real
interest in what came out later, and not enough neurons to figure out if
it was in compliance with any set of preconditions or not.  So why
should the server bother to check preconditions in this case -- after
all, the client doesn't give a rusty, so why should the server?  Who's
he gonna call? If that's a contract, then my roof is a contract between
my house and the sky.   The guys who built the roof didn't know what
wind speed it was supposed to withstand, they just built it the way they
always build them, and that's good enough.  And if the roof is spec'd to
handle winds up to 80 mph, I'm figuring that if one comes along at 85
mph, the roof isn't going to shut itself down on account of a contract
violation, it's going to try its best to hold together anyway, which is
what I'd want. OTOH, the software on the Ariane did shut itself down
while the thing was in flight, didn't it?

It would be nice if there could be a clear spec that includes everything
that might happen in the real world,  but when the real world does
something that the spec didn't anticipate, do we want the software to
just curl up and die?

Al

Re: The stupidity of all the Ariane 5 analysts.

["Paul E. Bennett"]

In article <33E06929.59F6@easystreet.com>
           achrist@easystreet.com "Al Christians" writes:

> 
> It would be nice if there could be a clear spec that includes everything
> that might happen in the real world,  but when the real world does
> something that the spec didn't anticipate, do we want the software to
> just curl up and die?

If such a spec could be produced it would probably be too large to 
understand in reasonable time. Instead, we need to construct our systems 
so that out-of-the-ordinary stimulii do not cause un-expected activity of 
the system. This involves knowing what happens in the system when the 
stimulii exceed the design limitations. This takes some effort in FMECA
and the designing in of "Inherent Robustness" for the system to become
dependable.

If we are going to re-use components, we need to be more certain about
what the effects are for component failure. In the A5 flight systems
situation, there were other factors in the organisation which blindly 
accepted the decision for non-provision of flight profiles. A risk 
assessment for the decision should have been conducted to determine if 
this was a reasonable decision.


-- 
Paul E. Bennett ................... <peb@transcontech.co.uk>
Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861                  <enquiry@transcontech.co.uk>
Going Forth Safely

Re: The stupidity of all the Ariane 5 analysts.

[Ken Garlington]

Paul E. Bennett wrote:
> 
> In article <33E06929.59F6@easystreet.com>
>            achrist@easystreet.com "Al Christians" writes:
> 
> >
> > It would be nice if there could be a clear spec that includes everything
> > that might happen in the real world,  but when the real world does
> > something that the spec didn't anticipate, do we want the software to
> > just curl up and die?
> 
> If such a spec could be produced it would probably be too large to
> understand in reasonable time. Instead, we need to construct our systems
> so that out-of-the-ordinary stimulii do not cause un-expected activity of
> the system. This involves knowing what happens in the system when the
> stimulii exceed the design limitations. This takes some effort in FMECA
> and the designing in of "Inherent Robustness" for the system to become
> dependable.

Also, FMECA/FMET is quite valuable in that it usually is not solely
driven
by the specification, but also includes past experience driven from
failure
records. We've found FMET in particular to be quite useful in finding
holes in the specification.

> If we are going to re-use components, we need to be more certain about
> what the effects are for component failure. In the A5 flight systems
> situation, there were other factors in the organisation which blindly
> accepted the decision for non-provision of flight profiles. A risk
> assessment for the decision should have been conducted to determine if
> this was a reasonable decision.
> 
> --
> Paul E. Bennett ................... <peb@transcontech.co.uk>
> Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
> +44 (0)117-9499861                  <enquiry@transcontech.co.uk>
> Going Forth Safely

Re: The stupidity of all the Ariane 5 analysts.

[Joerg Rodemann]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:
> To repeat once again the basic point made in the
> paper by Jean-Marc Jezequel and myself: it is dangerous
> and unjustifiable, especially in a mission-critical setting,
> to reuse a software element without a specification.

Agreed: it should be clearly stated what something is intended for. Although
the idea of preconditions sound very good to me at first sight I am very
sceptical if this is very useful at all since one has to think of EVERY
possibility the routine might be used for. E. g. assume the implementation
of some mathematical function that is not well defined for the complete
complex plane or not continously defined for real numbers. On the other
hand you might have an algorithm at hand that is suitable for every value
the function is defined. (Maybe the Gamma, Beta and Zeta functions are
some examples that meet my assumptions --- I can't remember them exactly right
now.) On the other hand you know that for your actual problem this function
is indeed defined for each possible value since you are --- from your
requirements --- quite sure that some area will not be left. So you could
enter this as a precondition. 

But now guess you like to use this component for some other work --- and 
you are not dealing with complex numbers of different areas of the plane.
It seems to me that you list of preconditions will grow very fast ---
leaving the code quite unreadable. (Kind of a " i++;  // increments i" type
comment.) Code is the more difficult to comprehend the large it is. And
especially emphasizing details may obscure the essential parts. Was not
this abstraction was all about?

From this point of view I would think that easy checkable preconditions
should be checked (e. g. using assertions). Others should be kept in the
documentation. As far as Ariane V is concerned the report clearly states
that the problem was know and discussed during develepment but due to
cpu time limits not every suspected variable was covered. It seems to me
that a lack of knowledge about the actual application was one reason for
the error to occur. (Among the devastating assumption that exceptions are
only to occur when hardware fails!) No pre-/postcondition theology would have
cured that, IMHO. (I believe no methodology could cure that. and this might
be a problem that is not easy if at all to solve for systems that complex.)

Well, just my humble opinion...and I have to admit that I have no experions
within realtime or safety critical applications development.

Yours sincerly

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Safety-critical development in Ada and Eiffel - Ariane crash

[Joachim Durchholz]

Ken Garlington wrote:
> 
> Jean-Marc Jezequel wrote:
> > At the risk of repeating myself, and reopening a thread beaten to
> death,
> > the all point of design by contract (DBC) is to
> > make this kind of assumptions explicit.
> 
> Which would not have happened in the Ariane V case.
> 
> > Ariane 5 is just a nice striking example
> > of working with assumptions that are true at a point in time (Ariane
> 4) and no longer
> > later on (Ariane 5). I think we agreed on this previously.
> 
> Yes. However, the assumption would not have been documented via an
> Eiffel assertion,
> as I claimed and you/Meyer never refuted (except to exclaim,
> "casuistry!").

Maybe nobody put all the relevant parts of the picture together yet. Let
me try to explain:

An Eiffel assertion serves a dual purpose:
As a run-time check, it is the equivalent of array bounds checking. The
programmer gets hit on his fingers hard and early when he calls a
routine without making sure the preconditions are satisfied, or (less
important to our discussion) writes a routine that violates its
postcondition or the class invariant.
The second purpose is that of documentation. Assertions are an integral
part of a routine's signature, and serve the same purpose as the type
declarations for routine parameters. The only difference is that type
checking can be done at compile time, while assertion checking must be
deferred to run-time (at least with current compiler technology).

Now imagine we're organizing class docucmentation differently than
usual: All documentation takes the form of source code. Specifications
are made into deferred (abstract) classes, with no routines implemented.
To implement a class, the programmer takes the specification class and
overrides deferred routines with implementations.
In such a scenario, the specification would not have been overlooked.
The restriction on input values might not have been enforced with a
run-time check, but it would have shown up as an (unchecked) assertion.

AFAIK the restrictions on the flight control software were known, but
buried in some remote document. Tying code and specification together
should have prevented the crash.

BTW nothing in this discussion has anything to do with object
orientation, or with the many other design decisions of Eiffel. The
point is just that

  ASSERTIONS SHOULD BE A STANDARD PART OF ROUTINE INTERFACES.

And I can't find anything wrong about that.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel - Ariane crash

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> >
> > Jean-Marc Jezequel wrote:
> > > At the risk of repeating myself, and reopening a thread beaten to
> > death,
> > > the all point of design by contract (DBC) is to
> > > make this kind of assumptions explicit.
> >
> > Which would not have happened in the Ariane V case.
> >
> > > Ariane 5 is just a nice striking example
> > > of working with assumptions that are true at a point in time (Ariane
> > 4) and no longer
> > > later on (Ariane 5). I think we agreed on this previously.
> >
> > Yes. However, the assumption would not have been documented via an
> > Eiffel assertion,
> > as I claimed and you/Meyer never refuted (except to exclaim,
> > "casuistry!").
> 
> Maybe nobody put all the relevant parts of the picture together yet. Let
> me try to explain:
> 
> An Eiffel assertion serves a dual purpose:
> As a run-time check, it is the equivalent of array bounds checking. The
> programmer gets hit on his fingers hard and early when he calls a
> routine without making sure the preconditions are satisfied, or (less
> important to our discussion) writes a routine that violates its
> postcondition or the class invariant.
> The second purpose is that of documentation. Assertions are an integral
> part of a routine's signature, and serve the same purpose as the type
> declarations for routine parameters. The only difference is that type
> checking can be done at compile time, while assertion checking must be
> deferred to run-time (at least with current compiler technology).
> 
> Now imagine we're organizing class docucmentation differently than
> usual: All documentation takes the form of source code. Specifications
> are made into deferred (abstract) classes, with no routines implemented.
> To implement a class, the programmer takes the specification class and
> overrides deferred routines with implementations.
> In such a scenario, the specification would not have been overlooked.
> The restriction on input values might not have been enforced with a
> run-time check, but it would have shown up as an (unchecked) assertion.

Assuming that someone 

  1. would have written the check: "Airframe shall comply with Ariane IV
     flight profile" (try coding that sometime!), and

  2. that the reviewer had done this manual check properly amongst all
     of the other manual checks that a large number of assertions would
     imply (or, as the final report states: "Given the large amount of
     documentation associated with any industrial application, the
assumption,
     although agreed, was essentially obscured, though not deliberately,
     from any external review."),

he would have been told "of course the airframe complies with that
profile,
that's why we don't need to retest!" To quote again from the final
report:

"The reason for the three remaining variables, including the one
denoting
horizontal bias, being unprotected was that further reasoning indicated
that they were either physically limited or that there was a large
margin
of safety, a reasoning which in the case of the variable BH turned out
to
be faulty. It is important to note that the decision to protect certain
variables but not others was taken jointly by project partners at
several
contractual levels."

There is no evidence that any trajectory data were used to analyse the
behaviour of the unprotected variables, and it is even more important
to note that it was jointly agreed not to include the Ariane 5
trajectory
data in the SRI requirements and specification."

Considerable (although incorrect) thought went into this decision.

So, your statement may be true, but it doesn't appear to be relevant.

> 
> AFAIK the restrictions on the flight control software were known, but
> buried in some remote document. Tying code and specification together
> should have prevented the crash.

Since it wasn't flight control software, but inertial reference
software,
that had the problem, this seems to be an odd statement.

More odd is the assumption that system engineers (the ones most likely
to know the differences in flight profile) read code before they read
documentation. My experience is just the opposite.

> 
> BTW nothing in this discussion has anything to do with object
> orientation, or with the many other design decisions of Eiffel. The
> point is just that
> 
>   ASSERTIONS SHOULD BE A STANDARD PART OF ROUTINE INTERFACES.
> 
> And I can't find anything wrong about that.

I can find several things wrong with it, having experience with
safety critical systems.


> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> > You would use them anywhere that a piece of code makes assumptions.
> For example,
> > to help avoid the Ariane fiasco, include contracts in the INS(?)
> that specify
> > Ariane 4 dynamics. Then, in testing, you will get an assertion
> violation when
> > you apply Ariane 5 dynamics to it.
> 
> This is why my blood pressure goes up!
> 
> The _Ada_ implementation did generate an assertion violation the very
> first time
> Ariane 5 dynamics were applied to it. Unfortunately, the very first
> time
> Ariane 5
> dynamics were applied to it was at LANUCH!
> 
> They were not applied earlier, because the contractor assumed that the
> Ariane 5
> dynamics were the same as the Ariane 4, so why spend the money testing
> to the same
> conditions already tested earlier? (They were wrong, of course, but
> they
> didn't know
> that at the time).

<Sigh> that misunderstanding again. The issue in the Ariane-5 paper by
Meyer and Jezequel isn't that the preconditions per se would have
changed anything. The issue is that the preconditions would have been an
integral part of the routine's signature, and thus not likely to have
been overlooked by the team that ported the Ariane-4 code to Ariane-5.
As it were, the preconditions were buried in some obscure part of the
documentation, and management didn't reread everything when they reused
the code (together with its hardware).

The paper may not be very clear in this respect (I got Meyer's view on
the topic from his book, not from the paper), or people might
misinterpret what it's saying.

> According to Meyer, et. al. Eiffel programmers would have written the
> handler
> differently, and also they would have known to do the testing
> differently (even though
> the requirements specification said that the tests need not change).

No. They would have written the handler the same way, and documented the
precondition with the routine where it belongs, not in some obscure spec
sheets that are shelved away.

> However, their
> explanation as to why this is true is far from convincing (basically,
> that "Eiffel
> programmers believe in quality" or some such nonsense).

Well, believing in quality is far from nonsense. And assertions do
certainly promote a certain style of quality-mindedness.
It is similar to declaring types for routine parameters. Early C didn't
have them, current C compilers have them. And besides catching lousy
errors, the need to declare parameter types makes the programmers
*think* about what's the right type for a parameter, instead of just
writing it down. A similar mechanism is at work with assertions and
Eiffel programmers.

> They believe that "software is software." and apply the
> expertise in their
> domain to mine.

Well, their finding may have been badly presented, but I think the
"software is software" approach is valid. Of course there are
differences between various levels of safety requirements, but some
basic themes apply all the same - like static typing, or the need to
choose meaningful names, etc. Meyer believes that assertions should be
considered one of these basic themes, and that assertions might have
prevented the Ariane-5 crash, for the reasons given above. (And I'm very
much with him, though I'm not informed enough about the Ariane-5 crash
to decide wether it is a particularly good example of the issue.)

> I am aware of at least one project developing an embedded missile
> controller,
> that did exactly what you describe (in Ada). Here's what happened:
> 
> 1. Their timings changed, which introduced some subtle differences in
> the
> relationships between tasks and external interrupts. Some of these
> subtle
> differences invalidated their original testing.

Timing on that basis is the one thing that Eiffel isn't built for.
Adding a new class might not change subtle timings, it might totally
alter the microscopic behaviour of the program. For example,
non-polymorphic routine calls that could be statically bound by the
compiler might become polymorphic and required a dynamic dispatch.
Fine-tuning code so that certain routines are guaranteed to take at
least x ms and at most y ms sounds to me like a very difficult and
fragile thing to achieve in Eiffel.

> 3. At least one compiler bug was introduced, which was definitely
> unsettling.

That's a problem of compiler quality. Eiffel doesn't guarantee perfect
compilers, but assertions should make bugs less likely.

> The other prong of this is that, while assertions are keen for
> catching
> design problems, I haven't seen much evidence that they catch
> high-level
> requirements problems (not surprising, since the code was presumably
> written
> to match the requirements). In 13 years of developing safety-critical
> embedded systems, our process tends to handle design problems fairly
> early.
> It's those high-level requirements problems where we need the most
> help.

Eiffel is the only language that I know that can scale up to formalizing
high-level requirements. The technique is easy: write a few abstract
("deferred") classes that aren't much more than a set of routine
signatures and assertions.
One can even implement such a system: Just take the design classes as
ancestors for your implementation classes. Descendants must keep the
assertions, so your code is guaranteed to match the specs (in a way -
assertions aren't statically checked).

> But almost all of our safety-critical threads are hard realtime
> threads!
> That's a HUGE limitation for our systems!

Well, if you don't have confidence in the compiler, there isn't much you
can do to remove assertions (or run-time range checking, which are a
limited form of assertions).
But in this domain there's no difference between Eiffel and Ada - the
problem's the same, and there is no satisfactory solution available.

BTW I'm somewhat curious how these subtle timing differences come to
have practical consequences. I'm not a hard real-time engineer, so I'd
expect it doesn't matter if a routine runs faster than expected. How
come that your experience is obviously different?

> What is the process to certify Eiffel compilers as being acceptably
> mature
> (code generation-wise) for safety-critical systems? Is all testing
> performed
> with assertions on and assertions off in all test cases?

There isn't even a testbed available - probably because nobody earnestly
demanded it yet.

> However, what about the topic of this thread (safety-critical
> systems)?
> It sounds
> like there's a lot of limitations as to using (and inheriting)
> assertions for
> this environment.

I think OO in general is difficult to apply here. You obviously need
tight control on the code generated, to control the timings. A good
Eiffel compiler will do a global analysis of the system and apply
inter-routine optimizations. This makes the type of control you desire
difficult, and I'm not sure wether the better reliability is worth the
price.

> > :Of course, Bertand Meyer's Eiffel website insists that even
> > :misinterpretation of
> > :requirements (Ariane V) will be a problem no longer when Eiffel is
> used!
> >
> > Come on. He's not saying that.
> 
> Read his analysis of Ariane V. He says _exactly_ that, and has
> defended
> saying that in multiple newsgroups. A smart person, but not someone
> who knows my domain particularly well.

The Ariane-5 crash wasn't a requirements misinterpretation. It was
overlooking a part of the requirements.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> > > You would use them anywhere that a piece of code makes assumptions.
> > For example,
> > > to help avoid the Ariane fiasco, include contracts in the INS(?)
> > that specify
> > > Ariane 4 dynamics. Then, in testing, you will get an assertion
> > violation when
> > > you apply Ariane 5 dynamics to it.
> >
> > This is why my blood pressure goes up!
> >
> > The _Ada_ implementation did generate an assertion violation the very
> > first time
> > Ariane 5 dynamics were applied to it. Unfortunately, the very first
> > time
> > Ariane 5
> > dynamics were applied to it was at LANUCH!
> >
> > They were not applied earlier, because the contractor assumed that the
> > Ariane 5
> > dynamics were the same as the Ariane 4, so why spend the money testing
> > to the same
> > conditions already tested earlier? (They were wrong, of course, but
> > they
> > didn't know
> > that at the time).
> 
> <Sigh> that misunderstanding again. The issue in the Ariane-5 paper by
> Meyer and Jezequel isn't that the preconditions per se would have
> changed anything. 

Actually, they base the claim on three possibilities, although they
immediately withdraw one (assertion performance during execution).
In addition to the documentation benefits, they state:

"Assertions (preconditions and postconditions in particular) can be
automatically turned on during testing, through a simple compiler
option.
The error might have been caught then."

There are several flaws with this statement, which I have addressed
previously. However, since you have agreed that this would not
have changed anything, I'll skip the analysis of this point.

> The issue is that the preconditions would have been an
> integral part of the routine's signature, and thus not likely to have
> been overlooked by the team that ported the Ariane-4 code to Ariane-5.

There are several flaws in this statement. Since I have addressed them
before in detail, I will summarize them now.

1. There is no evidence that the right precondition (which is not a
simple
   precondition) would have been inserted in the code even using DBC.
   (There is not necessarily a simple correlation between the flight
   profile and the HZ variable in question.)

2. There is no evidence that the reviewer would have had access to the
   Ariane 5 flight profile data necessary to detect the precondition
   violation. (The final report notes that the data was withheld
intentionally,
   with concurrence at several levels. Without this data, the reviewer
   would have been assured that the problem could not occur.)

3. There is no evidence that, if inserted, it would have been reviewed
   by a system engineer, or someone else with the ability to correlate
   the flight profile with the HZ range. (The final report implies that
the
   system specification or a "justification document" might be a more
logical
   place, and that a special team be generated to review these
documents.)

4. There is no evidence that, if inserted, the precondition violation
   would have been manually detected amongst the sea of other
preconditions
   that would have to be manually checked. (The final report makes note
   of the complexity of the system and the difficulty of such analyses,
   and recommends several other items, such as realistic testing, to
   compensate for this difficulty.)

> As it were, the preconditions were buried in some obscure part of the
> documentation, and management didn't reread everything when they reused
> the code (together with its hardware).
> 
> The paper may not be very clear in this respect (I got Meyer's view on
> the topic from his book, not from the paper), or people might
> misinterpret what it's saying.

I don't misinterpret it at all. I merely note that, _in this case_,
there
is no evidence it would have changed anything.

> > According to Meyer, et. al. Eiffel programmers would have written the
> > handler
> > differently, and also they would have known to do the testing
> > differently (even though
> > the requirements specification said that the tests need not change).
> 
> No. They would have written the handler the same way, and documented the
> precondition with the routine where it belongs, not in some obscure spec
> sheets that are shelved away.

Interesting, because the final report notes quite explicitly that the
handler was also a source of the error:

"Although the source of the Operand Error has been identified, this in
itself did not cause the mission to fail. The specification of the
exception-handling mechanism also contributed to the failure."

Thus, if _any_ of the four points above apply, then the results would
have been the same.

Meyer's paper makes no mention of the exception handling approach
defined for DBC; thank you for clarifying this.


> 
> > However, their
> > explanation as to why this is true is far from convincing (basically,
> > that "Eiffel
> > programmers believe in quality" or some such nonsense).
> 
> Well, believing in quality is far from nonsense. And assertions do
> certainly promote a certain style of quality-mindedness.
> It is similar to declaring types for routine parameters. Early C didn't
> have them, current C compilers have them. And besides catching lousy
> errors, the need to declare parameter types makes the programmers
> *think* about what's the right type for a parameter, instead of just
> writing it down. A similar mechanism is at work with assertions and
> Eiffel programmers.

The "nonsense" is that Eiffel programmers have a corner on such
thinking.
Meyer's paper states that "The ESA's software people knew what they were
doing and applied widely accepted industry practices" (the latter
half of this statement is contradicted by the final report), but then
goes on to say "Any team worth its salt would have checked
systematically
that every call satisfies the precondition." Such a statement is
hopelessly naive, as noted above: there are several factors that would
have worked to defeat the best-intentioned review team. None of these
are addressed in the paper (or afterwards).

> 
> > They believe that "software is software." and apply the
> > expertise in their
> > domain to mine.
> 
> Well, their finding may have been badly presented, but I think the
> "software is software" approach is valid. Of course there are
> differences between various levels of safety requirements,

An internally contradictory statement. Can you define these differences,
and explain why they are not a potential factor for this subject?

> but some
> basic themes apply all the same - like static typing, or the need to
> choose meaningful names, etc. Meyer believes that assertions should be
> considered one of these basic themes, and that assertions might have
> prevented the Ariane-5 crash, for the reasons given above. (And I'm very
> much with him, though I'm not informed enough about the Ariane-5 crash
> to decide wether it is a particularly good example of the issue.)

I think you've put your finger on it. People who are Meyer fans, but
not particularly well informed on the Ariane 5 issue, believe Meyer.
People with experience in these kinds of safety-critical systems do
not, at least from what I can tell. Furthermore, there is no
evidence that the paper was even reviewed by someone on the Ariane 5
team, or even someone with a background in such systems, prior to
its publication. I always thought peer review was an essential part of
any scholarly paper.

Note that your statement is wrong, by the way. I could forgive Meyer
to some extent if he had said that assertions "might" have
prevented the Ariane-5 crash. He goes much further: He states that
they "probably" would have avoided the crash. Such a statement carries
with it a much stronger proof requirement, which he fails to provide.

> 
> > I am aware of at least one project developing an embedded missile
> > controller,
> > that did exactly what you describe (in Ada). Here's what happened:
> >
> > 1. Their timings changed, which introduced some subtle differences in
> > the
> > relationships between tasks and external interrupts. Some of these
> > subtle
> > differences invalidated their original testing.
> 
> Timing on that basis is the one thing that Eiffel isn't built for.
> Adding a new class might not change subtle timings, it might totally
> alter the microscopic behaviour of the program. For example,
> non-polymorphic routine calls that could be statically bound by the
> compiler might become polymorphic and required a dynamic dispatch.
> Fine-tuning code so that certain routines are guaranteed to take at
> least x ms and at most y ms sounds to me like a very difficult and
> fragile thing to achieve in Eiffel.

It is a difficult and fragile thing in any language, and best avoided.
More to the point, it is important in testing to look for such
fragile dependencies (race conditions & deadlock in particular). This
testing cannot be done on code with significantly different timing
properties
than the production system.

> 
> > 3. At least one compiler bug was introduced, which was definitely
> > unsettling.
> 
> That's a problem of compiler quality. Eiffel doesn't guarantee perfect
> compilers, but assertions should make bugs less likely.

I presume you mean assertions in the compiler, since obviously the
assertions can't be relied upon to detect errors in the application
at this point. Is there evidence that Eiffel compilers use assertions
extensive internally? Is there evidence that, as a result, they have
far fewer bugs than other compilers? (These aren't idle questions;
if this is the case, this is actually a valid argument for the use of
Eiffel in safety-critical systems that hasn't been offered to date.)


> 
> > The other prong of this is that, while assertions are keen for
> > catching
> > design problems, I haven't seen much evidence that they catch
> > high-level
> > requirements problems (not surprising, since the code was presumably
> > written
> > to match the requirements). In 13 years of developing safety-critical
> > embedded systems, our process tends to handle design problems fairly
> > early.
> > It's those high-level requirements problems where we need the most
> > help.
> 
> Eiffel is the only language that I know that can scale up to formalizing
> high-level requirements. The technique is easy: write a few abstract
> ("deferred") classes that aren't much more than a set of routine
> signatures and assertions.
> One can even implement such a system: Just take the design classes as
> ancestors for your implementation classes. Descendants must keep the
> assertions, so your code is guaranteed to match the specs (in a way -
> assertions aren't statically checked).

I am skeptical that Eiffel is a good language for SRSs. Is there any
evidence that it has been used this way? Are there issues about
the notation being easy to understand by non-programmers?

> 
> > But almost all of our safety-critical threads are hard realtime
> > threads!
> > That's a HUGE limitation for our systems!
> 
> Well, if you don't have confidence in the compiler, there isn't much you
> can do to remove assertions (or run-time range checking, which are a
> limited form of assertions).
> But in this domain there's no difference between Eiffel and Ada - the
> problem's the same, and there is no satisfactory solution available.

Exactly. Again, I think you agree with me that the non-documentation
aspects of Eiffel assertions can be discounted with respect to the
Ariane 5 -- killing two of three of Meyer's arguments. Now, all you
have to do is agree with any one of my four points on documentation,
and we can put this argument to bed :)

I've noticed several times that Eiffel advocates try to make this
a langauge debate betwen Ada and Eiffel. I could care less. I've made
the same points about Ada that I make about Eiffel.


> 
> BTW I'm somewhat curious how these subtle timing differences come to
> have practical consequences. I'm not a hard real-time engineer, so I'd
> expect it doesn't matter if a routine runs faster than expected. How
> come that your experience is obviously different?
> 
> > What is the process to certify Eiffel compilers as being acceptably
> > mature
> > (code generation-wise) for safety-critical systems? Is all testing
> > performed
> > with assertions on and assertions off in all test cases?
> 
> There isn't even a testbed available - probably because nobody earnestly
> demanded it yet.

This seems odd. If Eiffel compilers use assertions, then why wouldn't
the compielr development team, which presumably is "worth its salt,"
establish the high level of quality you assert is the province of
all Eiffel programmers? Why would someone need to "demand" a means to
measure and improve the quality of the toolset?

> 
> > However, what about the topic of this thread (safety-critical
> > systems)?
> > It sounds
> > like there's a lot of limitations as to using (and inheriting)
> > assertions for
> > this environment.
> 
> I think OO in general is difficult to apply here. 

I'm not convinced of this, BTW; I have seen at least object-based
safety-critical real-time systems operate quite nicely. I have also
seen some features of OO not found in object-based designs (e.g.
full polymorphism) used on mission-critical real-time systems, and
I expect that we will use at least some of this in our future
safety-critical systems.

> You obviously need
> tight control on the code generated, to control the timings. A good
> Eiffel compiler will do a global analysis of the system and apply
> inter-routine optimizations. This makes the type of control you desire
> difficult, and I'm not sure wether the better reliability is worth the
> price.

Ada compilers do extensive inter-routine optimizations in our
safety-critical systems. Again, you misunderstand: it's not that the
object code is complex; it is that the object code tested needs to
be the object code delivered.

> 
> > > :Of course, Bertand Meyer's Eiffel website insists that even
> > > :misinterpretation of
> > > :requirements (Ariane V) will be a problem no longer when Eiffel is
> > used!
> > >
> > > Come on. He's not saying that.
> >
> > Read his analysis of Ariane V. He says _exactly_ that, and has
> > defended
> > saying that in multiple newsgroups. A smart person, but not someone
> > who knows my domain particularly well.
> 
> The Ariane-5 crash wasn't a requirements misinterpretation. It was
> overlooking a part of the requirements.

To quote directly from the final report:

"it is even more important to note that it was jointly agreed not to
include the Ariane 5 trajectory data in the SRI requirements and
specification."

I know that Meyer's report makes no note of this fact (it would
weaken his argument considerably if he did!). This is why you need
to read the final report for yourself and compare it critically to
Meyer's interpretation, as I did. Even without a background in this
area, you should see some contradictions.

Meyer, in fact, says: "The requirement that the horizontal bias should
fit on 16 bits was in fact stated in an obscure part of a document.",
but the final report says something a little different: "...three of
the variables were left unprotected. No reference to justification of
this decision was found directly in the source code. Given the large
amount of documentation associated with any industrial application,
the assumption, although agreed, was essentially obscured, though not
deliberately, from any external review." This quote refers to the
deliberate decision by the Ariane 4 designers to _not_ state this
requirement (more importantly, not to _handle_ the case in the code
in the right manner) which, ultimately, caused the failure. How Meyer
got his statement from this, I have no idea.

Don't take my word for it (or Meyer's!): read the report at:

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Ada vs Eiffel (was: Safety-critical development in ...)

[W. Wesley Groleau x4923]

> I presume you mean assertions in the compiler, since obviously the
> assertions can't be relied upon to detect errors in the application
> at this point. Is there evidence that Eiffel compilers use assertions
> extensive internally? Is there evidence that, as a result, they have
> far fewer bugs than other compilers? (These aren't idle questions;
> if this is the case, this is actually a valid argument for the use of
> Eiffel in safety-critical systems that hasn't been offered to date.)

Note that a particular high-quality Ada compiler is known to use
assertions extensively internally.  Or does it?

When is an assertion not an assertion?

Perhaps we could end this argument by designing a hybrid of Ada and
Eiffel--if you can't beat 'em, join 'em.  

We could call it Afel (rhymes with waffle).

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada vs Eiffel (was: Safety-critical development in ...)

[Matt Kennel (Remove 'NOSPAM' to reply)]

On Mon, 21 Jul 1997 18:52:28 GMT, W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
:Note that a particular high-quality Ada compiler is known to use
:assertions extensively internally.  Or does it?
:
:When is an assertion not an assertion?

An assertion is just that, an assertion that some particular state
should exist at some time. 

A precondition, for example, is more specific, in that it specifies who
is at fault if its assertion is violated.  And furthermore, this condition
is intended to be visible to outside users.  

It is but a small technical change, but a larger social and mental
change.  

The presumption is that fixing software to fit their specifications is
more likely to be profitable than just eliminating the assertion violation.

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           -
* "People who send spam to Emperor Cartagia... vanish! _They say_ that
* there's a room where he has their heads, lined up in a row on a desk...
* _They say_ that late at night, he goes there, and talks to them... _they
*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"

Re: Safety-critical development in Ada and Eiffel

[Robert S. White]

In article <33CD578D.562CC6A4@munich.netsurf.de>, 
joachim.durchholz@munich.netsurf.de says...
>

>changed anything. The issue is that the preconditions would have been an
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>integral part of the routine's signature, and thus not likely to have
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>been overlooked by the team that ported the Ariane-4 code to Ariane-5.
 ^^^^^^^^^^^^^^^

  Wrong!  The code was _REUSED_ as is and nothing new was even looked 
at.  The systems engineers did not even allow for the chance of
a review/reading of embedded Ariane 4 preconditions in the software 
source code.  They don't read the Ada code and they would not have
read any Eiffel source code.  They should have reviewed and modified
the system requirements and then (somebody) showuld have flowed the 
changes down to the software requirements.  NOT A LANGUAGE ISSUE!


>As it were, the preconditions were buried in some obscure part of the
>documentation, and management didn't reread everything when they reused
>the code (together with its hardware).

  EXACTLY!   But the fight dynamics in a system requirements spec IS
NOT an  _obscure_ part of the documentation!
>
>The paper may not be very clear in this respect (I got Meyer's view on
>the topic from his book, not from the paper), or people might
>misinterpret what it's saying.
 
  Yes his sanctimonious preaching of this "Eiffel only" DBC 
"magic bullet" to practioners in this particular hard real-time 
safety-critical difficult INS/IRS software domain has raised our 
collective blood pressures.  It is not to say that DBC is not a 
good thing _When_ it can be readily applied.

>
>> According to Meyer, et. al. Eiffel programmers would have written the
>> handler
>> differently, and also they would have known to do the testing
>> differently (even though
>> the requirements specification said that the tests need not change).
>
>No. They would have written the handler the same way, and documented the
>precondition with the routine where it belongs, not in some obscure spec
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
>sheets that are shelved away.

  You do _not_ know what your are talking about here.  This type of
requirement _MUST_ be in the software requirements document!!!

...rest of post deleted, stopping now, to let my blood pressure 
drop down.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Safety-critical development in Ada and Eiffel

[nabbasi]

>
>In article <33CD578D.562CC6A4@munich.netsurf.de>, 
>joachim.durchholz@munich.netsurf.de says...
>>
>
>>As it were, the preconditions were buried in some obscure part of the
>>documentation, and management didn't reread everything when they reused
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>the code (together with its hardware).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

this is so funny. since when management "read" code and "use" code any way? 
if "management" is anything I remember, most have no clue what code is. it
is the responsibility of the programmer to do this, management is there just
to sign the final paperwork :)

now back to the main topic...

Nasser

Re: Safety-critical development in Ada and Eiffel

[W. Wesley Groleau x4923]

> this is so funny. since when management "read" code and "use" code any way?

I once heard, "COBOL was designed to make it possible for managers to
read programs.  Instead, it successfully proved that managers don't 
read programs."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Sorry for taking a while to get back to you..

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :Don Harrison wrote:
:> :>
:> :> If even this small overhead is unacceptable, you can force static binding
:> :> where necessary by freezing routines.
:> :> Although you forgo the flexibility of
:> :> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
:> :> synonyms - these allow you to declare a routine under different names.
:> :
:> :But I can do this in Ada, as well, so I don't see the benefit.
:> 
:> I'm not saying there is any extra benefit - merely that you don't have to
:> wear the overhead of dynamic binding if you're desperate to maximise efficiency.
:> Tucker mentioned that overhead. I'm saying it isn't an issue.
:
:But you also said that it was required to use that part of Eiffel
:inheritance not
:available in Ada. 

No, you've misunderstood. What I'm saying is:

  1) If you want to forget about using polymorphism in Eiffel, you can force 
     static binding by freezing features. This prevents you from redefining 
     that feature in a descendant.
  2) However, if you want to leave open the possibility of redefining you 
     can call a feature by two names - do_something and frozen_do_something.
     This allows you to use frozen_do_something in all calls (thus forcing
     static binding) and still be able to redefine the feature via the other name.
     (See my previous post for the example of "equal" and "frozen_equal").

Whether or not you can acheive the same thing with tagged types and renaming
I wouldn't have a clue.


:In this statement, you seem to be saying that if I
:want an
:efficient safety-critical system (which I always do), I have to give us
:some of
:that extra inheritance.

Not inheritance but polymorphism.

: Do I need the full Eiffel inheritance model, or
:don't I?

Probably not - don't know.


:> BTW, how do call a procedure under different names in Ada?
:
:Via the "rename" statement.
:
:> 
:> : :Does this "pre-allocated memory pool" mean that you will know exactly
:> :> :what address
:> :> :each object's data will reside at, or merely that you dynamically
:> :> :allocate memory
:> :> :at initialization and do not dynamically allocate after initialization
:> :> :is complete?
:> :>
:> :> The latter. You don't actually need to know *where* objects are allocated,
:> :> merely that there is sufficient memory to allocate them.
:> :
:> :Actually, in my systems, I do need to know where they are allocated, so
:> :that
:> :I can examine them from the hideously crude display in the cockpit
:> :during
:> :troubleshooting.
:> 
:> That *is* hideously crude (and brings back some bad memories). Depending on how
:> crude you mean, maybe a primitive tool could give you a map of where objects get
:> put in memory. If you mean incredibly crude, use non-reference (expanded in
:> Eiffel) types and use a linker-generated memory map.
:
:Both approaches require that the memory address be known before
:execution time,
:however, so I still care where objects are located. I also care for
:other reasons,
:such as memory-mapped I/O, of course.

Yes.


:> :> Maybe general assertions are more common than you imagine. However, I agree
:> :> that range constraints are roughly covered by Ada subtypes. I use them liberally
:> :> for just that purpose.
:> :
:> :Maybe, but again, I would like to see how these complex assertions are
:> :used.
:> 
:> You would use them anywhere that a piece of code makes assumptions. For example,
:> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
:> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
:> you apply Ariane 5 dynamics to it.
:
:This is why my blood pressure goes up!

Well, this was naive of me wasn't it? In mentioning the very word "Ariane" 
a thousand assumptions come flooding into some people's minds about what you
are implying. I was implying nothing - just responding to your request for 
an example of a high level assertion. I did not intend to imply any deficiency 
of Ada in this or anything else that you may have assumed.

So, here's a different example. In my key handling object (one of the highest
level in the simulation), there's an operation for interpreting the CLEAR key.
Simplifying a little, pressing this key should reactivate the menu, clear the 
key sequence and clear any menu or sub-menu selection. So, there's a compound
postcondition thus:

      if SA.ASSERTIONS_ON and then (INPUT_STATE /= MENU or else 
        NO_OF_KEYS /= 0 or else MENU_OPTION_SELECTED or else
        SUBMENU_OPTION_SELECTED) then
        raise SA.POSTCONDITION_ERROR;

Note that some of the components are functions. Wrapping them in this way 
is typical practice in Eiffel and enables you to use them elsewhere (eg. in 
if-statements in the code proper) and makes contracting scalable.


:The _Ada_ implementation did generate an assertion violation the very
:first time
:Ariane 5 dynamics were applied to it. Unfortunately, the very first time
:Ariane 5
:dynamics were applied to it was at LANUCH!

Yes. 


:They were not applied earlier, because the contractor assumed that the
:Ariane 5
:dynamics were the same as the Ariane 4, so why spend the money testing
:to the same
:conditions already tested earlier? (They were wrong, of course, but they
:didn't know
:that at the time).

Not a good assumption.


:The other part of the problem was that the _response_ to the assertion
:violation was
:wrong. The designer assumed the assertion would occur due to a hardware
:failure, not
:a software requirements failure, and so the handler shut down the
:"offending" hardware,
:rather than attempting some other action (e.g. replacing the
:out-of-range value with
:a "safe" value)..

Clearly, the assumptions weren't properly thought out. Getting them right 
would have made the difference.


:According to Meyer, et. al. Eiffel programmers would have written the
:handler
:differently, and also they would have known to do the testing
:differently (even though
:the requirements specification said that the tests need not change).

I don't know about you, but I tend to take a pretty skeptical view of 
requirements because they often have holes in them. It pays to be a bit 
circumspect. With regard to whether an Eiffel software engineer would have 
picked up the false assumption compared with an Ada SE - possibly, due to the 
fact that they are conditioned by their use of contracting to *think* of as 
many assumptions as possible so they can code them as assertions. This sort of 
conditioning is much less prevalent among Ada developers because most don't 
use contracting (in this disciplined sense). I *know* this is true because I 
work with them. Of course, they may be (and probably are) more disciplined 
in your domain simply because they *have* to be. However, the conditioned 
cultural difference due to disciplined contracting would be an advantage. 

For your domain it's a bit of a Catch-22. Contracting would improve the culture 
but you're unable to use it due to hard timing constraints.

 
:However, their
:explanation as to why this is true is far from convincing (basically,
:that "Eiffel
:programmers believe in quality" or some such nonsense). 

No, it's the conditioning that makes the difference. There are a lot of 
Ada software engineers who *are* serious about quality (including you, I expect). 
Using DBC just makes you more effective.


:This is why I dislike people with no background in safety-critical
:flight systems discussing
:such issues. They believe that "software is software." and apply the
:expertise in their
:domain to mine. 

Well, having worked in a range of application areas from HRT to 4GL/database, 
I can say this is both true and false. What I mean is there are some principles 
(eg. how to structure code etc.) that don't change irrespective of whether 
you're developing an embedded system or a GUI-based client application on a PC. 
There are also things that *do* change. In particular, the options available 
to you progressively decrease and the development environment becomes more 
hostile as you move further towards the HRT end of the scale (as you know).


:> :Again, the code I've seen to date doesn't seem to use them that much.
:> 
:> If you're looking in Ada code, you're looking in the wrong place because few
:> Ada developers recognise there are additional benefits from using them in
:> addition to static typing and the predefined contracts already in Ada
:> (the conditions under which predefined exceptions - eg. Constraint_Error -
:> are raised).
:
:No - I'm looking at Eiffel code. 

Well, you must be looking in the wrong place. I don't know whether anyone 
has given any pointers yet as to where you can find some. Suggestions?..


:> Static typing gives you static contract checking. Assertions (predefined and
:> user-defined give you dynamic contract checking *during development*. What
:> most Ada software engineers miss out on is the user-defined variety which
:> bring a non-trivial benefit to reliability and reuse.
:
:Not this Ada engineer! I have dynamic assertions all over the place in
:my
:tools!

Terrific!


:My problem, again, is in the fundamental nature of dynamic assertions
:for safety-critical
:embedded systems, which have some unique risks, whether you (a) leave
:them in after development, 

Not recommended for your application area.

:or (b) take them out after developmental testing, but
:before usage.

In this case, the software should be regression tested.


:> They are only turned on during development, so what you do is fix the underlying
:> problem which is usually not difficult to find if you've used them systematically.
:> Even if you haven't (I was the only one of a team of 5 using them in our recent
:> development cycle), they still tell you more than you would otherwise be told.
:
:I am aware of at least one project developing an embedded missile
:controller,
:that did exactly what you describe (in Ada). Here's what happened:
:
:1. Their timings changed, which introduced some subtle differences in
:the
:relationships between tasks and external interrupts. Some of these
:subtle
:differences invalidated their original testing.

This is why I have specifically said they *shouldn't* be used in threads where 
timing is critical. The fundamental problem is that assertions are executed 
*sequentially* and will necessarily affect timing. I haven't thought of any 
bright ideas on this one..

This is in contrast to GC which can be executed *in parallel* if implemented 
on a shared memory - multi-processor architecture. 


:2. Their object code changed (obviously), which required reanalysis of
:their
:object-code branch coverage.

If assertions are being implemented in a safe way and you can validate that 
the compiler is doing the right thing, why should this be necessary?


:3. At least one compiler bug was introduced, which was definitely
:unsettling.

If you really mean a bug (whether from optimisation or something else), this 
is not the fault of contracting but the compiler.


:What safety-critical system did you develop where you turned off
:assertions
:afer development? 

None. But if I did, I would regression test to make sure the compiler didn't
stuff things up.


:What standard (DO-178?) did you use for certification?

Which is?..


:The other prong of this is that, while assertions are keen for catching
:design problems, I haven't seen much evidence that they catch high-level
:requirements problems (not surprising, since the code was presumably
:written
:to match the requirements). 

If you're talking about A-specs (specs above the level of Software Requirements
Specs) containing statements like "The Sonar simulation shall simulate 
active detection", such requirements are better linked to a bunch of SRS 
requirements and checked through them.


:In 13 years of developing safety-critical
:embedded systems, our process tends to handle design problems fairly
:early.
:It's those high-level requirements problems where we need the most help.

Can you give an example? Not sure how high-level you mean.


:> Yes, timing *is* something to be concerned about when applied to realtime
:> systems. That's why I suggested not using assertions in the hard realtime
:> threads of a process. BTW, software designed using DBC may actually run *faster*
:> than code without it because you get to strip out all the defensive validity
:> checks. You have already ascertained during development that operations are
:> called in valid contexts so you don't have to check the context.
:
:But almost all of our safety-critical threads are hard realtime threads!
:That's a HUGE limitation for our systems!

Agree.


:What is the process to certify Eiffel compilers as being acceptably
:mature
:(code generation-wise) for safety-critical systems? Is all testing
:performed
:with assertions on and assertions off in all test cases?

I am not aware of any use of Eiffel yet for safety-critical systems. What I'm
trying to get across is its *potential* for these systems. That potential 
would be contingent on a number of things happening:

  - The addition of a concurrency mechanism.
  - The addition of realtime libraries.
  - The addition of low-level libraries.
  - The addition of a formal certification process for Eiffel compilers.
  - A realisation in RT community of the advantages of using Eiffel.


:> :Another consequence of using assertions is that you have to develop and
:> :test the
:> :assertions.
:> 
:> Correct. My initial reaction when I started using them was "Gee, I've got to
:> do this extra work on top of writing the "real" code! However, I found I was
:> spending about a third of the time integrating compared with my colleagues
:> which meant I was saving time overall and producing more reliable code to boot.
:> 
:> :As a result, you need confidence that the benefits of the
:> :assertions
:> :outweigh the dilution of your test effort.
:> 
:> IME, they do.
:
:However, it sounds like you're talking about a non-safety-critical
:system, and
:certainly not a hard real-time embedded safety-critical systems. In that
:case,
:I agree. For tools, simulations, etc. I would use all of the assertions
:I could.

Yes, I'm talking about simulators. Our's probably regarded as medium realtime.


:However, what about the topic of this thread (safety-critical systems)?
:It sounds
:like there's a lot of limitations as to using (and inheriting)
:assertions for
:this environment.

In the HRT threads, yes. Elsewhere (not in your case), it is an option.


:> :Of course, Bertand Meyer's Eiffel website insists that even
:> :misinterpretation of
:> :requirements (Ariane V) will be a problem no longer when Eiffel is used!
:> 
:> Come on. He's not saying that.
:
:Read his analysis of Ariane V. He says _exactly_ that, and has defended
:saying that in multiple newsgroups. A smart person, but not someone
:who knows my domain particularly well.

That's probably true.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> :> :> Maybe general assertions are more common than you imagine. However, I agree
> :> :> that range constraints are roughly covered by Ada subtypes. I use them liberally
> :> :> for just that purpose.
> :> :
> :> :Maybe, but again, I would like to see how these complex assertions are
> :> :used.
> :>
> :> You would use them anywhere that a piece of code makes assumptions. For example,
> :> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> :> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> :> you apply Ariane 5 dynamics to it.

An assertion violation... as in Operand_Error?

Again, someone needs to explain how these high-level assertions would
have
benefitted the Ariane 5 IRS.

> So, here's a different example. In my key handling object (one of the highest
> level in the simulation), there's an operation for interpreting the CLEAR key.
> Simplifying a little, pressing this key should reactivate the menu, clear the
> key sequence and clear any menu or sub-menu selection. So, there's a compound
> postcondition thus:
> 
>       if SA.ASSERTIONS_ON and then (INPUT_STATE /= MENU or else
>         NO_OF_KEYS /= 0 or else MENU_OPTION_SELECTED or else
>         SUBMENU_OPTION_SELECTED) then
>         raise SA.POSTCONDITION_ERROR;
> 
> Note that some of the components are functions. Wrapping them in this way
> is typical practice in Eiffel and enables you to use them elsewhere (eg. in
> if-statements in the code proper) and makes contracting scalable.

In Eiffel, I assume this code would be in the "short form." Is the
user/reviewer
really expected to read all of this (including looking up the functions
embedded
in this code) and understand it?

Wouldn't it be just as easy to say, in the description of this
operation, the
English text preceding it?

> 
> Clearly, the assumptions weren't properly thought out. Getting them right
> would have made the difference.

Keep in mind that the people making these assumptions were not
programmers -
they were system engineering types. So, unless you propose teaching DBC
to all engineers in the program (which might not be a bad idea,
actually),
then 

> :According to Meyer, et. al. Eiffel programmers would have written the
> :handler
> :differently, and also they would have known to do the testing
> :differently (even though
> :the requirements specification said that the tests need not change).
> 
> I don't know about you, but I tend to take a pretty skeptical view of
> requirements because they often have holes in them. It pays to be a bit
> circumspect.

Doesn't matter. You (a) would have been told that your suspicions are
not
a concern, since the Ariane 4 and 5 have the same flight profile, and
(b)
don't go throwing dumb assertions throughout your code - we're already
running around 80% of max throughput!

> With regard to whether an Eiffel software engineer would have
> picked up the false assumption compared with an Ada SE - possibly, due to the
> fact that they are conditioned by their use of contracting to *think* of as
> many assumptions as possible so they can code them as assertions. This sort of
> conditioning is much less prevalent among Ada developers because most don't
> use contracting (in this disciplined sense). I *know* this is true because I
> work with them. Of course, they may be (and probably are) more disciplined
> in your domain simply because they *have* to be. However, the conditioned
> cultural difference due to disciplined contracting would be an advantage.

Our engineers are taught the same thing in ADARTS, so I don;t think this
is
as big a difference as you think.

I also challenge whether or not you code all of the assertions you can
envision.
Look at your example from earlier. There's absolutely no other
assertions you
could consider? How about the possibility that calling one of the
functions
in the assertion causes NO_OF_KEYS to become non-zero, just for fun?

> For your domain it's a bit of a Catch-22. Contracting would improve the culture
> but you're unable to use it due to hard timing constraints.

Not at all. We have to distinguish between "contracting" and
"assertions." You
can still think in terms of writing strong interfaces, with well
documented
user constraints (ADARTS term), but without coding them. For example,
you may
write your test cases such that pre-conditions, post-conditions, and
invariants
are checked outside the object code. You can also permit more
comprehensive
reviews by documenting them via comments. The point is, you don't have
to use
DBC/Eiffel to get these benefits... they are also contained in
ADARTS/Ada, for
example.

> 
> 
> :However, their
> :explanation as to why this is true is far from convincing (basically,
> :that "Eiffel
> :programmers believe in quality" or some such nonsense).
> 
> No, it's the conditioning that makes the difference. There are a lot of
> Ada software engineers who *are* serious about quality (including you, I expect).
> Using DBC just makes you more effective.

However, the supposed advantage of Eiffel is that this thinking becomes
code.
I don't see the advantage for my domain (although I certainly do for
others).

> 
> :This is why I dislike people with no background in safety-critical
> :flight systems discussing
> :such issues. They believe that "software is software." and apply the
> :expertise in their
> :domain to mine.
> 
> Well, having worked in a range of application areas from HRT to 4GL/database,
> I can say this is both true and false. What I mean is there are some principles
> (eg. how to structure code etc.) that don't change irrespective of whether
> you're developing an embedded system or a GUI-based client application on a PC.
> There are also things that *do* change. In particular, the options available
> to you progressively decrease and the development environment becomes more
> hostile as you move further towards the HRT end of the scale (as you know).
> 
> :> :Again, the code I've seen to date doesn't seem to use them that much.
> :>
> :> If you're looking in Ada code, you're looking in the wrong place because few
> :> Ada developers recognise there are additional benefits from using them in
> :> addition to static typing and the predefined contracts already in Ada
> :> (the conditions under which predefined exceptions - eg. Constraint_Error -
> :> are raised).
> :
> :No - I'm looking at Eiffel code.
> 
> Well, you must be looking in the wrong place. I don't know whether anyone
> has given any pointers yet as to where you can find some. Suggestions?..
> 
> :> Static typing gives you static contract checking. Assertions (predefined and
> :> user-defined give you dynamic contract checking *during development*. What
> :> most Ada software engineers miss out on is the user-defined variety which
> :> bring a non-trivial benefit to reliability and reuse.
> :
> :Not this Ada engineer! I have dynamic assertions all over the place in
> :my
> :tools!
> 
> Terrific!
> 
> :My problem, again, is in the fundamental nature of dynamic assertions
> :for safety-critical
> :embedded systems, which have some unique risks, whether you (a) leave
> :them in after development,
> 
> Not recommended for your application area.
> 
> :or (b) take them out after developmental testing, but
> :before usage.
> 
> In this case, the software should be regression tested.

This requires that _all_ of the testing/analysis be done twice. Putting
aside
the cost and schedule concerns, any such program will have finite time
and other material. I can either do all of this work twice (which
dilutes
my effort 50%), or I can do it once - which might allow me to do testing
that otherwise I wouldn't do.

> 
> :> They are only turned on during development, so what you do is fix the underlying
> :> problem which is usually not difficult to find if you've used them systematically.
> :> Even if you haven't (I was the only one of a team of 5 using them in our recent
> :> development cycle), they still tell you more than you would otherwise be told.
> :
> :I am aware of at least one project developing an embedded missile
> :controller,
> :that did exactly what you describe (in Ada). Here's what happened:
> :
> :1. Their timings changed, which introduced some subtle differences in
> :the
> :relationships between tasks and external interrupts. Some of these
> :subtle
> :differences invalidated their original testing.
> 
> This is why I have specifically said they *shouldn't* be used in threads where
> timing is critical. The fundamental problem is that assertions are executed
> *sequentially* and will necessarily affect timing. I haven't thought of any
> bright ideas on this one..
> 
> This is in contrast to GC which can be executed *in parallel* if implemented
> on a shared memory - multi-processor architecture.
> 
> :2. Their object code changed (obviously), which required reanalysis of
> :their
> :object-code branch coverage.
> 
> If assertions are being implemented in a safe way and you can validate that
> the compiler is doing the right thing, why should this be necessary?

Because structural (path) testing at the object level has been shown to
be
extremely useful in detecting various types of errors - compiler errors
among them. Beizer cites several studies.

> 
> :3. At least one compiler bug was introduced, which was definitely
> :unsettling.
> 
> If you really mean a bug (whether from optimisation or something else), this
> is not the fault of contracting but the compiler.

True, but I have to live in the real world. The families of the people I
kill will not be impressed with the statement "That's a tool problem,
not
a methodology problem." The point is, changing the compiler switches
after
testing is complete is a Bad Thing.

> 
> :What safety-critical system did you develop where you turned off
> :assertions
> :afer development?
> 
> None. But if I did, I would regression test to make sure the compiler didn't
> stuff things up.

Do you run all of your tests, and perform all of your analyses, twice
(once with
SA.ASSERTIONS_ON set, and the other with it cleared)? Ever miss a
schedule date,
overrun a budget, or forego any potential testing as a result?

> 
> :What standard (DO-178?) did you use for certification?
> 
> Which is?..

DO-178 is the FAA standard for critical software. It, along with other
commonly-used certification criteria, would likely take a dim view of
what Eiffel advocates propose with respect to not testing the actual
code.

> 
> :The other prong of this is that, while assertions are keen for catching
> :design problems, I haven't seen much evidence that they catch high-level
> :requirements problems (not surprising, since the code was presumably
> :written
> :to match the requirements).
> 
> If you're talking about A-specs (specs above the level of Software Requirements
> Specs) containing statements like "The Sonar simulation shall simulate
> active detection", such requirements are better linked to a bunch of SRS
> requirements and checked through them.

No, code would usually be written to an SRS. Requirements traceability,
while
useful, only says that you implemented/tested what was written. It
doesn't say
that what was written is correct or complete.

> 
> :In 13 years of developing safety-critical
> :embedded systems, our process tends to handle design problems fairly
> :early.
> :It's those high-level requirements problems where we need the most help.
> 
> Can you give an example? Not sure how high-level you mean.

Recent examples:

  Ariane 5 - incorrect operational profile (Ariane 4 specified instead
of 5)
             See:
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
  F-18     - divide by zero at Mach 1, due to incorrect control law
equation in spec.
  YF-22, Gripen - PIO due to incorrect control law equation in spec.
(PIO is
             a complex lag interaction between the operator and the
system -
             can't wait to see the assertion for this one!)

> :> Yes, timing *is* something to be concerned about when applied to realtime
> :> systems. That's why I suggested not using assertions in the hard realtime
> :> threads of a process. BTW, software designed using DBC may actually run *faster*
> :> than code without it because you get to strip out all the defensive validity
> :> checks. You have already ascertained during development that operations are
> :> called in valid contexts so you don't have to check the context.
> :
> :But almost all of our safety-critical threads are hard realtime threads!
> :That's a HUGE limitation for our systems!
> 
> Agree.
> 
> :What is the process to certify Eiffel compilers as being acceptably
> :mature
> :(code generation-wise) for safety-critical systems? Is all testing
> :performed
> :with assertions on and assertions off in all test cases?
> 
> I am not aware of any use of Eiffel yet for safety-critical systems. What I'm
> trying to get across is its *potential* for these systems. That potential
> would be contingent on a number of things happening:
> 
>   - The addition of a concurrency mechanism.
>   - The addition of realtime libraries.
>   - The addition of low-level libraries.
>   - The addition of a formal certification process for Eiffel compilers.
>   - A realisation in RT community of the advantages of using Eiffel.

Much like saying a brick has the potential to fly... if you strap it to
an airplane :)

Aren't there more fundamental problems than just this? You state that
the assertions can't be executed in a hard real-time thread, so how does
a "realtime" library help?

> 
> :> :Another consequence of using assertions is that you have to develop and
> :> :test the
> :> :assertions.
> :>
> :> Correct. My initial reaction when I started using them was "Gee, I've got to
> :> do this extra work on top of writing the "real" code! However, I found I was
> :> spending about a third of the time integrating compared with my colleagues
> :> which meant I was saving time overall and producing more reliable code to boot.
> :>
> :> :As a result, you need confidence that the benefits of the
> :> :assertions
> :> :outweigh the dilution of your test effort.
> :>
> :> IME, they do.
> :
> :However, it sounds like you're talking about a non-safety-critical
> :system, and
> :certainly not a hard real-time embedded safety-critical systems. In that
> :case,
> :I agree. For tools, simulations, etc. I would use all of the assertions
> :I could.
> 
> Yes, I'm talking about simulators. Our's probably regarded as medium realtime.
> 
> :However, what about the topic of this thread (safety-critical systems)?
> :It sounds
> :like there's a lot of limitations as to using (and inheriting)
> :assertions for
> :this environment.
> 
> In the HRT threads, yes. Elsewhere (not in your case), it is an option.

But not all of my issues relate to HRT, so I still don't see that on
balance it's a good idea.

> :> :Of course, Bertand Meyer's Eiffel website insists that even
> :> :misinterpretation of
> :> :requirements (Ariane V) will be a problem no longer when Eiffel is used!
> :>
> :> Come on. He's not saying that.
> :
> :Read his analysis of Ariane V. He says _exactly_ that, and has defended
> :saying that in multiple newsgroups. A smart person, but not someone
> :who knows my domain particularly well.
> 
> That's probably true.
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Again, someone needs to explain how these high-level assertions would
:have
:benefitted the Ariane 5 IRS.

I have almost zero interest in the Ariane failure because (as Robert Dewar 
correctly pointed out some time ago) it reveals next to nothing about software
engineering except what is blindingly obvious.


:> So, here's a different example. In my key handling object (one of the highest
:> level in the simulation), there's an operation for interpreting the CLEAR key.
:> Simplifying a little, pressing this key should reactivate the menu, clear the
:> key sequence and clear any menu or sub-menu selection. So, there's a compound
:> postcondition thus:
:> 
:>       if SA.ASSERTIONS_ON and then (INPUT_STATE /= MENU or else
:>         NO_OF_KEYS /= 0 or else MENU_OPTION_SELECTED or else
:>         SUBMENU_OPTION_SELECTED) then
:>         raise SA.POSTCONDITION_ERROR;
:> 
:> Note that some of the components are functions. Wrapping them in this way
:> is typical practice in Eiffel and enables you to use them elsewhere (eg. in
:> if-statements in the code proper) and makes contracting scalable.
:
:In Eiffel, I assume this code would be in the "short form." Is the
:user/reviewer
:really expected to read all of this (including looking up the functions
:embedded
:in this code) and understand it?

First, part of the reason it looks complicated is that it is only emulating 
(in Ada83) the real thing. As I've already said, I wouldn't implement assertions
this way if I had the proper tools to work with. If you express it in Eiffel, 
it becomes simpler. 

Second, the compound condition represents a single higher level condition 
which can be declared as a function.

So, expressing it in Eiffel and wrapping the compound condition, we have

  ensure in_menu_state

with function in_menu_state defined as

  in_menu_state: BOOLEAN is
  do
    Result := ...               -- compound condition
  end.

This should be simple enough for any reviewer. The meaning of in_menu_state 
is self explanatory but if they want more detail, they can look at its
implementation.

:Wouldn't it be just as easy to say, in the description of this
:operation, the
:English text preceding it?

..and lose the benefit of being able to execute it?


:... So, unless you propose teaching DBC
:to all engineers in the program (which might not be a bad idea,
:actually),

I agree, it would.


:> With regard to whether an Eiffel software engineer would have
:> picked up the false assumption compared with an Ada SE - possibly, due to the
:> fact that they are conditioned by their use of contracting to *think* of as
:> many assumptions as possible so they can code them as assertions. This sort of
:> conditioning is much less prevalent among Ada developers because most don't
:> use contracting (in this disciplined sense). I *know* this is true because I
:> work with them. Of course, they may be (and probably are) more disciplined
:> in your domain simply because they *have* to be. However, the conditioned
:> cultural difference due to disciplined contracting would be an advantage.
:
:Our engineers are taught the same thing in ADARTS, so I don;t think this
:is
:as big a difference as you think.

I don't know what ADARTS is but it's one thing to be told you have to think
of all assumptions and another to demonstrate you have as evidenced by coded 
assertions.

:I also challenge whether or not you code all of the assertions you can
:envision.
:Look at your example from earlier. There's absolutely no other
:assertions you
:could consider? 

There may be others but so what? The existence of any I may not have thought 
of doesn't negate the effectiveness of those I *have* thought of.

:How about the possibility that calling one of the
:functions
:in the assertion causes NO_OF_KEYS to become non-zero, just for fun?

As I don't write functions with side effects, I'm not sure why I would want to
do that!..


:> For your domain it's a bit of a Catch-22. Contracting would improve the culture
:> but you're unable to use it due to hard timing constraints.
:
:Not at all. We have to distinguish between "contracting" and
:"assertions." You
:can still think in terms of writing strong interfaces, with well
:documented
:user constraints (ADARTS term), but without coding them. For example,
:you may
:write your test cases such that pre-conditions, post-conditions, and
:invariants
:are checked outside the object code. You can also permit more
:comprehensive
:reviews by documenting them via comments. The point is, you don't have
:to use
:DBC/Eiffel to get these benefits... they are also contained in
:ADARTS/Ada, for
:example.

Documented contracts are a good idea and may be appropriate for your domain.
Their weakness is that they can't be enforced, so for *other* domains, I would 
prefer executable assertions.


:> No, it's the conditioning that makes the difference. There are a lot of
:> Ada software engineers who *are* serious about quality (including you, I expect).
:> Using DBC just makes you more effective.
:
:However, the supposed advantage of Eiffel is that this thinking becomes
:code.
:I don't see the advantage for my domain (although I certainly do for
:others).

Agree.

[...]


:> Can you give an example? Not sure how high-level you mean.
:
:Recent examples:
:
:  Ariane 5 - incorrect operational profile (Ariane 4 specified instead
:of 5)
:             See:
:http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

There already was one, but it would be better to also have a higher level 
one for initialisation. This would aid testing in that if you fed in the 
wrong profile, you could verify that the IRS will not work. It wouldn't rely
on the more obscure low-level assertion that was actually violated.

In IRS:

  set_operational_profile (profile: OPERATIONAL_PROFILE) is
  require profile_compatible (profile)
  do .. end

BTW, this is intended to suggest what ought to done in engineering such 
software. This presupposes (among other things) that someone has actually sat 
down recognised the dependency of the IRS on the rocket dynamics. It is *not* a 
slap-on "remedy" to the non-existent software engineering that was practised 
in reality.

:  F-18     - divide by zero at Mach 1, due to incorrect control law
:equation in spec.

There already was a predefined assertion for this - "you may not divide 
zero" - which presumably resulted in a numeric_error. This assertion correctly
exposed an incorrect formula(?).

:  YF-22, Gripen - PIO due to incorrect control law equation in spec.
:  (PIO is a complex lag interaction between the operator and the system -

  class SOME_CLASS
    ...
  invariant not PIO (..)
  end

Likewise, this would expose the incorrect formula.


:Aren't there more fundamental problems than just this? You state that
:the assertions can't be executed in a hard real-time thread, so how does
:a "realtime" library help?

For those that aren't.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> First, part of the reason it looks complicated is that it is only emulating
> (in Ada83) the real thing. As I've already said, I wouldn't implement assertions
> this way if I had the proper tools to work with. If you express it in Eiffel,
> it becomes simpler.

OK - could you post the Ada equivalent?

> Second, the compound condition represents a single higher level condition
> which can be declared as a function.

But doesn't that just postpone the complexity? Making the assertion
nearest
the point the reviewer is reading less clear, and requiring a search
through
other files to discover the meaning of the higher-level condition?

For that matter, if this is the correct method, why not do it in Ada?

> ..and lose the benefit of being able to execute it?

According to Meyer, the principle benefit is the documentation value.
As to execution (either during test or operation), see sections 3.2 and
3.3 of

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

> :... So, unless you propose teaching DBC
> :to all engineers in the program (which might not be a bad idea,
> :actually),
> 
> I agree, it would.

But unlikely, unfortunately, given the history of such attempts.

> I don't know what ADARTS is but it's one thing to be told you have to think
> of all assumptions and another to demonstrate you have as evidenced by coded
> assertions.

Again, from a documentation standpoint, why is writing code better than
documenting the assertions in a form the reviewer understands?

> 
> :I also challenge whether or not you code all of the assertions you can
> :envision.
> :Look at your example from earlier. There's absolutely no other
> :assertions you
> :could consider?
> 
> There may be others but so what? The existence of any I may not have thought
> of doesn't negate the effectiveness of those I *have* thought of.

But how do you draw the line between the assumptions you state and the
assumptions you leave silent?

And what does that do to the oft-said statement that Eiffel programmers
put in assertions for unlikely events?

> :How about the possibility that calling one of the
> :functions
> :in the assertion causes NO_OF_KEYS to become non-zero, just for fun?
> 
> As I don't write functions with side effects, I'm not sure why I would want to
> do that!..

More correctly stated, you don't _intend_ to write assumptions with side
effects, so you _assume_ there's no need to write an assertion to
confirm
that you, in fact, met your intent.

How do you catch software design faults in your code if you assume you
made
no mistakes in your code?

> Documented contracts are a good idea and may be appropriate for your domain.
> Their weakness is that they can't be enforced, so for *other* domains, I would
> prefer executable assertions.

A perfectly reasonable approach, for those domains that (a) can live
with
executable assertions and (b) where the documentation effect is best
expressed in code.

> There already was one, but it would be better to also have a higher level
> one for initialisation. This would aid testing in that if you fed in the
> wrong profile, you could verify that the IRS will not work. It wouldn't rely
> on the more obscure low-level assertion that was actually violated.
> 
> In IRS:
> 
>   set_operational_profile (profile: OPERATIONAL_PROFILE) is
>   require profile_compatible (profile)
>   do .. end

This would require that the profile be stored in memory, wouldn't it?
The profile is a textual/graphical description of the behavior of the
environment.

You might be able to express it as "The horizontal acceleration shall
not exceed xxx..." ... and in fact, it probably would make more sense
to express it exactly that way (in English!) so that it is clear at
the requirements level.

> BTW, this is intended to suggest what ought to done in engineering such
> software. This presupposes (among other things) that someone has actually sat
> down recognised the dependency of the IRS on the rocket dynamics. It is *not* a
> slap-on "remedy" to the non-existent software engineering that was practised
> in reality.
> 
> :  F-18     - divide by zero at Mach 1, due to incorrect control law
> :equation in spec.
> 
> There already was a predefined assertion for this - "you may not divide
> zero" - which presumably resulted in a numeric_error. This assertion correctly
> exposed an incorrect formula(?).

But how would the user write an Eiffel assertion to cover this? I know
that
Ada has pre-defined assertions, but how does the Eiffel coder write an
assertion that says "this equation has no errors?"

> 
> :  YF-22, Gripen - PIO due to incorrect control law equation in spec.
> :  (PIO is a complex lag interaction between the operator and the system -
> 
>   class SOME_CLASS
>     ...
>   invariant not PIO (..)
>   end
> 
> Likewise, this would expose the incorrect formula.

Unfortunately, PIO is not a formula, nor can it be sensed by the system.

It is an interaction between the
operator and the system. The system sees the operator telling it to
ascend, then descend, then ascend a little faster, then descend faster
still... which might be valid commands. However, what is actually
happening is that the pilot's sensory system is a little behind the
dynamics of the airframe. He's trying to level the aircraft, but
he's actually making the problem much worse. There are criteria that
can be used to analyze a system for such potential behavior, but
overcompensating for PIO can make the system too stable (not responsive
enough).

Try writing a post-condition that says, "user's favorite color
displayed on screen" (without being able to ask the user first) and
you'll see what I mean.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> First, part of the reason it looks complicated is that it is only emulating
:> (in Ada83) the real thing. As I've already said, I wouldn't implement assertions
:> this way if I had the proper tools to work with. If you express it in Eiffel,
:> it becomes simpler.
:
:OK - could you post the Ada equivalent?

Sure. Assuming the availability of a postcondition clause,

  type Input_State_Type is (.., Menu, ..);

  Input_State : Input_State_Type;
  No_of_Keys : Natural
  Menu_Option_Selected : Boolean;
  Submenu_Option_Selected : Boolean;

  ...

  function in_menu_state return Boolean is
  begin
    return (Input_State = Menu and then No_of_Keys = 0 and then 
      not Menu_Option_Selected and then not Submenu_Option_Selected);
  end;

  procedure Interpret_CLR_Key is
  begin
    ...
  ensure in_menu_state                                   -- General assertion
  end;

Note that there is no precondition on Interpret_CLR_Key in accordance with the
fact that the Console Operator should be able to press any key at any time 
without having the software fall over. Using assertions to validate input 
would be a misuse of DBC.


:> Second, the compound condition represents a single higher level condition
:> which can be declared as a function.
:
:But doesn't that just postpone the complexity? Making the assertion
:nearest
:the point the reviewer is reading less clear, and requiring a search
:through
:other files to discover the meaning of the higher-level condition?

Yes, but this is no different from using encapsulation for abstraction anywhere 
else to simplify. You aren't going to replace every call in a procedure 
with the actual code of the called procedures (a compiler may, but a human 
shouldn't). Neither should you do this for assertions. You don't suddenly forget 
about abstraction just because you're writing an assertion.

A prerequisite for (any kind of) abstraction to be effective, of course, is
meaningful identifiers. If your identifier names accurately reflect what you're
trying to model, a high-level assertion immediately makes sense and you only 
look further if you really need to know the details. This would be the case, 
for example, if investigating the cause of an assertion violation or conducting 
a manual code review. Otherwise, the higher-level abstraction is not only 
sufficient but desirable (unless you want to be needlessly swamped by compexity).

Using meaningful identifiers sure makes a big difference to intelligibility and, 
IMO, is a skill that can be acquired by any reasonably literate developer 
who is suitably encouraged (read "forced" to use them). 
 

:For that matter, if this is the correct method, why not do it in Ada?

Purely historical reasons. If the code wasn't frozen at the moment, I probably
would.


:>: Wouldn't it be just as easy to say, in the description of this
:>: operation, the
:>: English text preceding it?
:>
:> ..and lose the benefit of being able to execute it?
:
:According to Meyer, the principle benefit is the documentation value.

I don't know whether he said this, but I'm not sure that I agree. I'll only 
find out through experience..

:As to execution (either during test or operation), see sections 3.2 and
:3.3 of
:
:   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

This is irrelevant to what we are dicussing here - use of DBC in non-HRT 
situations. It should be quite plain by now that I agree with you about the 
dangers of using assertions in HRT threads using current technology.


:> :... So, unless you propose teaching DBC
:> :to all engineers in the program (which might not be a bad idea,
:> :actually),
:> 
:> I agree, it would.
:
:But unlikely, unfortunately, given the history of such attempts.

Quite true.


:> I don't know what ADARTS is but it's one thing to be told you have to think
:> of all assumptions and another to demonstrate you have as evidenced by coded
:> assertions.
:
:Again, from a documentation standpoint, why is writing code better than
:documenting the assertions in a form the reviewer understands?

Consider the aversion of developers to documenting code. It's viewed by them 
as a necessary burden which doesn't actually make the software work so there's 
little motivation to do it. Executable assertions, OTOH, actually contribute 
something (runtime checks) to a running program. Therefore, they have some 
material value in the mind of a developer and their more likely to use them.
The by-product is that the code gets documented for free and the developers
actually *want* to do it.


:> :I also challenge whether or not you code all of the assertions you can
:> :envision.
:> :Look at your example from earlier. There's absolutely no other
:> :assertions you
:> :could consider?
:> 
:> There may be others but so what? The existence of any I may not have thought
:> of doesn't negate the effectiveness of those I *have* thought of.
:
:But how do you draw the line between the assumptions you state and the
:assumptions you leave silent?

Sorry, not sure what you're driving at. 

:And what does that do to the oft-said statement that Eiffel programmers
:put in assertions for unlikely events?

That's what all (or at least most) assertions are. They're catering for the 
unlikely event that the developer has made a logic error. Most of the time 
we write code with correct logic but occasionally we make mistakes. These 
mistakes can often be picked up by an assertion.


:> :How about the possibility that calling one of the
:> :functions
:> :in the assertion causes NO_OF_KEYS to become non-zero, just for fun?
:> 
:> As I don't write functions with side effects, I'm not sure why I would want to
:> do that!..
:
:More correctly stated, you don't _intend_ to write assumptions with side
:effects, so you _assume_ there's no need to write an assertion to
:confirm
:that you, in fact, met your intent.

You mean meta-assertions? Obviously, Your question in tongue-in-cheek but 
does highlight the fact that there is practical limit beyond which you don't 
want to go and meta-assertions are well beyond that limit. Most people want to 
go home at the end of the day.


:How do you catch software design faults in your code if you assume you
:made
:no mistakes in your code?

Don't follow. In writing assertions, you assume you *will* make design mistakes
in the code proper. If you're talking about design faults in assertions, I've
already answered you previously - the code proper acts as a built-in assertion
validation mechanism.


:> Documented contracts are a good idea and may be appropriate for your domain.
:> Their weakness is that they can't be enforced, so for *other* domains, I would
:> prefer executable assertions.
:
:A perfectly reasonable approach, for those domains that (a) can live
:with
:executable assertions and (b) where the documentation effect is best
:expressed in code.

Agree.


:> There already was one, but it would be better to also have a higher level
:> one for initialisation. This would aid testing in that if you fed in the
:> wrong profile, you could verify that the IRS will not work. It wouldn't rely
:> on the more obscure low-level assertion that was actually violated.
:> 
:> In IRS:
:> 
:>   set_operational_profile (profile: OPERATIONAL_PROFILE) is
:>   require profile_compatible (profile)
:>   do .. end
:
:This would require that the profile be stored in memory, wouldn't it?
:The profile is a textual/graphical description of the behavior of the
:environment.

No, it simply requires that the thing you want to make assertions about can 
be abstracted in some way. This implies both attributes (data) and operations
on those attributes. If you can abstract a profile using a class (which I'm
sure you could), then you can make assertions about it's compatibility.

:You might be able to express it as "The horizontal acceleration shall
:not exceed xxx..." ... and in fact, it probably would make more sense
:to express it exactly that way (in English!) so that it is clear at
:the requirements level.

You can do both.


The other examples actually aren't applicable to the efficacy of DBC as 
they stem from errors in specification documents..


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> First, part of the reason it looks complicated is that it is only emulating
> :> (in Ada83) the real thing. As I've already said, I wouldn't implement assertions
> :> this way if I had the proper tools to work with. If you express it in Eiffel,
> :> it becomes simpler.
> :
> :OK - could you post the Ada equivalent?
> 
> Sure. Assuming the availability of a postcondition clause,
> 
>   type Input_State_Type is (.., Menu, ..);
> 
>   Input_State : Input_State_Type;
>   No_of_Keys : Natural
>   Menu_Option_Selected : Boolean;
>   Submenu_Option_Selected : Boolean;
> 
>   ...
> 
>   function in_menu_state return Boolean is
>   begin
>     return (Input_State = Menu and then No_of_Keys = 0 and then
>       not Menu_Option_Selected and then not Submenu_Option_Selected);
>   end;
> 
>   procedure Interpret_CLR_Key is
>   begin
>     ...
>   ensure in_menu_state                                   -- General assertion
>   end;
> 
> Note that there is no precondition on Interpret_CLR_Key in accordance with the
> fact that the Console Operator should be able to press any key at any time
> without having the software fall over. Using assertions to validate input
> would be a misuse of DBC.

Compare this to the Ada code you presented earlier. Why is this
significantly
simpler or easier to read?

> 
> :> Second, the compound condition represents a single higher level condition
> :> which can be declared as a function.
> :
> :But doesn't that just postpone the complexity? Making the assertion
> :nearest
> :the point the reviewer is reading less clear, and requiring a search
> :through
> :other files to discover the meaning of the higher-level condition?
> 
> Yes, but this is no different from using encapsulation for abstraction anywhere
> else to simplify. You aren't going to replace every call in a procedure
> with the actual code of the called procedures (a compiler may, but a human
> shouldn't). Neither should you do this for assertions. You don't suddenly forget
> about abstraction just because you're writing an assertion.

True, but remember that we are asking a human reader to not just
understand what is required from a user's point of view (where
abstraction
permits unncessary details to be hidden), but to verify if the
software will function correctly or not. Doesn't this imply that the
evaluator will likely have to understand more than that required by a
user of
the interface?

> A prerequisite for (any kind of) abstraction to be effective, of course, is
> meaningful identifiers. If your identifier names accurately reflect what you're
> trying to model, a high-level assertion immediately makes sense and you only
> look further if you really need to know the details. This would be the case,
> for example, if investigating the cause of an assertion violation or conducting
> a manual code review. 

Exactly my point. Meyer claims that such manual reviews are the primary
benefit
of assertions. However, abstration does not necessarily assist such a
review; in
fact, it may complicate it.

> Otherwise, the higher-level abstraction is not only
> sufficient but desirable (unless you want to be needlessly swamped by compexity).
> 
> Using meaningful identifiers sure makes a big difference to intelligibility and,
> IMO, is a skill that can be acquired by any reasonably literate developer
> who is suitably encouraged (read "forced" to use them).

However, if the intent is to discover errors made by the developer, to
what
extent can the reviewer trust those "meaningful identifiers"?

> :For that matter, if this is the correct method, why not do it in Ada?
> 
> Purely historical reasons. If the code wasn't frozen at the moment, I probably
> would.

Then this doesn't seem to be an advantage of Eiffel over Ada, as your
earlier comment indicated.

> 
> :>: Wouldn't it be just as easy to say, in the description of this
> :>: operation, the
> :>: English text preceding it?
> :>
> :> ..and lose the benefit of being able to execute it?
> :
> :According to Meyer, the principle benefit is the documentation value.
> 
> I don't know whether he said this, but I'm not sure that I agree. I'll only
> find out through experience..

See section 3.1 of my analysis of his Ariane paper, at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

> :As to execution (either during test or operation), see sections 3.2 and
> :3.3 of
> :
> :   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/
> 
> This is irrelevant to what we are dicussing here - use of DBC in non-HRT
> situations. It should be quite plain by now that I agree with you about the
> dangers of using assertions in HRT threads using current technology.
> 
> :> :... So, unless you propose teaching DBC
> :> :to all engineers in the program (which might not be a bad idea,
> :> :actually),
> :>
> :> I agree, it would.
> :
> :But unlikely, unfortunately, given the history of such attempts.
> 
> Quite true.
> 
> :> I don't know what ADARTS is but it's one thing to be told you have to think
> :> of all assumptions and another to demonstrate you have as evidenced by coded
> :> assertions.
> :
> :Again, from a documentation standpoint, why is writing code better than
> :documenting the assertions in a form the reviewer understands?
> 
> Consider the aversion of developers to documenting code. It's viewed by them
> as a necessary burden which doesn't actually make the software work so there's
> little motivation to do it. Executable assertions, OTOH, actually contribute
> something (runtime checks) to a running program. Therefore, they have some
> material value in the mind of a developer and their more likely to use them.

I'm not sure I agree that well-trained and professional developers feel
this
way, but let's say they do. Wouldn't this imply that they will be biased
toward adding code that helps them get their code correct for the
current
use of their code (i.e. that part that provides direct value to them)
and
much less attention to addressing issues that don't provide value to
them
(e.g., handling errors due to improper reuse by "some other guy")?

> The by-product is that the code gets documented for free and the developers
> actually *want* to do it.

It also seems that the documentation value of the assertions will be
lessened
(less likely to use meaningful identifiers vs. ones that "work good
enough").
The line between codes that don't like to write documentation vs. coders
that
don't like to write self-documenting code for others to read appears to
me
to be easy to cross...

> 
> :> :I also challenge whether or not you code all of the assertions you can
> :> :envision.
> :> :Look at your example from earlier. There's absolutely no other
> :> :assertions you
> :> :could consider?
> :>
> :> There may be others but so what? The existence of any I may not have thought
> :> of doesn't negate the effectiveness of those I *have* thought of.
> :
> :But how do you draw the line between the assumptions you state and the
> :assumptions you leave silent?
> 
> Sorry, not sure what you're driving at.

Every error condition that might occur (e.g., adding extra code that
makes an extraneous assignment), but is not checked by an assertion,
would appear to be an undocumented assumption. Every undocumented
assumption,
per Meyer, represents an incomplete description of the interface.

How do you decide which assumptions not to document?

> :And what does that do to the oft-said statement that Eiffel programmers
> :put in assertions for unlikely events?
> 
> That's what all (or at least most) assertions are. They're catering for the
> unlikely event that the developer has made a logic error. Most of the time
> we write code with correct logic but occasionally we make mistakes. These
> mistakes can often be picked up by an assertion.

So, how are the likely events detected?

And, if the same person who made the logic error writes the assertions,
why
is it reasonable to expect that the assertion detects the error? Won't
the person simply make the same mistake in logic, particularly for such
things as missed requirements?

> :> :How about the possibility that calling one of the
> :> :functions
> :> :in the assertion causes NO_OF_KEYS to become non-zero, just for fun?
> :>
> :> As I don't write functions with side effects, I'm not sure why I would want to
> :> do that!..
> :
> :More correctly stated, you don't _intend_ to write assumptions with side
> :effects, so you _assume_ there's no need to write an assertion to
> :confirm
> :that you, in fact, met your intent.
> 
> You mean meta-assertions? Obviously, Your question in tongue-in-cheek but
> does highlight the fact that there is practical limit beyond which you don't
> want to go and meta-assertions are well beyond that limit. Most people want to
> go home at the end of the day.

I don't know why this is a "meta-assertion." Extraneous code is a
category of
error, just like missing code.

Given that "most people want to go home at the end of the day," my point
stands.
Which assumptions do you document? Which do you remain undocumented? And
what
theory drives the decision? Does DBC say, "this type of coding error is
more
likely than the other, so protect against it first?"

> :How do you catch software design faults in your code if you assume you
> :made
> :no mistakes in your code?
> 
> Don't follow. In writing assertions, you assume you *will* make design mistakes
> in the code proper.

Except that you deliberately exclude classes of faults, apparently,
without
any statement in the code that you did so.

> If you're talking about design faults in assertions, I've
> already answered you previously - the code proper acts as a built-in assertion
> validation mechanism.

Think again, particularly with respect to missing code.

> 
> :> Documented contracts are a good idea and may be appropriate for your domain.
> :> Their weakness is that they can't be enforced, so for *other* domains, I would
> :> prefer executable assertions.
> :
> :A perfectly reasonable approach, for those domains that (a) can live
> :with
> :executable assertions and (b) where the documentation effect is best
> :expressed in code.
> 
> Agree.
> 
> :> There already was one, but it would be better to also have a higher level
> :> one for initialisation. This would aid testing in that if you fed in the
> :> wrong profile, you could verify that the IRS will not work. It wouldn't rely
> :> on the more obscure low-level assertion that was actually violated.
> :>
> :> In IRS:
> :>
> :>   set_operational_profile (profile: OPERATIONAL_PROFILE) is
> :>   require profile_compatible (profile)
> :>   do .. end
> :
> :This would require that the profile be stored in memory, wouldn't it?
> :The profile is a textual/graphical description of the behavior of the
> :environment.
> 
> No, it simply requires that the thing you want to make assertions about can
> be abstracted in some way. This implies both attributes (data) and operations
> on those attributes. If you can abstract a profile using a class (which I'm
> sure you could), then you can make assertions about it's compatibility.

Don't assertions involving the enviroment require data about the
environment?

> 
> :You might be able to express it as "The horizontal acceleration shall
> :not exceed xxx..." ... and in fact, it probably would make more sense
> :to express it exactly that way (in English!) so that it is clear at
> :the requirements level.
> 
> You can do both.

I'm not sure I agree with the claim that all comments can be written as
code!

> 
> The other examples actually aren't applicable to the efficacy of DBC as
> they stem from errors in specification documents..

WUPS!

DBC doesn't protect against errors in specification documents? An
interesting
statement!

Given this, then it shouldn't be able to protect against
misinterpretations
of specification documents by a developer, either, true? Or, for that
matter,
misinterpretations of any higher-tier document (e.g. a design document)?
Doesn't
a requirement not read equate to a requirement not written?

Finally, of all of the errors in code, assuming the use of existing
techniques
(code reviews, unit test, etc.) how many are "code-only" errors vs.
misinterpretations
of higher-tier documents?

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :Don Harrison wrote:
:> :>
:> :> First, part of the reason it looks complicated is that it is only emulating
:> :> (in Ada83) the real thing. As I've already said, I wouldn't implement assertions
:> :> this way if I had the proper tools to work with. If you express it in Eiffel,
:> :> it becomes simpler.
:> :
:> :OK - could you post the Ada equivalent?
:> 
:> Sure. Assuming the availability of a postcondition clause,
:> 
:>   type Input_State_Type is (.., Menu, ..);
:> 
:>   Input_State : Input_State_Type;
:>   No_of_Keys : Natural
:>   Menu_Option_Selected : Boolean;
:>   Submenu_Option_Selected : Boolean;
:> 
:>   ...
:> 
:>   function in_menu_state return Boolean is
:>   begin
:>     return (Input_State = Menu and then No_of_Keys = 0 and then
:>       not Menu_Option_Selected and then not Submenu_Option_Selected);
:>   end;
:> 
:>   procedure Interpret_CLR_Key is
:>   begin
:>     ...
:>   ensure in_menu_state                                   -- General assertion
:>   end;
:> 
:> Note that there is no precondition on Interpret_CLR_Key in accordance with the
:> fact that the Console Operator should be able to press any key at any time
:> without having the software fall over. Using assertions to validate input
:> would be a misuse of DBC.
:
:Compare this to the Ada code you presented earlier. Why is this
:significantly
:simpler or easier to read?

Due to abstraction.


:> :> Second, the compound condition represents a single higher level condition
:> :> which can be declared as a function.
:> :
:> :But doesn't that just postpone the complexity? Making the assertion
:> :nearest
:> :the point the reviewer is reading less clear, and requiring a search
:> :through
:> :other files to discover the meaning of the higher-level condition?
:> 
:> Yes, but this is no different from using encapsulation for abstraction anywhere
:> else to simplify. You aren't going to replace every call in a procedure
:> with the actual code of the called procedures (a compiler may, but a human
:> shouldn't). Neither should you do this for assertions. You don't suddenly forget
:> about abstraction just because you're writing an assertion.
:
:True, but remember that we are asking a human reader to not just
:understand what is required from a user's point of view (where
:abstraction
:permits unncessary details to be hidden), but to verify if the
:software will function correctly or not. Doesn't this imply that the
:evaluator will likely have to understand more than that required by a
:user of
:the interface?

It means they have to have to find out more but the effort involved isn't
excessive, IMO. 


:> A prerequisite for (any kind of) abstraction to be effective, of course, is
:> meaningful identifiers. If your identifier names accurately reflect what you're
:> trying to model, a high-level assertion immediately makes sense and you only
:> look further if you really need to know the details. This would be the case,
:> for example, if investigating the cause of an assertion violation or conducting
:> a manual code review. 
:
:Exactly my point. Meyer claims that such manual reviews are the primary
:benefit
:of assertions. However, abstration does not necessarily assist such a
:review; in
:fact, it may complicate it.

Well, it does add a little more work but I've never heard anyone complain 
about it.


:> Otherwise, the higher-level abstraction is not only
:> sufficient but desirable (unless you want to be needlessly swamped by compexity).
:> 
:> Using meaningful identifiers sure makes a big difference to intelligibility and,
:> IMO, is a skill that can be acquired by any reasonably literate developer
:> who is suitably encouraged (read "forced" to use them).
:
:However, if the intent is to discover errors made by the developer, to
:what
:extent can the reviewer trust those "meaningful identifiers"?

If you know that Joe Bloggs, the author, is fond of using non-indicative
identifiers, you know to check the details. Of course, *real* software 
engineers aren't like that, are they?.. Realistically, any software shop 
that *does* use Eiffel is likely to encourage/enforce sensible naming so I 
don't see it as an Earth-shattering issue. 


:> :For that matter, if this is the correct method, why not do it in Ada?
:> 
:> Purely historical reasons. If the code wasn't frozen at the moment, I probably
:> would.
:
:Then this doesn't seem to be an advantage of Eiffel over Ada, as your
:earlier comment indicated.

Perhaps we've miscommunicated here. The principle of abstracting assertions 
using functions is language-neutral - unlike a number of other assertion-related
issues.


:> :> I don't know what ADARTS is but it's one thing to be told you have to think
:> :> of all assumptions and another to demonstrate you have as evidenced by coded
:> :> assertions.
:> :
:> :Again, from a documentation standpoint, why is writing code better than
:> :documenting the assertions in a form the reviewer understands?
:> 
:> Consider the aversion of developers to documenting code. It's viewed by them
:> as a necessary burden which doesn't actually make the software work so there's
:> little motivation to do it. Executable assertions, OTOH, actually contribute
:> something (runtime checks) to a running program. Therefore, they have some
:> material value in the mind of a developer and their more likely to use them.
:
:I'm not sure I agree that well-trained and professional developers feel
:this
:way, but let's say they do. 

IME, the desire to minimise the amount of work we have to do is shared by 
everyone however well-trained and professional they happen to be. However,..


:Wouldn't this imply that they will be biased
:toward adding code that helps them get their code correct for the
:current
:use of their code (i.e. that part that provides direct value to them)
:and
:much less attention to addressing issues that don't provide value to
:them
:(e.g., handling errors due to improper reuse by "some other guy")?

Not if they take a longer-term, reuse-centred view. That sort of attitude 
would be encouraged in Eiffel shops. Those who weren't interested in practising
it would be more likely working somewhere else.


:> The by-product is that the code gets documented for free and the developers
:> actually *want* to do it.
:
:It also seems that the documentation value of the assertions will be
:lessened
:(less likely to use meaningful identifiers vs. ones that "work good
:enough").
:The line between codes that don't like to write documentation vs. coders
:that
:don't like to write self-documenting code for others to read appears to
:me
:to be easy to cross...

Yes, it is easy to cross, especially after a few nightmare experiences as 
a maintenance programmer. :)


:> :> :I also challenge whether or not you code all of the assertions you can
:> :> :envision.
:> :> :Look at your example from earlier. There's absolutely no other
:> :> :assertions you
:> :> :could consider?
:> :>
:> :> There may be others but so what? The existence of any I may not have thought
:> :> of doesn't negate the effectiveness of those I *have* thought of.
:> :
:> :But how do you draw the line between the assumptions you state and the
:> :assumptions you leave silent?
:> 
:> Sorry, not sure what you're driving at.
:
:Every error condition that might occur (e.g., adding extra code that
:makes an extraneous assignment), but is not checked by an assertion,
:would appear to be an undocumented assumption. Every undocumented
:assumption,
:per Meyer, represents an incomplete description of the interface.

True.

:How do you decide which assumptions not to document?

I can only speak for myself, but I document as many as I can think of without 
going overboard (bearing in mind I'm developing realtime software). Because 
of my domain, I'm probably more selective than a non-realtime programmer 
would be.


:> :And what does that do to the oft-said statement that Eiffel programmers
:> :put in assertions for unlikely events?
:> 
:> That's what all (or at least most) assertions are. They're catering for the
:> unlikely event that the developer has made a logic error. Most of the time
:> we write code with correct logic but occasionally we make mistakes. These
:> mistakes can often be picked up by an assertion.
:
:So, how are the likely events detected?

By this definition, the likely events correspond to correct logic so we're 
not interested in them.


:And, if the same person who made the logic error writes the assertions,
:why
:is it reasonable to expect that the assertion detects the error? Won't
:the person simply make the same mistake in logic, particularly for such
:things as missed requirements?

Perhaps sometimes, but often not. Usually, the error in logic is in a different
piece of code to the assertion. (consider my ATC example). Even if the same 
person writes both the assertion and the code that uses it, there may be an 
intervening time period, giving the developer a chance to forget their 
original reasoning. Worse still, in a team-oriented setup, it usually *isn't* 
the same person and their understanding of how the system hangs together may
differ. In my own experience, a large number of such differences can be 
exposed by assertions.  


:> :> :How about the possibility that calling one of the
:> :> :functions
:> :> :in the assertion causes NO_OF_KEYS to become non-zero, just for fun?
:> :>
:> :> As I don't write functions with side effects, I'm not sure why I would want to
:> :> do that!..
:> :
:> :More correctly stated, you don't _intend_ to write assumptions with side
:> :effects, so you _assume_ there's no need to write an assertion to
:> :confirm
:> :that you, in fact, met your intent.
:> 
:> You mean meta-assertions? Obviously, Your question in tongue-in-cheek but
:> does highlight the fact that there is practical limit beyond which you don't
:> want to go and meta-assertions are well beyond that limit. Most people want to
:> go home at the end of the day.
:
:I don't know why this is a "meta-assertion." Extraneous code is a
:category of error, just like missing code.

You were talking about assertions with side-effects and seemed to be suggesting 
a need for assertions about assertions - which would be meta-assertions. These 
would be overkill, IMO.

Getting back to your question, it can be verified statically (using a tool, 
for example) that an assertion (transitively) performs no assignments.
So, a language environment with such a tool can verify for you that all your 
assertions are free of side-effects. 


:Given that "most people want to go home at the end of the day," my point
:stands.

Best have a tool do it for you, then, instead of doing it manually.


:Which assumptions do you document? 

Those you think of.

:Which do you remain undocumented? 

Those you don't (or choose to ignore for whatever reason).

:And what theory drives the decision? Does DBC say, "this type of coding error is
:more likely than the other, so protect against it first?"

In theory, you try to document as many as you can think of without 
discrimination. However, I guess you can be more selective in practice. 
Personally, I try to anticipate the most likely causes of error and document 
those possibilities in assertions. Maybe others would like to offer their 
perpective..


:> :How do you catch software design faults in your code if you assume you
:> :made
:> :no mistakes in your code?
:> 
:> Don't follow. In writing assertions, you assume you *will* make design mistakes
:> in the code proper.
:
:Except that you deliberately exclude classes of faults, apparently,
:without any statement in the code that you did so.

Not intentionally, unless it's expedient for some reason - eg. for timing.


:> If you're talking about design faults in assertions, I've
:> already answered you previously - the code proper acts as a built-in assertion
:> validation mechanism.
:
:Think again, particularly with respect to missing code.

Maybe we're misconnecting here. I'm saying if you *do* code an assertion and 
you happen to miscode it or your initial assuption was incorrect, you will 
find out because you'll get an assertion violation under legitimate, rather `
than erroneous circumstances. You then *know* the assertion is incorrect, you 
find why, and fix it. In this way, the code proper acts as an assertion 
validation mechanism.

Obviously, if you *don't* code an assertion (for whatever reason - didn't 
recognise the assumption, decided to leave it out), the code proper isn't 
going to validate it.

Not sure whether I've covered your original question, though..


:> :> There already was one, but it would be better to also have a higher level
:> :> one for initialisation. This would aid testing in that if you fed in the
:> :> wrong profile, you could verify that the IRS will not work. It wouldn't rely
:> :> on the more obscure low-level assertion that was actually violated.
:> :>
:> :> In IRS:
:> :>
:> :>   set_operational_profile (profile: OPERATIONAL_PROFILE) is
:> :>   require profile_compatible (profile)
:> :>   do .. end
:> :
:> :This would require that the profile be stored in memory, wouldn't it?
:> :The profile is a textual/graphical description of the behavior of the
:> :environment.
:> 
:> No, it simply requires that the thing you want to make assertions about can
:> be abstracted in some way. This implies both attributes (data) and operations
:> on those attributes. If you can abstract a profile using a class (which I'm
:> sure you could), then you can make assertions about it's compatibility.
:
:Don't assertions involving the enviroment require data about the
:environment?

Ultimately, in some way. In terms of textual/graphical descriptions, if you can 
capture that information in a bunch of abstractions and capture a set of 
validity rules about it, you should then be able code an assertion which 
expresses its validity. This sort of assertion is quite high-level and 
potentially complex so would be a good candidate for an abstract assertion. 


:> :You might be able to express it as "The horizontal acceleration shall
:> :not exceed xxx..." ... and in fact, it probably would make more sense
:> :to express it exactly that way (in English!) so that it is clear at
:> :the requirements level.
:> 
:> You can do both.
:
:I'm not sure I agree with the claim that all comments can be written as
:code!

Nor would I but this one sounds like it could be. :)


:> The other examples actually aren't applicable to the efficacy of DBC as
:> they stem from errors in specification documents..
:
:WUPS!

Uh-oh. :)  Why do I get the feeling this leading somewhere?..

:DBC doesn't protect against errors in specification documents? An interesting
:statement!

Not unless there was a related specification which serves indirectly to 
validate the erroneous one. This would effectively the same as if the developer
made an error somewhere and an assertion picked it up. So, leaving it out 
doesn't necessarily mean all bets are off on picking it up.

Otherwise, it's true. Alas, assertions won't do *everything* for you. :(

:Given this, then it shouldn't be able to protect against misinterpretations
:of specification documents by a developer, either, true? 

Again, not unless there was a related specification which serves indirectly to 
validate the one misinterpreted - otherwise true.

:Or, for that matter,
:misinterpretations of any higher-tier document (e.g. a design document)?

Same deal.

:Doesn't a requirement not read equate to a requirement not written?

In practical terms, yes. (For some reason, this has a familiar ring to it :)

Watch out, here comes the punchline..

:Finally, of all of the errors in code, assuming the use of existing techniques
:(code reviews, unit test, etc.) how many are "code-only" errors vs.
:misinterpretations of higher-tier documents?

Probably greater than 50%  Why, I wonder, do you ask?..  :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[W. Wesley Groleau x4923]

> Consider the aversion of developers to documenting code. It's viewed by them
> as a necessary burden which doesn't actually make the software work so there's
> little motivation to do it. ....

I hope this is not generally true, and I don't think it is.  I think
that 
there are far too many that think that way, but OTOH even more just let 
the documentation slide due to real or perceived schedule pressure.  
Either way it's a Bad Thing.

> little motivation to do it. Executable assertions, OTOH, actually contribute
> something (runtime checks) to a running program. Therefore, they have some
> material value in the mind of a developer and their more likely to use them.
> The by-product is that the code gets documented for free and the developers
> actually *want* to do it.

And either way, this part is a Good Thing--if it doesn't also slide 
for the same reasons.

> :And what does that do to the oft-said statement that Eiffel programmers
> :put in assertions for unlikely events?
> 
> That's what all (or at least most) assertions are. They're catering for the
> unlikely event that the developer has made a logic error. Most of the time
> we write code with correct logic but occasionally we make mistakes. These
> mistakes can often be picked up by an assertion.

This is a good idea for most software.  But I would think that if you 
know enough to write the assertion, you know enough to track down and 
eliminate whatever would make the assertion fail.  In safety-critical 
software, how can you justify not doing so? 

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Wesley Groleau wrote:

:> Consider the aversion of developers to documenting code. It's viewed by them
:> as a necessary burden which doesn't actually make the software work so there's
:> little motivation to do it. ....
:
:I hope this is not generally true, and I don't think it is.  I think
:that 
:there are far too many that think that way, but OTOH even more just let 
:the documentation slide due to real or perceived schedule pressure.  
:Either way it's a Bad Thing.

Agree.


:> little motivation to do it. Executable assertions, OTOH, actually contribute
:> something (runtime checks) to a running program. Therefore, they have some
:> material value in the mind of a developer and their more likely to use them.
:> The by-product is that the code gets documented for free and the developers
:> actually *want* to do it.
:
:And either way, this part is a Good Thing--if it doesn't also slide 
:for the same reasons.

Agree.


:> :And what does that do to the oft-said statement that Eiffel programmers
:> :put in assertions for unlikely events?
:> 
:> That's what all (or at least most) assertions are. They're catering for the
:> unlikely event that the developer has made a logic error. Most of the time
:> we write code with correct logic but occasionally we make mistakes. These
:> mistakes can often be picked up by an assertion.
:
:This is a good idea for most software.  But I would think that if you 
:know enough to write the assertion, you know enough to track down and 
:eliminate whatever would make the assertion fail.  

This is true only in a few isolated cases. However, what we come up against 
more often is an exponential complexity caused by the number of possible 
execution paths to the routine we are dealing with at any one time. While we
can comfortably grapple with the logic of the actual routine at hand and 
a handful of the more isolated execution paths, we usually haven't a hope 
of dealing with all possible execution paths. There are very few people who 
can handle complexity of these dimensions and they probably prefer to use it 
playing chess with Deep Blue or counting cards in casinos than in developing 
software.

So, disappointed, we admit we're not up to the task of dealing with all the 
possibilities in the system as a whole. What we remember, though, is that 
we're more than capable of dealing with just our routine - that's no problem.
Well, if we can't cope with the system as a whole, how about doing it 
incrementally. If we can prove, step-by-step that each part of the system is
doing the right thing, then we've got the problem beaten - a divide-and-conquer
strategy. Let's think about how we might be able to do that..

To do that, we'll suppose we're developing an Air Traffic Control system 
and we have a concept of aircraft which may be transfered from one controller 
to another. The specific part of the overall ATC system we want to consider
is an operation Assume_Control which takes an Aircraft as a parameter.

So, we have

  procedure Assume_Control (Aircraft: Aircraft_Type) is
  begin
    ...
    My_Aircraft.Add (Aircraft);   -- Add to my set of aircraft
  end;

Well, that's simple enough. Not much can go wrong here ..or can it? We see 
a couple of potential problems:

  1) What if I already control the aircraft and, by mistake, the software that
     tranfers control doesn't realise it? It's likely that our software will 
     corrupt some data, for example leaving us with a duplicate aircraft under
     our control!

  2) We delegate work to other objects to get the job done. What if one of 
     them makes a mistake? Then, by implication, there's also a mistake in *our*
     operation!

We need some way to stop these things happening. 

For 1), we could add a comment to the operation header

       -- Assumes aircraft not already controlled

so the transfer software knows to check this first. That's good but still leaves 
us a little uneasy. Even though the requirement is documented, it's still 
possible to miss or ignore it. We could protect ourselves by checking *ourselves*
that the aircraft is not already controlled by us..

  begin
    if not My_Aircraft.Mine (Aircraft) then
      ...
      My_Aircraft.Add (Aircraft);
    end if;
  end;

That would mean *we're* okay, but what about the caller? There is a serious 
problem here in that the caller's code contains an error. They are calling 
an operation they don't need to. This is misleading and may lead to further 
errors in the caller based on the assumed contextual validity of the call.
Also, the erroneous call will cause problems if, for some reason, the 
implementation of our operation changes so it is no longer benign under these 
conditions. 

What we want is a way to signal to the caller that they've made a mistake and 
need to take corrective action. A very effective way of doing that is by 
raising an exception. This sends a very clear message which cannot be ignored.

So, we add a mechanism to the language whereby we can make the checks *and* 
raise an exception if not satisfied..

  procedure Assume_Control (Aircraft: Aircraft_Type) is
  require not My_Aircraft.Mine (Aircraft)
  begin
    ...
    My_Aircraft.Add (Aircraft);
  end;

Now our operation can only be executed under the right circumstances.

What about case 2)? Here, we want to check that the work we delegated was 
done properly and acheived what we set out to do. In this case, we can 
perform some checks and raise and exception against ourselves to force us 
to fix the problem (possibly by delegating)..

  procedure Assume_Control (Aircraft: Aircraft_Type) is
  require not My_Aircraft.Mine (Aircraft)
  begin
    ...
    My_Aircraft.Add (Aircraft);
  ensure My_Aircraft.Mine (Aircraft)
  end;

which is our final solution. What we are now left with is a component of 
software that we know can only be executed under the intended conditions and 
can guarantee producing the required results. We now move on to the next 
component and repeat the process. Step-by-step, piece-by-piece we construct 
our reliable ATC system. We did so *incrementally* through a divide-and-conquer 
strategy and by being demanding in what we expected of callers and demanding 
of ourselves in producing the correct results.

Sorry if this is a bit Mickey Mouse for some, but some may find this helpful.


[the "doing so" following means checking the validity of all calls]

:In safety-critical 
:software, how can you justify not doing so? 

If timing is so desperate that you can't use assertions, you may *have* to 
do perform this sort of analysis manually.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> What we want is a way to signal to the caller that they've made a mistake and
> need to take corrective action. 

If they don't know to check that they might have made a mistake, how do
they
know what corrective action they should take?

If the erroneous code is reused in another application, doesn't it carry
its
error along with it?

What if the mistake is in your code, not the calling code?

> What about case 2)? Here, we want to check that the work we delegated was
> done properly and acheived what we set out to do. In this case, we can
> perform some checks and raise and exception against ourselves to force us
> to fix the problem (possibly by delegating)..
> 
>   procedure Assume_Control (Aircraft: Aircraft_Type) is
>   require not My_Aircraft.Mine (Aircraft)
>   begin
>     ...
>     My_Aircraft.Add (Aircraft);
>   ensure My_Aircraft.Mine (Aircraft)
>   end;
> 
> which is our final solution. What we are now left with is a component of
> software that we know can only be executed under the intended conditions and
> can guarantee producing the required results.

Assuming...

1. My_Aircraft.Mine is correct. (How is this determined? Do assertions
have
   assertions? What happens if an assertion's assertion fails, and how
is
   it distinguished from an assertion failure?)

2. Assume_Control is not called again with the same aircraft between the
   pre-condition and My_Aircraft.Add.

3. Release_Control (I propose this as the opposite of Assume_Control) is
   not called between My_Aircraft.Add and the post-condition.

4. There are no errors from other sources (e.g. extraneous code,
higher-tier
   documentation miscommunications).

Correct?

Also: If the post-condition fails, who provides the corrective action?

Also: If My_Aircraft.Add is provided by a different programmer/team than
Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)? Why
or
why not?

Also: it's my understanding that DBC requires My_Aircraft.Mine be made
available
to the client of Assume_Control (no private pre-conditions). Is this the
case
here? Why or why not? Does this mean that the pre-condition may be
checked twice
before each call?

> We now move on to the next
> component and repeat the process. Step-by-step, piece-by-piece we construct
> our reliable ATC system. We did so *incrementally* through a divide-and-conquer
> strategy and by being demanding in what we expected of callers and demanding
> of ourselves in producing the correct results.

However, these results seem to be limited to making sure the code does
what
you thought it was supposed to do. How are the other failure sources
handled?

> Sorry if this is a bit Mickey Mouse for some, but some may find this helpful.
> 
> [the "doing so" following means checking the validity of all calls]
> 
> :In safety-critical
> :software, how can you justify not doing so?
> 
> If timing is so desperate that you can't use assertions, you may *have* to
> do perform this sort of analysis manually.

I think timing is part of the issue, but there are certainly other
issues.
See sections 3.1.6, 3.2.2, and 3.3 of my draft paper at:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/

Also, given that Meyer claims the "most important" effect of assertions
is manual analysis (see section 3.1 of same paper), shouldn't you be
doing this
anyway (in addition to any executable testing)? If you're not reviewing
these manually, why not?

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> What if the mistake is in your code, not the calling code?

There's always an end to the chain in buck-passing. If the mistake is in
our code, we obviously have to fix it. DBC is not a silver bullet, it is
just a way of unambiguously distributing responsibilities (preconditions
to the caller, postconditions to the callee - and the callee is *not*
required to check its preconditions in its code).
Or, if the system must be fail-safe, the buck is passed up to some
routine that just takes note of the software failure and tries something
else (or detonates the rocked).

> 1. My_Aircraft.Mine is correct. (How is this determined?

Proofreading.
However, assertions are (hopefully) on a higher level than the program
code, so the task of the proofreader becomes easier by that level.

>    Do assertions
>    have
>    assertions?

In Eiffel, no. Assertions are on a higher level of reasoning than the
program code itself. The advice is to write simple assertions (again to
make proofreading easier).
Personally, I'm not totally sure wether this will properly scale up to
arbitrarily large systems. Adding assertions to assertions, however,
adds a second layer of checking (which would have to be read and
understood by the proofreader), so assertions on assertions aren't too
useful anyway.

> 2. Assume_Control is not called again with the same aircraft between
>    the
>    pre-condition and My_Aircraft.Add.
> 3. Release_Control (I propose this as the opposite of Assume_Control)
>    is
>    not called between My_Aircraft.Add and the post-condition.

This is taken care of.
For single-threaded applications, the problem cannot arise anyway.
For multi-threading, only a single procedure may execute at any time for
a given object.

> 4. There are no errors from other sources (e.g. extraneous code,
>    higher-tier
>    documentation miscommunications).

You might formalize the higher-tier documentation as deferred (abstract)
Eiffel classes. The concrete system is built by deriving from the
deferred classes. DBC makes sure that the concrete classes will abide by
the contracts in the high-level specification classes.
Of course this does not preclude other communication problems. But
there's no silver bullet for this.

> Also: If the post-condition fails, who provides the corrective action?

A postcondition failure means the routine is wrong; as it already has
terminated executing, it cannot take corrective action.
So the caller is left to deal with the broken contract - either by
failing its own contract (the default reaction), or by taking corrective
action (catching the exception and trying some other approach).

> Also: If My_Aircraft.Add is provided by a different programmer/team
> than
> Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
> Why
> or
> why not?

I'm having trouble understanding the situation you're thinking of here.
Usually a class is written by a single programmer/team.
Besides, wether a routine is called once or twice doesn't seem related
to who wrote it, so I'm rather confused here...

> Also: it's my understanding that DBC requires My_Aircraft.Mine be made
> available
> to the client of Assume_Control (no private pre-conditions). Is this
> the
> case
> here?

Yes.

> Why or why not?

The caller must be able to check wether it has fulfilled all
preconditions. It can do so only if all features used in preconditions
are available to him.

> Does this mean that the pre-condition may be
> checked twice
> before each call?

Yes. (Only once with precondition checking turned off.)
However, this is misleading. If PBC is in place, you don't have to write

  do_something (My_Aircraft: AIRCRAFT) is
  do
    if MyAircraft.Mine then
      -- do something with My_Aircraft
    else
      -- declare error
    end;
  end; -- do_something

Instead, you write

  do_something (My_Aircraft: AIRCRAFT) is
  require My_Aircraft.Mine
  do
    -- do something with My_Aircraft
  end; -- do_something

which is shorter, and clearly separates the "defensive programming" part
from the really useful code.

> However, these results seem to be limited to making sure the code does
> what
> you thought it was supposed to do.
> How are the other failure sources
> handled?
> ...
> Also, given that Meyer claims the "most important" effect of
> assertions
> is manual analysis (see section 3.1 of same paper), shouldn't you be
> doing this
> anyway (in addition to any executable testing)? If you're not
> reviewing
> these manually, why not?

DBC doesn't handle external failure sources. It is there to make sure
that the code does what it's supposed to do.
As a very useful side effect, it also seduces the programmer into
getting a clear picture of what the routine is actually supposed to do
(something many programmers really need).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> > What if the mistake is in your code, not the calling code?
> 
> There's always an end to the chain in buck-passing. If the mistake is in
> our code, we obviously have to fix it. DBC is not a silver bullet, it is
> just a way of unambiguously distributing responsibilities (preconditions
> to the caller, postconditions to the callee - and the callee is *not*
> required to check its preconditions in its code).
> Or, if the system must be fail-safe, the buck is passed up to some
> routine that just takes note of the software failure and tries something
> else (or detonates the rocked).

Or shuts down?

My read of the Meyer paper is that DBC is designed to avoid
buck-passing:
that each routine is essentially bullet-proof internally. However, if
the
group "distributing the responsibilities" is also the group whose errors
you are trying to detect, how does this help?

> 
> > 1. My_Aircraft.Mine is correct. (How is this determined?
> 
> Proofreading.
> However, assertions are (hopefully) on a higher level than the program
> code, so the task of the proofreader becomes easier by that level.

Why would they be expected to be at a "higher level?" Take the example
in the Ariane 5 paper. It doesn't appear to have any particular
abstration associated with it.

Consider also the limits of proofreading described in my draft paper.
Furthermore, how does DBC make proofreading any easier than without?

> 
> >    Do assertions
> >    have
> >    assertions?
> 
> In Eiffel, no. Assertions are on a higher level of reasoning than the
> program code itself. The advice is to write simple assertions (again to
> make proofreading easier).

But writing simple assertions to make it easier to review also implies
only writing critical assertions to reduce the workload, doesn't it?
And if the wrong critical assertions are chosen, then more errors
are likely.

> Personally, I'm not totally sure wether this will properly scale up to
> arbitrarily large systems. Adding assertions to assertions, however,
> adds a second layer of checking (which would have to be read and
> understood by the proofreader), so assertions on assertions aren't too
> useful anyway.
> 
> > 2. Assume_Control is not called again with the same aircraft between
> >    the
> >    pre-condition and My_Aircraft.Add.
> > 3. Release_Control (I propose this as the opposite of Assume_Control)
> >    is
> >    not called between My_Aircraft.Add and the post-condition.
> 
> This is taken care of.
> For single-threaded applications, the problem cannot arise anyway.
> For multi-threading, only a single procedure may execute at any time for
> a given object.

So, in a real-time system, no interrupts can occur while a procedure is
executing? How is this managed, particularly for non-maskable
interrupts?
Assuming it is managed, how can latency be managed in such a system?
Is the nulti-threading rule part of the Eiffel spec, or part of an
implementation?

> 
> > 4. There are no errors from other sources (e.g. extraneous code,
> >    higher-tier
> >    documentation miscommunications).
> 
> You might formalize the higher-tier documentation as deferred (abstract)
> Eiffel classes. 

You might.. if (a) the requirements writer knows Eiffel, (b) all readers
know Eiffel, (c) Eiffel has been shown as a useful language for
requirements analysis (compare and contrast with tools such as
StateMate,
for example).

> The concrete system is built by deriving from the
> deferred classes. DBC makes sure that the concrete classes will abide by
> the contracts in the high-level specification classes.
> Of course this does not preclude other communication problems. But
> there's no silver bullet for this.
> 
> > Also: If the post-condition fails, who provides the corrective action?
> 
> A postcondition failure means the routine is wrong; as it already has
> terminated executing, it cannot take corrective action.
> So the caller is left to deal with the broken contract - either by
> failing its own contract (the default reaction), or by taking corrective
> action (catching the exception and trying some other approach).

Wouldn't that cause the very Ariane 5 failure that DBC was supposed to
prevent?

> 
> > Also: If My_Aircraft.Add is provided by a different programmer/team
> > than
> > Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
> > Why
> > or
> > why not?
> 
> I'm having trouble understanding the situation you're thinking of here.
> Usually a class is written by a single programmer/team.

Really? Doesn't sound like these routines get reused or maintained over
time!

> Besides, wether a routine is called once or twice doesn't seem related
> to who wrote it, so I'm rather confused here...

If different people/teams are each writing a separate piece of code
that has an interface between them, then any of the following can
happen:

1. One team checks the assertions associated with the interface (e.g.
the preconditions are checked by the callee).

2. Both teams do the check, not knowing that the other team is also
doing it
(or perhaps not caring, if they want their code to be separately
reusable.)
After all, the callee does make the preconditions available to the
caller
(see below), so why wouldn't they both end up doing the check (and
adding
the time to the system).

3. Each team assumes the other team does the check, and neither does it.

> > Also: it's my understanding that DBC requires My_Aircraft.Mine be made
> > available
> > to the client of Assume_Control (no private pre-conditions). Is this
> > the
> > case
> > here?
> 
> Yes.
> 
> > Why or why not?
> 
> The caller must be able to check wether it has fulfilled all
> preconditions. It can do so only if all features used in preconditions
> are available to him.
> 
> > Does this mean that the pre-condition may be
> > checked twice
> > before each call?
> 
> Yes. (Only once with precondition checking turned off.)
> However, this is misleading. If PBC is in place, you don't have to write
> 
>   do_something (My_Aircraft: AIRCRAFT) is
>   do
>     if MyAircraft.Mine then
>       -- do something with My_Aircraft
>     else
>       -- declare error
>     end;
>   end; -- do_something
> 
> Instead, you write
> 
>   do_something (My_Aircraft: AIRCRAFT) is
>   require My_Aircraft.Mine
>   do
>     -- do something with My_Aircraft
>   end; -- do_something
> 
> which is shorter, and clearly separates the "defensive programming" part
> from the really useful code.

Not the issue. The caller of do_something (potentially) calls
My_Aircraft.Mine, which
then calls My_Aircraft.Mine again. This doesn't seem like a particularly
efficient
way to manage assertions!

> 
> > However, these results seem to be limited to making sure the code does
> > what
> > you thought it was supposed to do.
> > How are the other failure sources
> > handled?
> > ...
> > Also, given that Meyer claims the "most important" effect of
> > assertions
> > is manual analysis (see section 3.1 of same paper), shouldn't you be
> > doing this
> > anyway (in addition to any executable testing)? If you're not
> > reviewing
> > these manually, why not?
> 
> DBC doesn't handle external failure sources.

How can this be, if you are "unambiguously distributing responsibilities
(preconditions to the caller...". Isn't the caller an "external failure
source"?

> It is there to make sure
> that the code does what it's supposed to do.
> As a very useful side effect, it also seduces the programmer into
> getting a clear picture of what the routine is actually supposed to do
> (something many programmers really need).

I would be much more convinced of this if there was a study that
demonstrated it. As you note above, excessive assertions can obfuscate
as well as clarify, and many Eiffel advocates seem to believe that
the more assertions, the better. Isn't this a self-defeating system?

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Ken Garlington wrote:

Lots of critisms about Don Harrisons ATC example.

OK Ken, You write a requirement document for Don's example and I'm sure
someone will code it up in Eiffel. Just a simple set of requirements
will do. 

PS In the UK the ATC are still using Jovial.

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Steve Jones - JON]

Nick Leaton <nickle@calfp.co.uk> writes:

[snip]
> PS In the UK the ATC are still using Jovial.

The new centre (NERC) is a majority Ada product, when it comes on line
however....

-- 
|---------------- C++ is to OO what C is to structured --------------------|
|----The above opinions rarely reflect my own and never my employers'------|
|Do not add me to mailing lists violations will be billed for time.        |

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Nick Leaton wrote:
> 
> Ken Garlington wrote:
> 
> Lots of critisms about Don Harrisons ATC example.
> 
> OK Ken, You write a requirement document for Don's example and I'm sure
> someone will code it up in Eiffel. Just a simple set of requirements
> will do.

See the ATC system requirements set in the ADARTS Guidebook, vol. 2.
(ATC is one of the example systems used to teach ADARTS). It's
reasonably
small, and chock-full of those tricky system timing issues that appear
to be trouble in Eiffel. (See, I can reuse requirements! :)

For more information, see http://www.software.org.

> 
> PS In the UK the ATC are still using Jovial.

So are we, on the F-16. A reasonably good language for such systems
(although
I like Ada better).

> 
> --
> 
> Nick

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> What we want is a way to signal to the caller that they've made a mistake and
:> need to take corrective action. 
:
:If they don't know to check that they might have made a mistake, 

They *do* know because they get an exception.

:how do they know what corrective action they should take?

To determine the right corrective action, they determine which specific 
(sub-)expression triggered the violation and work out the cause by conventional
means, namely logical deduction.

:If the erroneous code is reused in another application, doesn't it carry
:its error along with it?

Yes, that's why it's important to fix it. :)

:What if the mistake is in your code, not the calling code?

The context we're dicussing is a precondition, so I assume you mean a mistake 
in the precondition. This will be obvious from the fact that the call is valid. 
This is what I mean about the code proper validating assertions. (See my previous 
posts for details).


:> What about case 2)? Here, we want to check that the work we delegated was
:> done properly and acheived what we set out to do. In this case, we can
:> perform some checks and raise and exception against ourselves to force us
:> to fix the problem (possibly by delegating)..
:> 
:>   procedure Assume_Control (Aircraft: Aircraft_Type) is
:>   require not My_Aircraft.Mine (Aircraft)
:>   begin
:>     ...
:>     My_Aircraft.Add (Aircraft);
:>   ensure My_Aircraft.Mine (Aircraft)
:>   end;
:> 
:> which is our final solution. What we are now left with is a component of
:> software that we know can only be executed under the intended conditions and
:> can guarantee producing the required results.
:
:Assuming...
:
:1. My_Aircraft.Mine is correct. (How is this determined? 

Joachim has already mentioned code inspection. 

Also, if Mine is called anywhere in the code proper of the system and it has 
its own assertions, it will be validated by them. However, these lower-level 
assertions won't be evaluated as part of higher-level assertion evaluation.

(For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable
Software", Page 400 ff.)

In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are 
abstracted using boolean functions.

:Do assertions have assertions? 

See above.

:What happens if an assertion's assertion fails, and how
:is
:   it distinguished from an assertion failure?)

Because assertion checking is turned off during assertion evaluation, this
doesn't happen.

:2. Assume_Control is not called again with the same aircraft between the
:   pre-condition and My_Aircraft.Add.
:
:3. Release_Control (I propose this as the opposite of Assume_Control) is
:   not called between My_Aircraft.Add and the post-condition.

Neither of these concurrency issues exist under SCOOP because the runtime system 
automatically locks objects on behalf of the thread using them. It's simply 
impossible to have concurrent access to an object by multiple threads. 

(For details of object locking under SCOOP, see OOSC-2, Section 30.6 - 
"Accessing separate objects", Page 982 ff.)

Ada, in contrast, does allow this - for example, if tasking is used in isolation. 
To overcome this deficiency, you have to either roll-your-own object protection
(using semaphores, for example) or use protected objects. Using Ada protected 
objects is fine, but they lack the flexibility of Eiffel separate objects.

:4. There are no errors from other sources (e.g. extraneous code,
:higher-tier
:   documentation miscommunications).

I've already covered the case of extraneous code in a previous post. 

WRT documentation-related problems, these are outside the scope of any runtime 
error checking mechanism. DBC is *almost* a silver bullet but not quite. :)

:Correct?

All of these issues are either non-issues or already catered for.


:Also: If the post-condition fails, who provides the corrective action?

During development, you, the designer of the code (or your delegate) by fixing 
the problem. Additionally, in the case of critical software, you can add a
rescue clause (exception handler) to keep the show on the road in production. 

:Also: If My_Aircraft.Add is provided by a different programmer/team than
:Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)? 

It doesn't matter. What's your point?..

:Also: it's my understanding that DBC requires My_Aircraft.Mine be made
:available
:to the client of Assume_Control (no private pre-conditions). Is this the
:case
:here? Why or why not? Does this mean that the pre-condition may be
:checked twice
:before each call?

(Joachim's already answered this).


:> We now move on to the next
:> component and repeat the process. Step-by-step, piece-by-piece we construct
:> our reliable ATC system. We did so *incrementally* through a divide-and-conquer
:> strategy and by being demanding in what we expected of callers and demanding
:> of ourselves in producing the correct results.
:
:However, these results seem to be limited to making sure the code does what
:you thought it was supposed to do. 

Yes?..

:How are the other failure sources handled?

Clairvoyance. :)  Seriously, we already know that DBC can't identify all sources
of error. Other classes of error may be identified through other means that 
you're already well acquanted with.

:> Sorry if this is a bit Mickey Mouse for some, but some may find this helpful.


:Also, given that Meyer claims the "most important" effect of assertions
:is manual analysis (see section 3.1 of same paper), shouldn't you be
:doing this anyway (in addition to any executable testing)? 

Absolutely! For critical application, you want to do whatever you can to 
improve reliability - including manual analysis.

:If you're not reviewing these manually, why not?

I would.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> What we want is a way to signal to the caller that they've made a mistake and
> :> need to take corrective action.
> :
> :If they don't know to check that they might have made a mistake,
> 
> They *do* know because they get an exception.

Not when they're _writing_ the code, unfortunately. Remember, the
assumption is
that the caller (directly or indirectly) made a mistake to cause the
exception
in the first place. However, in your scheme, you're trusting them to
take the
right corrective action to a problem that they may have unintentionally
caused
in the first place!

Human lapses in judgement aren't usually confined to a few-second
bursts. If
they make an invalid assumption in their algorithm, they're probably
going to
maintain that same invalid assumption when writing their
exception-handling
code.

> 
> :how do they know what corrective action they should take?
> 
> To determine the right corrective action, they determine which specific
> (sub-)expression triggered the violation and work out the cause by conventional
> means, namely logical deduction.

This brings up the second point. Why would a methodology/language go to
great lengths to _detect_ errors, but completely punt ("use conventional
means") to determine what to do _afterwards_?

> :If the erroneous code is reused in another application, doesn't it carry
> :its error along with it?
> 
> Yes, that's why it's important to fix it. :)

Doesn't this erode the argument of using Eiffel to support reuse, if
errors
are so easily ported between applications?

> 
> :What if the mistake is in your code, not the calling code?
> 
> The context we're dicussing is a precondition, so I assume you mean a mistake
> in the precondition.  This will be obvious from the fact that the call is valid.

Your code thinks the call is invalid. Who decides otherwise?

> This is what I mean about the code proper validating assertions. (See my previous
> posts for details).
> 
> :> What about case 2)? Here, we want to check that the work we delegated was
> :> done properly and acheived what we set out to do. In this case, we can
> :> perform some checks and raise and exception against ourselves to force us
> :> to fix the problem (possibly by delegating)..
> :>
> :>   procedure Assume_Control (Aircraft: Aircraft_Type) is
> :>   require not My_Aircraft.Mine (Aircraft)
> :>   begin
> :>     ...
> :>     My_Aircraft.Add (Aircraft);
> :>   ensure My_Aircraft.Mine (Aircraft)
> :>   end;
> :>
> :> which is our final solution. What we are now left with is a component of
> :> software that we know can only be executed under the intended conditions and
> :> can guarantee producing the required results.
> :
> :Assuming...
> :
> :1. My_Aircraft.Mine is correct. (How is this determined?
> 
> Joachim has already mentioned code inspection.

See my arguments related to manual inspection as the only safeguard
against
errors in large systems.

> Also, if Mine is called anywhere in the code proper of the system and it has
> its own assertions, it will be validated by them. 

However, other posts have said that assertions shouldn't have
assertions.
What is the DBC position?

> However, these lower-level
> assertions won't be evaluated as part of higher-level assertion evaluation.
> 
> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable
> Software", Page 400 ff.)
> 
> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are
> abstracted using boolean functions.
> 
> :Do assertions have assertions?
> 
> See above.
> 
> :What happens if an assertion's assertion fails, and how
> :is
> :   it distinguished from an assertion failure?)
> 
> Because assertion checking is turned off during assertion evaluation, this
> doesn't happen.
> 
> :2. Assume_Control is not called again with the same aircraft between the
> :   pre-condition and My_Aircraft.Add.
> :
> :3. Release_Control (I propose this as the opposite of Assume_Control) is
> :   not called between My_Aircraft.Add and the post-condition.
> 
> Neither of these concurrency issues exist under SCOOP because the runtime system
> automatically locks objects on behalf of the thread using them. It's simply
> impossible to have concurrent access to an object by multiple threads.

So, if an object is referenced by a thread, no other operations
associated with
the object can be called (object-locking, as opposed to
operation-locking)?
Doesn't this cause a few latency problems? For example, it's usually OK
for
multiple reads to occur concurrently, so long as no write is in process.
SCOOP
only permits sequential reads?

> 
> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
> "Accessing separate objects", Page 982 ff.)
> 
> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
> To overcome this deficiency, you have to either roll-your-own object protection
> (using semaphores, for example) or use protected objects. Using Ada protected
> objects is fine, but they lack the flexibility of Eiffel separate objects.

Just the opposite! Protected objects, for example, would allow
concurrent reads
if no timing issues result!

> 
> :4. There are no errors from other sources (e.g. extraneous code,
> :higher-tier
> :   documentation miscommunications).
> 
> I've already covered the case of extraneous code in a previous post.

Right - you said that you assume this won't happen. I was just noting
this
fact.

> 
> WRT documentation-related problems, these are outside the scope of any runtime
> error checking mechanism. DBC is *almost* a silver bullet but not quite. :)

Is DBC a methodology, or a "runtime error checking mechanism"? I
certainly know
methodologies that will help uncover extraneous code, and
requirements/design
issues. In fact, some methodologies emphasize the ability to manage
requirements
and design, since that's where many of the really difficult errors
emerge.

> 
> :Correct?
> 
> All of these issues are either non-issues or already catered for.

I'm not sure that saying "DBC won't help with this" is the same as
saying
that they are "non-issues."

Someone needs to decide if DBC is a coding guideline or a software
development
methodology. My concern is that it is touted as the former, but used as
the
latter.

> 
> :Also: If the post-condition fails, who provides the corrective action?
> 
> During development, you, the designer of the code (or your delegate) by fixing
> the problem. Additionally, in the case of critical software, you can add a
> rescue clause (exception handler) to keep the show on the road in production.

So, the client has to figure out what to do if your code fails? I
wouldn't
be inspired to confidence to reuse such code!

> 
> :Also: If My_Aircraft.Add is provided by a different programmer/team than
> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
> 
> It doesn't matter. What's your point?..

It matters a lot! Again, if each team assumes the other does the call,
this
is bad news. If both teams do the call, this is not nice from a
efficiency
standpoint.

> 
> :Also: it's my understanding that DBC requires My_Aircraft.Mine be made
> :available
> :to the client of Assume_Control (no private pre-conditions). Is this the
> :case
> :here? Why or why not? Does this mean that the pre-condition may be
> :checked twice
> :before each call?
> 
> (Joachim's already answered this).
> 
> :> We now move on to the next
> :> component and repeat the process. Step-by-step, piece-by-piece we construct
> :> our reliable ATC system. We did so *incrementally* through a divide-and-conquer
> :> strategy and by being demanding in what we expected of callers and demanding
> :> of ourselves in producing the correct results.
> :
> :However, these results seem to be limited to making sure the code does what
> :you thought it was supposed to do.
> 
> Yes?..
> 
> :How are the other failure sources handled?
> 
> Clairvoyance. :)  Seriously, we already know that DBC can't identify all sources
> of error. 

But DBC is advertised as identifying other sources of error (e.g., the
code
does what's it's supposed to do, but only in a given environment).

> Other classes of error may be identified through other means that
> you're already well acquanted with.

Furthermore, the classes of error to which DBC is limited are
well-covered
through other means (beat to death, in fact). So, I'm still at a loss to
see what DBC brings to the table here. It doesn't address my main
problem
(requirements/design faults), it has limitations with respect to
implementation
language, it's not clear that it scales well, and it doesn't appear to
be internally
complete (big on error detection mechanisms, not much on how to derive
the
particular error sources, and not much on what to do after the error is
detected, for example).

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :Don Harrison wrote:
:> :>
:> :> What we want is a way to signal to the caller that they've made a mistake and
:> :> need to take corrective action.
:> :
:> :If they don't know to check that they might have made a mistake,
:> 
:> They *do* know because they get an exception.
:
:Not when they're _writing_ the code, unfortunately. 

Yes, but we're not talking about writing the code. We're talking about execution. 
Even Smalltalkers can't write and execute at the same time. :)


:> :how do they know what corrective action they should take?
:> 
:> To determine the right corrective action, they determine which specific
:> (sub-)expression triggered the violation and work out the cause by conventional
:> means, namely logical deduction.
:
:This brings up the second point. Why would a methodology/language go to
:great lengths to _detect_ errors, but completely punt ("use conventional
:means") to determine what to do _afterwards_?

DBC won't fix the errors for you. :)

No tool can *think* for you. DBC does help identify and localise errors, but 
you're the one who must solve them. 


:> :If the erroneous code is reused in another application, doesn't it carry
:> :its error along with it?
:> 
:> Yes, that's why it's important to fix it. :)
:
:Doesn't this erode the argument of using Eiffel to support reuse, if
:errors
:are so easily ported between applications?

No. If an error doesn't exist, it can't be ported.


:> :What if the mistake is in your code, not the calling code?
:> 
:> The context we're dicussing is a precondition, so I assume you mean a mistake
:> in the precondition.  This will be obvious from the fact that the call is valid.
:
:Your code thinks the call is invalid. Who decides otherwise?

The developer running the program - by thinking.


:> This is what I mean about the code proper validating assertions. (See my previous
:> posts for details).
:> 
:> :> What about case 2)? Here, we want to check that the work we delegated was
:> :> done properly and acheived what we set out to do. In this case, we can
:> :> perform some checks and raise and exception against ourselves to force us
:> :> to fix the problem (possibly by delegating)..
:> :>
:> :>   procedure Assume_Control (Aircraft: Aircraft_Type) is
:> :>   require not My_Aircraft.Mine (Aircraft)
:> :>   begin
:> :>     ...
:> :>     My_Aircraft.Add (Aircraft);
:> :>   ensure My_Aircraft.Mine (Aircraft)
:> :>   end;
:> :>
:> :> which is our final solution. What we are now left with is a component of
:> :> software that we know can only be executed under the intended conditions and
:> :> can guarantee producing the required results.
:> :
:> :Assuming...
:> :
:> :1. My_Aircraft.Mine is correct. (How is this determined?
:> 
:> Joachim has already mentioned code inspection.
:
:See my arguments related to manual inspection as the only safeguard
:against
:errors in large systems.

I'm not suggesting it should be.


:> Also, if Mine is called anywhere in the code proper of the system and it has
:> its own assertions, it will be validated by them. 
:
:However, other posts have said that assertions shouldn't have
:assertions.

We're talking about different things. See the OOSC-2 reference and my comments
following for details..

:> However, these lower-level
:> assertions won't be evaluated as part of higher-level assertion evaluation.
:> 
:> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable
:> Software", Page 400 ff.)
:> 
:> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are
:> abstracted using boolean functions.


:> :2. Assume_Control is not called again with the same aircraft between the
:> :   pre-condition and My_Aircraft.Add.
:> :
:> :3. Release_Control (I propose this as the opposite of Assume_Control) is
:> :   not called between My_Aircraft.Add and the post-condition.
:> 
:> Neither of these concurrency issues exist under SCOOP because the runtime system
:> automatically locks objects on behalf of the thread using them. It's simply
:> impossible to have concurrent access to an object by multiple threads.
:
:So, if an object is referenced by a thread, no other operations
:associated with
:the object can be called (object-locking, as opposed to
:operation-locking)?

In theory, yes. In practice, I would expect SCOOP implementations to provide 
greater flexibility through optimisations (See below).

:Doesn't this cause a few latency problems? For example, it's usually OK
:for
:multiple reads to occur concurrently, so long as no write is in process.
:SCOOP only permits sequential reads?

Optimisations could allow multiple concurrent queries (reads). The important 
is that exclusive access is *theoretically* guaranteed. What happens in practice
doesn't matter so long as it's safe.


:> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
:> "Accessing separate objects", Page 982 ff.)
:> 
:> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
:> To overcome this deficiency, you have to either roll-your-own object protection
:> (using semaphores, for example) or use protected objects. Using Ada protected
:> objects is fine, but they lack the flexibility of Eiffel separate objects.
:
:Just the opposite! 

Incorrect.

:Protected objects, for example, would allow concurrent reads
:if no timing issues result!

See above. You lose flexibility with protected types because they're not  
inheritable and can't be used polymorphically.

:> :4. There are no errors from other sources (e.g. extraneous code,
:> :higher-tier
:> :   documentation miscommunications).
:> 
:> I've already covered the case of extraneous code in a previous post.
:
:Right - you said that you assume this won't happen. 

No, I said something else. 


:> WRT documentation-related problems, these are outside the scope of any runtime
:> error checking mechanism. DBC is *almost* a silver bullet but not quite. :)
:
:Is DBC a methodology, or a "runtime error checking mechanism"? 

Both.

:I certainly know
:methodologies that will help uncover extraneous code, and
:requirements/design
:issues. In fact, some methodologies emphasize the ability to manage
:requirements
:and design, since that's where many of the really difficult errors
:emerge.

I agree this is an important area.


:Someone needs to decide if DBC is a coding guideline or a software
:development
:methodology. My concern is that it is touted as the former, but used as
:the latter.

I don't see any problem with using it as both.


:> :Also: If the post-condition fails, who provides the corrective action?
:> 
:> During development, you, the designer of the code (or your delegate) by fixing
:> the problem. Additionally, in the case of critical software, you can add a
:> rescue clause (exception handler) to keep the show on the road in production.
:
:So, the client has to figure out what to do if your code fails? 

Who said anything about clients? I said the designer of the code containing 
the postcondition - that is, the *supplier* in Eiffel parlance.

My original example, reinserted..

:  procedure Assume_Control (Aircraft: Aircraft_Type) is
:  require not My_Aircraft.Mine (Aircraft)
:  begin
:    ...
:    My_Aircraft.Add (Aircraft);
:  ensure My_Aircraft.Mine (Aircraft)
:  end;

:> :Also: If My_Aircraft.Add is provided by a different programmer/team than
:> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
:> 
:> It doesn't matter. What's your point?..
:
:It matters a lot! Again, if each team assumes the other does the call,
:this is bad news. 

Correct me if I have this wrong, but you seem to be worried about too few checks
and too many checks. 

WRT too few checks, it's always the responsibility of the client to make sure 
the precondition is met. So, a check will always be made.
 
WRT too many checks, an implementation may optimise out any redundant checks 
- for example if a precondition check is already done by a caller. This minimises
the number of redundant checks.

:If both teams do the call, this is not nice from a
:efficiency standpoint.

See above.


:> Other classes of error may be identified through other means that
:> you're already well acquanted with.
:
:Furthermore, the classes of error to which DBC is limited are
:well-covered
:through other means (beat to death, in fact). 

The difference is it does a better job of it.

:So, I'm still at a loss to
:see what DBC brings to the table here. It doesn't address my main
:problem (requirements/design faults), 

Not entirely true. DBC can highlight specification/design inconsistencies.
(See my previous posts). Otherwise, I agree. 

:it has limitations with respect to implementation language, 

More accurate is to say that most languages provide limited support for it.

:it's not clear that it scales well, 

Not true. 

:and it doesn't appear to be internally complete (big on error detection 
:mechanisms, not much on how to derive the particular error sources, 

That's because they're typically blindingly obvious! Why? Because error detection
is more localised.

:and not much on what to do after the error is detected, for example).

Again, this is usually blindingly obvious. 


All of these points have been made before. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> Ken Garlington wrote:
> :>
> :> :Don Harrison wrote:
> :> :>
> :> :> What we want is a way to signal to the caller that they've made a mistake and
> :> :> need to take corrective action.
> :> :
> :> :If they don't know to check that they might have made a mistake,
> :>
> :> They *do* know because they get an exception.
> :
> :Not when they're _writing_ the code, unfortunately.
> 
> Yes, but we're not talking about writing the code. We're talking about execution.
> Even Smalltalkers can't write and execute at the same time. :)

Eiffel advocates need to decide: Is the primary value of assertions for
documentation
(as Meyer maintains) or to raise errors during execution (which has a
number of
drawbacks, including potentially postponing the detection of the problem
until well
after it is delivered).

> 
> :> :how do they know what corrective action they should take?
> :>
> :> To determine the right corrective action, they determine which specific
> :> (sub-)expression triggered the violation and work out the cause by conventional
> :> means, namely logical deduction.
> :
> :This brings up the second point. Why would a methodology/language go to
> :great lengths to _detect_ errors, but completely punt ("use conventional
> :means") to determine what to do _afterwards_?
> 
> DBC won't fix the errors for you. :)

No, but other methodologies do discuss error recovery techniques, and
how to
apply them. This is particularly important if the error won't be
uncovered
until after it is delivered.

> No tool can *think* for you. DBC does help identify and localise errors, but
> you're the one who must solve them.
> 
> :> :If the erroneous code is reused in another application, doesn't it carry
> :> :its error along with it?
> :>
> :> Yes, that's why it's important to fix it. :)
> :
> :Doesn't this erode the argument of using Eiffel to support reuse, if
> :errors
> :are so easily ported between applications?
> 
> No. If an error doesn't exist, it can't be ported.

Consider the Ariane case. The error didn't exist in the original
environment
(Ariane IV). The error only occured during execution in the Ariane 5
environment (a little too late to fix, unfortunately). Basing your
argument
on execution means that any latent error in the system, which might be
caught in other methodologies through the use of analysis and reviews,
will
be missed using DBC/Eiffel.

> 
> :> :What if the mistake is in your code, not the calling code?
> :>
> :> The context we're dicussing is a precondition, so I assume you mean a mistake
> :> in the precondition.  This will be obvious from the fact that the call is valid.
> :
> :Your code thinks the call is invalid. Who decides otherwise?
> 
> The developer running the program - by thinking.

Which is completely contradicted by the abve statements of using
assertions
for execution purposes.

The whole point of a methodology is to guide the thinking of an analyst.
It
doesn't sound like DBC/Eiffel has given you much in the way of guidance.

> 
> :> This is what I mean about the code proper validating assertions. (See my previous
> :> posts for details).
> :>
> :> :> What about case 2)? Here, we want to check that the work we delegated was
> :> :> done properly and acheived what we set out to do. In this case, we can
> :> :> perform some checks and raise and exception against ourselves to force us
> :> :> to fix the problem (possibly by delegating)..
> :> :>
> :> :>   procedure Assume_Control (Aircraft: Aircraft_Type) is
> :> :>   require not My_Aircraft.Mine (Aircraft)
> :> :>   begin
> :> :>     ...
> :> :>     My_Aircraft.Add (Aircraft);
> :> :>   ensure My_Aircraft.Mine (Aircraft)
> :> :>   end;
> :> :>
> :> :> which is our final solution. What we are now left with is a component of
> :> :> software that we know can only be executed under the intended conditions and
> :> :> can guarantee producing the required results.
> :> :
> :> :Assuming...
> :> :
> :> :1. My_Aircraft.Mine is correct. (How is this determined?
> :>
> :> Joachim has already mentioned code inspection.
> :
> :See my arguments related to manual inspection as the only safeguard
> :against
> :errors in large systems.
> 
> I'm not suggesting it should be.

More to the point, you haven't given any evidence that DBC/Eiffel has
any
particular advantage in this area.

> :> Also, if Mine is called anywhere in the code proper of the system and it has
> :> its own assertions, it will be validated by them.
> :
> :However, other posts have said that assertions shouldn't have
> :assertions.
> 
> We're talking about different things. See the OOSC-2 reference and my comments
> following for details..
> 
> :> However, these lower-level
> :> assertions won't be evaluated as part of higher-level assertion evaluation.
> :>
> :> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable
> :> Software", Page 400 ff.)
> :>
> :> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are
> :> abstracted using boolean functions.
> 
> :> :2. Assume_Control is not called again with the same aircraft between the
> :> :   pre-condition and My_Aircraft.Add.
> :> :
> :> :3. Release_Control (I propose this as the opposite of Assume_Control) is
> :> :   not called between My_Aircraft.Add and the post-condition.
> :>
> :> Neither of these concurrency issues exist under SCOOP because the runtime system
> :> automatically locks objects on behalf of the thread using them. It's simply
> :> impossible to have concurrent access to an object by multiple threads.
> :
> :So, if an object is referenced by a thread, no other operations
> :associated with
> :the object can be called (object-locking, as opposed to
> :operation-locking)?
> 
> In theory, yes. In practice, I would expect SCOOP implementations to provide
> greater flexibility through optimisations (See below).
> 
> :Doesn't this cause a few latency problems? For example, it's usually OK
> :for
> :multiple reads to occur concurrently, so long as no write is in process.
> :SCOOP only permits sequential reads?
> 
> Optimisations could allow multiple concurrent queries (reads). The important
> is that exclusive access is *theoretically* guaranteed. What happens in practice
> doesn't matter so long as it's safe.

Has such automated optimization been done in practice? Isn't such an
optimization
on the same difficulty level as the toolset automatically generating the
correct assertions for each interface?

> 
> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
> :> "Accessing separate objects", Page 982 ff.)
> :>
> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
> :> To overcome this deficiency, you have to either roll-your-own object protection
> :> (using semaphores, for example) or use protected objects. Using Ada protected
> :> objects is fine, but they lack the flexibility of Eiffel separate objects.
> :
> :Just the opposite!
> 
> Incorrect.

Eiffel separate objects always lock the object. Ada protected records
can lock the
object for a given operation or not (at the designer's preference), can
requeue
requests, etc. More choices for the designer usually means additional
flexibility, I would think.

> 
> :Protected objects, for example, would allow concurrent reads
> :if no timing issues result!
> 
> See above. You lose flexibility with protected types because they're not
> inheritable and can't be used polymorphically.

But you gain flexibility in their timing capabilities (which is what we
were
discussing, remember? :). Given that the purpose of a protected type is
to
define time-based aspects the system, isn't this the more valuiable
flexibility
for this type of object?

> 
> :> :4. There are no errors from other sources (e.g. extraneous code,
> :> :higher-tier
> :> :   documentation miscommunications).
> :>
> :> I've already covered the case of extraneous code in a previous post.
> :
> :Right - you said that you assume this won't happen.
> 
> No, I said something else.

You said that you did not provide exhaustive coverage via assertions. If
that
doesn't mean that you assume the condition will not occur, what does it
mean?
That you assume it will occur, but do not address it?

> 
> :> WRT documentation-related problems, these are outside the scope of any runtime
> :> error checking mechanism. DBC is *almost* a silver bullet but not quite. :)
> :
> :Is DBC a methodology, or a "runtime error checking mechanism"?
> 
> Both.

Then what does it matter what a "runtime error checking mechanism" does?
The question remains: How does DBC address documentation-related
problems?

> 
> :I certainly know
> :methodologies that will help uncover extraneous code, and
> :requirements/design
> :issues. In fact, some methodologies emphasize the ability to manage
> :requirements
> :and design, since that's where many of the really difficult errors
> :emerge.
> 
> I agree this is an important area.

Given that, then if DBC does not address this area, it must be
deficient.

> 
> :Someone needs to decide if DBC is a coding guideline or a software
> :development
> :methodology. My concern is that it is touted as the former, but used as
> :the latter.
> 
> I don't see any problem with using it as both.

However, there is a serious problem when practitioners use it (and
discuss it) in terms of the former. Note the number of times in this
post, for example, that DBC has been described in terms of concrete
capabilities when the subject is code execution, but only vaguely
(if at all) when described as a methodology. For example:

1. How, specifically, does DBC support error detection prior to
execution?
(Not writing down potential error sources, but actually determining if
the
error exists in the particular application.)

2. By extension, how does DBC support error detection after reuse?

3. For those errors not discovered (which will presumably cause run-time
exceptions), how does DBC guide the designer to handle these exceptions
(which were not expected to occur)?

4. How does DBC help detect inconsistencies between code and
requirements,
or for that matter internal consistencies within the requirements?

Given that we both agree (as noted earlier in the post) that the key is
for the designer to think, how does a coding convention support such
thinking - not in terms of general OO concepts like polymorphism and
inheritance (which other languages, including Ada, have) but in terms of
error detection and correction?

> 
> :> :Also: If the post-condition fails, who provides the corrective action?
> :>
> :> During development, you, the designer of the code (or your delegate) by fixing
> :> the problem. Additionally, in the case of critical software, you can add a
> :> rescue clause (exception handler) to keep the show on the road in production.
> :
> :So, the client has to figure out what to do if your code fails?
> 
> Who said anything about clients? I said the designer of the code containing
> the postcondition - that is, the *supplier* in Eiffel parlance.

Wait a minute! Here's the possible scenarios:

1. The post-condition fails during initial development. In this case,
the
developer of the code fixes the problem (or changes the post-condition,
as unfortunately sometimes happens). However, how often is the
post-condition
going to fail at this point? The developer writes both the code and the
post-condition, so it's likely that they will match at that point.

2. The post-condition fails after delivery. The developer may no longer
be around
to fix the problem. Furthermore, if there is a rescue clause, what does
it do?
What guidance does DBC provide.

3. The post-condition fails during reuse development. Same outcome as
#2. This
is the most likely case for a post-condition failing - where the
environment
in which the module is used changes.

Any methodology that postpones finding errors until the code is reused
is going
to be difficult to sell as "reuse-friendly".

> 
> My original example, reinserted..
> 
> :  procedure Assume_Control (Aircraft: Aircraft_Type) is
> :  require not My_Aircraft.Mine (Aircraft)
> :  begin
> :    ...
> :    My_Aircraft.Add (Aircraft);
> :  ensure My_Aircraft.Mine (Aircraft)
> :  end;
> 
> :> :Also: If My_Aircraft.Add is provided by a different programmer/team than
> :> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
> :>
> :> It doesn't matter. What's your point?..
> :
> :It matters a lot! Again, if each team assumes the other does the call,
> :this is bad news.
> 
> Correct me if I have this wrong, but you seem to be worried about too few checks
> and too many checks.
> 
> WRT too few checks, it's always the responsibility of the client to make sure
> the precondition is met. So, a check will always be made.

Hasn't this whole discussion been in terms of how to detect errors in
the code?
Isn't it a little naive to assume that the code will be written
correctly as a
precondition for finding errors in the code?

For that matter, if it's the client's responsibility, and it doesn't
hurt if
the assertion is not performed by the object being used, then doesn't
this
cut the legs out of an argument of Eiffel's power? Pretty much any
language
can provide assertions for the client to manually call prior to using an
operation.

> 
> WRT too many checks, an implementation may optimise out any redundant checks
> - for example if a precondition check is already done by a caller. This minimises
> the number of redundant checks.

You're assuming a lot about automated optimizations across object
interface
boundaries. Is there evidence that Eiffel compilers do such
optimizations
successfully? Worse, you're again in the "proof by execution" mode. What
does
this extra code do in terms of readability, for example?

> :If both teams do the call, this is not nice from a
> :efficiency standpoint.
> 
> See above.

Ditto. Any methodology that says, "Write as much code as you want, the
compiler will optimize it" doesn't seem to be a strong methodology, in
my opinion.

> 
> :> Other classes of error may be identified through other means that
> :> you're already well acquanted with.
> :
> :Furthermore, the classes of error to which DBC is limited are
> :well-covered
> :through other means (beat to death, in fact).
> 
> The difference is it does a better job of it.

We'll just have to agree to disagree on this one. Again, I would rather
have a methodology that helps me think about the issues vs. coding them.

> 
> :So, I'm still at a loss to
> :see what DBC brings to the table here. It doesn't address my main
> :problem (requirements/design faults),
> 
> Not entirely true. DBC can highlight specification/design inconsistencies.
> (See my previous posts). Otherwise, I agree.

I saw your previous posts. I quote from the line above:

  "WRT documentation-related problems, these are outside the scope of
  any runtime error checking mechanism. DBC is *almost* a silver bullet
  but not quite."

Please summarize your arguments/evidence that DBC helps find
documentation-
related problems.

> 
> :it has limitations with respect to implementation language,
> 
> More accurate is to say that most languages provide limited support for it.

Two responses:

1. I was discussing limitations in Eiffel, and

2. Other Eiffel experts disagree with you with regard to other
languages:

See the post on Internet newsgroup comp.lang.eiffel "Re: Papers on the
Ariane-5
crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "Ada's
subtype
declarations are a kind of contract, that could be documented as such.
Design
by contract is not specific to Eiffel. You can do it with any language,
just
because it is a way of designing!"

> 
> :it's not clear that it scales well,
> 
> Not true.

Can you provide evidence to the contrary?

See Internet newsgroup comp.lang.eiffel post "Re: Papers on the
Ariane-5 crash and Design by Contract," Jean-Marc Jezequel,
1997/03/18: "...at least in the case of Ariane 501, simple assertions
(a la Eiffel and other languages) would have been expressive enough to
specify the fatal hidden assumption. Whether the last point scales up
to a full sized mission critical system is still an open question.
I'm quite confident it is so, but I've only my own experience with telco
systems to back it up."

> 
> :and it doesn't appear to be internally complete (big on error detection
> :mechanisms, not much on how to derive the particular error sources,
> 
> That's because they're typically blindingly obvious! Why? Because error detection
> is more localised.

But interface errors, by definition, are not localized. They are
generated
due to the interaction between objects (in some cases, a long thread of
object interactions). The Ariane 5 case is a perfect example of this.

Requirements/design mismatches, similarly, are not localized since the
requirements are usually not written in terms of objects. One of the
designer's jobs is to map the requirements to objects. Even for
requirements that are object-oriented, they are usually a much higher
level than the implementation.

Again, you're thinking of run-time error detection. This is the worst
place
to detect errors. Consider, for example, the errors made in the Eiffel
implementation of the scaling routine presented in their Ariane paper.
If these errors were "blindingly obvious", why did it take a year for
anyone to say anything about them?

> 
> :and not much on what to do after the error is detected, for example).
> 
> Again, this is usually blindingly obvious.

Any time someone says something is obvious, without any evidence or
argument to support it, I pretty much assume that the point is ceded.
I will say that if error recovery is blindingly obvious, then there's
a lot of work in the fault tolerance world that's apparently just a
waste of money. :)

> 
> All of these points have been made before.

Unfortunately, I think you're right. It doesn't seem as though we're
communicating very effectively. I'll concede the argument to you.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jim Cochrane]

In article <33E9ADE9.4709@flash.net>,
Ken Garlington  <kennieg@flash.net> wrote:
>Don Harrison wrote:
>> 
>> Ken Garlington wrote:
>> 
>> :Don Harrison wrote:
>> :>
>> :> Ken Garlington wrote:
>> :>
>> :> :Don Harrison wrote:
>> :> :>
>> :> :> What we want is a way to signal to the caller that they've made a mistake and
>> :> :> need to take corrective action.
>> :> :
>> :> :If they don't know to check that they might have made a mistake,
>> :>
>> :> They *do* know because they get an exception.
>> :
>> :Not when they're _writing_ the code, unfortunately.
>> 
>> Yes, but we're not talking about writing the code. We're talking about execution.
>> Even Smalltalkers can't write and execute at the same time. :)
>
>Eiffel advocates need to decide: Is the primary value of assertions for
>documentation
>(as Meyer maintains) or to raise errors during execution (which has a
>number of
>drawbacks, including potentially postponing the detection of the problem
>until well
>after it is delivered).

I think the most important use of Eiffel assertions (specifically
require, ensure, and (class) invariant) is for documentation - that is,
to provide a precise specification of the precondition and postcondition
for each public method and of the class invariant.  Specifications that
are not codable can still be documented as comments.  Tools that are part
of the standard Eiffel environment automatically extract these specifications
so that a programmer who is using a class will have access to the
documentation of the class's interface without needing to look at the
class implementation.

> ...
>> 
>> :Someone needs to decide if DBC is a coding guideline or a software
>> :development
>> :methodology. My concern is that it is touted as the former, but used as
>> :the latter.
>> 
>> I don't see any problem with using it as both.
>
>However, there is a serious problem when practitioners use it (and
>discuss it) in terms of the former. Note the number of times in this
>post, for example, that DBC has been described in terms of concrete
>capabilities when the subject is code execution, but only vaguely
>(if at all) when described as a methodology. For example:
>
>1. How, specifically, does DBC support error detection prior to
>execution?
>(Not writing down potential error sources, but actually determining if
>the
>error exists in the particular application.)

The concept of design by contract is simply an extension of the ideas
presented by Dijkstra, Gries, and others on the design of correct
programs.  An important component of these ideas is the specification of a
precise pre- and post-condition for each coded procedure.  The extensions
made to this component by the principle of design by contract include
adapting it to an object-oriented system (by adding class invariants
and having the procedures belong to a class) and providing language
support for these specifications.

To address the above question in this context, design by contract can
be used as part of a formal development process that uses design and
code inspections as a means of detecting and removing design and code
defects.  The technique of precisely specifying class interfaces,
aided with tools to extract this specification to make it easily
available, enhances the inspection process by making these interfaces
explicit.  Thus, for example, when the implementation of a method m that
uses class X is inspected, the use of X's methods by m can be examined
to determine if m uses X's methods correctly; this is done by checking,
for example, for a call of X.a in m, that the precondition of X.a will
be true when the call is made.  Additionally, m's postcondition can
be used during an inspection to check if it will always be true by
analyzing the implementation of m - that is, by answering the question:
When m's implementation is executed, will it always terminate with
the postcondition true?

Thus (in my opinion), design by contract is not a method.  Rather it
is a technique that is a useful component of a method.  The contribution
of the this technique is that it ensures a precise and explicit
specification of a class interface so that the use of the interface
can be examined by means of its pre-conditions to make sure that it
is used correctly, and the implementation of the interface can be
examined by means of its post-conditions and class invariant to make
sure that it is implemented correctly.  In any object-oriented design,
all class interfaces will have specifications.  If the specifications
are not explicitly documented, it will be more difficult to use the
interface correctly.  When the specifications are explicitly documented,
it becomes easier to use the interface correctly, as well as easier to
detect defects in the use or implementation of the interface.

>
>2. By extension, how does DBC support error detection after reuse?

If I understand what you're asking, design by contract can be used to
detect errors in the use of a reusable component by examining the
use of the component by the client code and determining if the
pre-conditions specified by the reusable component's interface are
true for every call in the client code of a method belonging to the
interface.

>
>3. For those errors not discovered (which will presumably cause run-time
>exceptions), how does DBC guide the designer to handle these exceptions
>(which were not expected to occur)?

I think that the originator of the concept of design by contract,
Meyer, has presented some guidelines for handling exceptions.  However,
although these guidelines may be helpful, I think the designer of
the software is going to need to decide how to handle each situation
where an exception could occur.

>
>4. How does DBC help detect inconsistencies between code and
>requirements,
>or for that matter internal consistencies within the requirements?

Again, (in my opinion) design by contract is not a method; and it cannot
solve these problems.  It should be used as part of a method.  Areas
such as these that are not addressed by design by contract, should
be addressed by means of other method components.  Design by contract
could help to detect inconsistencies between code and requirements,
since it makes the interface specifications of the code explicit, thus
making it easier to detect such inconsistencies simply because the
documentation of the specifications is available; but it cannot be
used as the only means to detect these inconsistencies.

From your post, my impression is that you are assuming that design
by contract is a method whose purpose is to develop software as free
from defects as possible.  I think if you adjust your view and look
at it as a technique or tool that is part of such a method, this may
clear up some of the confusion.  In other words, the application of
design by contract will not guarantee high quality software.  This is
only possible if it is applied wisely as part of a comprehensive method.
And even a comprehensive method cannot guarantee high quality software;
it is also necessary to apply one's own exertion, intelligence, and
wisdom.  A method may guide us in developing high quality software,
but we will still need to make difficult decisions.  Regardless of the
method used, a poorly made decision can detract from the quality of the
software we are developing.


Jim Cochrane
jtc@dimensional.com

>
>Given that we both agree (as noted earlier in the post) that the key is
>for the designer to think, how does a coding convention support such
>thinking - not in terms of general OO concepts like polymorphism and
>inheritance (which other languages, including Ada, have) but in terms of
>error detection and correction?
>
>> 
>> :> :Also: If the post-condition fails, who provides the corrective action?
>> :>
>> :> During development, you, the designer of the code (or your delegate) by fixing
>> :> the problem. Additionally, in the case of critical software, you can add a
>> :> rescue clause (exception handler) to keep the show on the road in production.
>> :
>> :So, the client has to figure out what to do if your code fails?
>> 
>> Who said anything about clients? I said the designer of the code containing
>> the postcondition - that is, the *supplier* in Eiffel parlance.
>
>Wait a minute! Here's the possible scenarios:
>
>1. The post-condition fails during initial development. In this case,
>the
>developer of the code fixes the problem (or changes the post-condition,
>as unfortunately sometimes happens). However, how often is the
>post-condition
>going to fail at this point? The developer writes both the code and the
>post-condition, so it's likely that they will match at that point.
>
>2. The post-condition fails after delivery. The developer may no longer
>be around
>to fix the problem. Furthermore, if there is a rescue clause, what does
>it do?
>What guidance does DBC provide.
>
>3. The post-condition fails during reuse development. Same outcome as
>#2. This
>is the most likely case for a post-condition failing - where the
>environment
>in which the module is used changes.
>
>Any methodology that postpones finding errors until the code is reused
>is going
>to be difficult to sell as "reuse-friendly".
>
>> 
>> My original example, reinserted..
>> 
>> :  procedure Assume_Control (Aircraft: Aircraft_Type) is
>> :  require not My_Aircraft.Mine (Aircraft)
>> :  begin
>> :    ...
>> :    My_Aircraft.Add (Aircraft);
>> :  ensure My_Aircraft.Mine (Aircraft)
>> :  end;
>> 
>> :> :Also: If My_Aircraft.Add is provided by a different programmer/team than
>> :> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
>> :>
>> :> It doesn't matter. What's your point?..
>> :
>> :It matters a lot! Again, if each team assumes the other does the call,
>> :this is bad news.
>> 
>> Correct me if I have this wrong, but you seem to be worried about too few checks
>> and too many checks.
>> 
>> WRT too few checks, it's always the responsibility of the client to make sure
>> the precondition is met. So, a check will always be made.
>
>Hasn't this whole discussion been in terms of how to detect errors in
>the code?
>Isn't it a little naive to assume that the code will be written
>correctly as a
>precondition for finding errors in the code?
>
>For that matter, if it's the client's responsibility, and it doesn't
>hurt if
>the assertion is not performed by the object being used, then doesn't
>this
>cut the legs out of an argument of Eiffel's power? Pretty much any
>language
>can provide assertions for the client to manually call prior to using an
>operation.
>
>> 
>> WRT too many checks, an implementation may optimise out any redundant checks
>> - for example if a precondition check is already done by a caller. This minimises
>> the number of redundant checks.
>
>You're assuming a lot about automated optimizations across object
>interface
>boundaries. Is there evidence that Eiffel compilers do such
>optimizations
>successfully? Worse, you're again in the "proof by execution" mode. What
>does
>this extra code do in terms of readability, for example?
>
>> :If both teams do the call, this is not nice from a
>> :efficiency standpoint.
>> 
>> See above.
>
>Ditto. Any methodology that says, "Write as much code as you want, the
>compiler will optimize it" doesn't seem to be a strong methodology, in
>my opinion.
>
>> 
>> :> Other classes of error may be identified through other means that
>> :> you're already well acquanted with.
>> :
>> :Furthermore, the classes of error to which DBC is limited are
>> :well-covered
>> :through other means (beat to death, in fact).
>> 
>> The difference is it does a better job of it.
>
>We'll just have to agree to disagree on this one. Again, I would rather
>have a methodology that helps me think about the issues vs. coding them.
>
>> 
>> :So, I'm still at a loss to
>> :see what DBC brings to the table here. It doesn't address my main
>> :problem (requirements/design faults),
>> 
>> Not entirely true. DBC can highlight specification/design inconsistencies.
>> (See my previous posts). Otherwise, I agree.
>
>I saw your previous posts. I quote from the line above:
>
>  "WRT documentation-related problems, these are outside the scope of
>  any runtime error checking mechanism. DBC is *almost* a silver bullet
>  but not quite."
>
>Please summarize your arguments/evidence that DBC helps find
>documentation-
>related problems.
>
>> 
>> :it has limitations with respect to implementation language,
>> 
>> More accurate is to say that most languages provide limited support for it.
>
>Two responses:
>
>1. I was discussing limitations in Eiffel, and
>
>2. Other Eiffel experts disagree with you with regard to other
>languages:
>
>See the post on Internet newsgroup comp.lang.eiffel "Re: Papers on the
>Ariane-5
>crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "Ada's
>subtype
>declarations are a kind of contract, that could be documented as such.
>Design
>by contract is not specific to Eiffel. You can do it with any language,
>just
>because it is a way of designing!"
>
>> 
>> :it's not clear that it scales well,
>> 
>> Not true.
>
>Can you provide evidence to the contrary?
>
>See Internet newsgroup comp.lang.eiffel post "Re: Papers on the
>Ariane-5 crash and Design by Contract," Jean-Marc Jezequel,
>1997/03/18: "...at least in the case of Ariane 501, simple assertions
>(a la Eiffel and other languages) would have been expressive enough to
>specify the fatal hidden assumption. Whether the last point scales up
>to a full sized mission critical system is still an open question.
>I'm quite confident it is so, but I've only my own experience with telco
>systems to back it up."
>
>> 
>> :and it doesn't appear to be internally complete (big on error detection
>> :mechanisms, not much on how to derive the particular error sources,
>> 
>> That's because they're typically blindingly obvious! Why? Because error detection
>> is more localised.
>
>But interface errors, by definition, are not localized. They are
>generated
>due to the interaction between objects (in some cases, a long thread of
>object interactions). The Ariane 5 case is a perfect example of this.
>
>Requirements/design mismatches, similarly, are not localized since the
>requirements are usually not written in terms of objects. One of the
>designer's jobs is to map the requirements to objects. Even for
>requirements that are object-oriented, they are usually a much higher
>level than the implementation.
>
>Again, you're thinking of run-time error detection. This is the worst
>place
>to detect errors. Consider, for example, the errors made in the Eiffel
>implementation of the scaling routine presented in their Ariane paper.
>If these errors were "blindingly obvious", why did it take a year for
>anyone to say anything about them?
>
>> 
>> :and not much on what to do after the error is detected, for example).
>> 
>> Again, this is usually blindingly obvious.
>
>Any time someone says something is obvious, without any evidence or
>argument to support it, I pretty much assume that the point is ceded.
>I will say that if error recovery is blindingly obvious, then there's
>a lot of work in the fault tolerance world that's apparently just a
>waste of money. :)
>
>> 
>> All of these points have been made before.
>
>Unfortunately, I think you're right. It doesn't seem as though we're
>communicating very effectively. I'll concede the argument to you.
>
>> 
>> Don.
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <5siqrr$3of@jupiter.milkyway.org>, jtc@jupiter.milkyway.org says...

>I think the most important use of Eiffel assertions (specifically
>require, ensure, and (class) invariant) is for documentation [...]

While this is true, the importance of executable assertions should not
be under-estimated.  Execution acts as a safeguard on the inspection and
documentation parts.  We've all worked on projects where the documentation
has been put off or not done because of schedule pressure.  Everyone agrees
that this is a bad thing, but it still keeps on happening.  Executable
assertions won't let you do this.

A mature software process can also use this property by tracking assertion
failures and using them to monitor and improve inspection procedures.



> [...] I think the designer of
>the software is going to need to decide how to handle each situation
>where an exception could occur.

This is true.  It depends on the context of the application.  For example
a real-time control system would shut down, re-initialise and try to
continue.  For safety or mission-critical apps it would let the back-up
take over (yes, I've read the Ariane 5 report).  For an interactive
application it would try to save the user data, put up an informative
message, and close down.

Paul

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
> In article <5siqrr$3of@jupiter.milkyway.org>, jtc@jupiter.milkyway.org says...
> 
> >I think the most important use of Eiffel assertions (specifically
> >require, ensure, and (class) invariant) is for documentation [...]
> 
> While this is true, the importance of executable assertions should not
> be under-estimated.  Execution acts as a safeguard on the inspection and
> documentation parts.  We've all worked on projects where the documentation
> has been put off or not done because of schedule pressure.  Everyone agrees
> that this is a bad thing, but it still keeps on happening.  Executable
> assertions won't let you do this.

Leaving out executable assertions is just as easy as leaving out
non-executable
ones, isn't it?

> A mature software process can also use this property by tracking assertion
> failures and using them to monitor and improve inspection procedures.

Is there a systematic method for reviewing code to determine if the
right
number and type of assertions have been added? This would seem to be the
more critical issue. Without any assertions, the number of assertions
failures can be predicted with some confidence :)

> 
> > [...] I think the designer of
> >the software is going to need to decide how to handle each situation
> >where an exception could occur.
> 
> This is true.  It depends on the context of the application.  For example
> a real-time control system would shut down, re-initialise and try to
> continue.  For safety or mission-critical apps it would let the back-up
> take over (yes, I've read the Ariane 5 report).  For an interactive
> application it would try to save the user data, put up an informative
> message, and close down.

I think this is a little over-simplified. For example, in each case:

1. A real-time feedback system would probably not want to shut down,
   even for a small interval.

2. As you note, turning over control to a backup is not always a good
idea.

3. Interactive application error messages can be missed (see the recent
   InterNIC risk).

Real-world exception responses in complex systems can be extremely
difficult to analyze.

> 
> Paul
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Mark A Biggar]

In article <33EFCCE4.4CE0@flash.net> Ken.Garlington@computer.org writes:
>Paul Johnson wrote:
>Leaving out executable assertions is just as easy as leaving out
>non-executable
>ones, isn't it?

Sure, even if assertions are required by the language syntax,
you can always just use the assertion "true" :-).
You can't even make using the assertion "true" illegal as there are
cases where the assertion "true" is exactly the correct assertion to 
use; for example, using "true" as a precondition for a method documents the
fact that it has NO enviromential requirements at all. (E.G. a random
number routine or the Unix exit() call).  And, what is the postcondition
for printf()?

--
Mark Biggar
mab@wdl.lmco.com

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Mark says

<<Sure, even if assertions are required by the language syntax,
you can always just use the assertion "true" :-).
You can't even make using the assertion "true" illegal as there are
cases where the assertion "true" is exactly the correct assertion to
use; for example, using "true" as a precondition for a method documents the
fact that it has NO enviromential requirements at all. (E.G. a random
number routine or the Unix exit() call).  And, what is the postcondition
for printf()?>>

As for the last question, this is just the tip of the iceburg. Of course it
is not the case that all requirements can be caught by pre and post conditions.

The idea of using pre and post conditions and assertions is very old. It
is useful but by no means applicable in all cases.

What should be the post condition after outputting an error message
from a compiler?

pragma Assert (programmer now understands what they did wrong);

You need a *really* clever language to test that one (well I suppose the
assertion routine executed at runtime could ask the programmer whether
he understood :-)

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Robert Dewar wrote:
> 
> Mark says
> 
> <<Sure, even if assertions are required by the language syntax,
> you can always just use the assertion "true" :-).
> You can't even make using the assertion "true" illegal as there are
> cases where the assertion "true" is exactly the correct assertion to
> use; for example, using "true" as a precondition for a method documents the
> fact that it has NO enviromential requirements at all. (E.G. a random
> number routine or the Unix exit() call).  And, what is the postcondition
> for printf()?>>

Well if we take the Eiffel equivalents of printf, which are put_string,
put_integer ...

Basically put_<basic_type>. We can come up with sensible
postconditions.

Since we are writting to a file, and let us assume we have have a method
called file_position, which returns the position in the file.

For put_string we have

ensure
   old file_position + string.count = file_position

Since other routines are likely to use this to output the 
formatted values that means the other postconditions are
to be found in the formatting routines, where they 
belong.
 

> As for the last question, this is just the tip of the iceburg. Of course it
> is not the case that all requirements can be caught by pre and post conditions.

Agreed, but you should be breaking your requirements down into
smaller parts. 

Some are expressable, but wise to do. Membership of collections
is one, and specifying the postcondition of a sorted collection
is also not a wise postcondition to add.

If you were writing a library they may be a wise addition. Running them
in production code wouldn't be. It is too inefficient.

> The idea of using pre and post conditions and assertions is very old. It
> is useful but by no means applicable in all cases.
> 
> What should be the post condition after outputting an error message
> from a compiler?

> pragma Assert (programmer now understands what they did wrong);
> 
> You need a *really* clever language to test that one (well I suppose the
> assertion routine executed at runtime could ask the programmer whether
> he understood :-)

Please explain?

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Bertrand Meyer]

Robert Dewar wrote:
 
> What should be the post condition after outputting an error message
> from a compiler?
> 
> pragma Assert (programmer now understands what they did wrong);
> 
> You need a *really* clever language to test that one
> (well I suppose the
> assertion routine executed at runtime could ask the programmer whether
> he understood :-)

You obviously must know better. The postcondition, if it
needs to be expressed, is something like "string XXX" [the
argument to the routine] "has been appended to the output".
With the proper model this is easy to express formally.


-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel from those who invented it ==

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Bertrand says

<<You obviously must know better. The postcondition, if it
needs to be expressed, is something like "string XXX" [the
argument to the routine] "has been appended to the output".
With the proper model this is easy to express formally.>>

But that's the whole point. Sure you can write a (pretty useless)
postcondition after 

print ("this is my useless error message");

to make sure you have added that string to the output file, but that tests
only whether your code is working, not whether it meets the specification,
which was to produce intelligible error messages. And I do not know what
you mean by "know better". If you mean do I know perfectly well that
postconditions cannot capture this kind of specification, yes, I know
that perfectly well -- many specifications and requirements cannot be
formalized in any useful manner.

Re: Safety-critical development in Ada and Eiffel

[Lee Webber]

On 19 Aug 1997 22:33:04 -0400, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>Bertrand says
>
><<You obviously must know better. The postcondition, if it
>needs to be expressed, is something like "string XXX" [the
>argument to the routine] "has been appended to the output".
>With the proper model this is easy to express formally.>>
>
>But that's the whole point. Sure you can write a (pretty useless)
>postcondition after 
>
>print ("this is my useless error message");
>
>to make sure you have added that string to the output file, but that tests
>only whether your code is working, not whether it meets the specification,
>which was to produce intelligible error messages. And I do not know what
>you mean by "know better". If you mean do I know perfectly well that
>postconditions cannot capture this kind of specification, yes, I know
>that perfectly well -- many specifications and requirements cannot be
>formalized in any useful manner.
>

You've got a point here, but I think you're making too much of it.
This is a problem with all specification, not just assertions: you
can't formally specify an interface between a component of your system
and an external entity that itself is not specifiable.  But of course
everyone knows that.

This problem propagates all the way back to the requirements (how do
you engineer an "intelligible" set of messages so that they are
guaranteed to pass an acceptance test unless you specify the
acceptance test in advance?).  It isn't really an issue for the
solution domain.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Lee Webber wrote:

:Robert Dewar wrote:
:
:>... many specifications and requirements cannot be
:>formalized in any useful manner.
:
:You've got a point here, but I think you're making too much of it.
:This is a problem with all specification, not just assertions: 

Exactly, and typically such requirements are both untestable yet obviously 
desirable (intelligible messages, for example). As a basic rule, if you can't 
specify something in verifiable terms, then it shouldn't be specified as a 
requirement. It should be recorded as desirable behaviour ("will" rather than 
"shall"): 

  "Messages to the operator will be intelligible".

Having said that, it's also true that verifiable specifications *do* get omitted
from specifications, not because it's impossible to specify them, but because 
they're difficult to specify. Although some are unlikely to admit it, the Ariane 
profile thingo probably falls into that category.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

> Having said that, it's also true that verifiable specifications *do* get omitted
> from specifications, not because it's impossible to specify them, but because
> they're difficult to specify. Although some are unlikely to admit it, the Ariane
> profile thingo probably falls into that category.

Total nonsense. Flight envelopes can easily be specified, and usually
are.
They can also be tested. Read the inquiry report: The profile "thingo"
was
left out not because it was hard to specify, but because it (and the
corresponding validation) was thought to be _unnecessary_, since the
system was already in operation.

What would be difficult would be to write an assertion to capture the
flight envelope. This would require a model of the environment inside
the code. Such a model can be created in a laboratory and used to
validate a system, but it is difficult (not impossible, but difficult)
to build it into the system itself.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Robert Dewar wrote:
> 
> Bertrand says
> 
> <<You obviously must know better. The postcondition, if it
> needs to be expressed, is something like "string XXX" [the
> argument to the routine] "has been appended to the output".
> With the proper model this is easy to express formally.>>
> 
> But that's the whole point. Sure you can write a (pretty useless)
> postcondition after
> 
> print ("this is my useless error message");
> 
> to make sure you have added that string to the output file, but that tests
> only whether your code is working, not whether it meets the specification,
> which was to produce intelligible error messages. And I do not know what
> you mean by "know better". If you mean do I know perfectly well that
> postconditions cannot capture this kind of specification, yes, I know
> that perfectly well -- many specifications and requirements cannot be
> formalized in any useful manner.

But who should be resposible for the error message? You have a choice
between client of print and print itself.

The answer must be the client, because as the client, I may want to
handle errors in different ways. Pop up a window, or print to a console
window as two reasonable examples.

So having a postcondition that checks to see that the string has been
added to the output condition is fine, tells me something about what the
routine does, and acts as a check that it does the work.

Producing an error message is not print's problem. Lets say there are
preconditions of 1) the file being open for writing, and 2) the string
not being void (C++ null). Either being false when you call print is an
error, and will raise an exception, which can be caught, or you can
check before you call the routine if you cannot tell at compile time,
for example because the string came from some user input.

So as a result you have to have checks in the client. 

However if I write print ("Cest un crado error") you may complain that
it is an intelligible error message. OK, it may be for you. But if you
cannot express specifications and requirements in code, how can you
write a system? 

Take the example of useability. What 'exactly' does it mean? How do you
measure it? At the end of the day you have to write something which is
decomposing 'useablility' into code. I don't see why you can do the same
with DBC. Although, you may omit some of the checks for pragmatic
reasons.

For another example. I write software for a bank. A requirement is that
we help prevent the bank going bust. A very valid requirement. However,
this is a very woolly spec, and needs to be decomposed into smaller,
manageable requirements.


-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Nick Leaton wrote:
> However if I write print ("Cest un crado error") you may complain that
> it is an intelligible error message. OK, it may be for you. But if you
> cannot express specifications and requirements in code, how can you
> write a system?
> 
> Take the example of useability. What 'exactly' does it mean? How do
> you
> measure it? At the end of the day you have to write something which is
> decomposing 'useablility' into code. I don't see why you can do the
> same
> with DBC. Although, you may omit some of the checks for pragmatic
> reasons.

That's exactly what's being done - such assertions are written as
comments (which doesn't mean they don't bind the caller or the routine).
Though stuff like usability is difficult to express even as a comment
that's better than "this routine is user-friendly" - no wonder usability
labs are in existence.

> For another example. I write software for a bank. A requirement is
> that
> we help prevent the bank going bust. A very valid requirement.
> However,
> this is a very woolly spec, and needs to be decomposed into smaller,
> manageable requirements.

Same case as above.

Such assertions go to the currently perceived top-level function of the
system. In practice, the top-level function isn't too important (it will
change as soon as we go from batch to interactive, add another service
to the system, etc. etc. ...) If the top-level function is unimportant,
so are its assertions :)

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33FAB260.7E0CD1D1@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> Robert Dewar wrote:
> > [...some BM stuff...]
> > you mean by "know better". If you mean do I know perfectly well that
> > postconditions cannot capture this kind of specification, yes, I know
> > that perfectly well -- many specifications and requirements cannot be
> > formalized in any useful manner.

What's really odd here is that BM does not give the impression that he
understands this point.  Go figure.


> But who should be resposible for the error message? You have a choice
> between client of print and print itself.

Hint: it is not the dichotomy as you suggest.


> The answer must be the client, because as the client, I may want to
> handle errors in different ways. Pop up a window, or print to a console
> window as two reasonable examples.

That's not the point.  The point is, what is expressed via the
_mechanisms_ you suggest.  This latter depends largely on the context
of who/what is using the system (client and print together).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Jon S Anthony wrote:

> > Robert Dewar wrote:
> > > [...some BM stuff...]
> > > you mean by "know better". If you mean do I know perfectly well that
> > > postconditions cannot capture this kind of specification, yes, I know
> > > that perfectly well -- many specifications and requirements cannot be
> > > formalized in any useful manner.
> 
> What's really odd here is that BM does not give the impression that he
> understands this point.  Go figure.

I think he does. I read a least one message in the last two days by BM
where he makes this point. Reiterating a point I have made else where.
In what cases does DBC detract from a solution?

> > But who should be resposible for the error message? You have a choice
> > between client of print and print itself.
> 
> Hint: it is not the dichotomy as you suggest.

OK, If I don't have a print system where I can have resposibility as a
client I have a problem. I must have DBC.  Now if you are saying that I
some cases I don't want to bother, which isn't an unreasonable in the
case of print, I agree. In this case a default handler makes sense, but
this is just being nice. You must be able to take the DBC route with the
client accepting responsibility.

> > The answer must be the client, because as the client, I may want to
> > handle errors in different ways. Pop up a window, or print to a console
> > window as two reasonable examples.
> 
> That's not the point.  The point is, what is expressed via the
> _mechanisms_ you suggest.  This latter depends largely on the context
> of who/what is using the system (client and print together).

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Robert Dewar wrote:
> 
> pragma Assert (programmer now understands what they did wrong);
> 
> You need a *really* clever language to test that one (well I suppose the
> assertion routine executed at runtime could ask the programmer whether
> he understood :-)

No, you just need to code this in a top-level abstraction :)

Re: Safety-critical development in Ada and Eiffel

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>What should be the post condition after outputting an error message
>from a compiler?

>pragma Assert (programmer now understands what they did wrong);

>You need a *really* clever language to test that one (well I suppose the
>assertion routine executed at runtime could ask the programmer whether
>he understood :-)

That won't do as a postcondition for error messages.
One of my all-time favourite error messages came from the Burroughs
ESPOL compiler:

    "If you know what it means, implement it."

Such a message does not imply that the programmer did anything wrong at all.
(Although it _usually_ meant that.)

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <33EFCCE4.4CE0@flash.net>, kennieg@flash.net says...

>Leaving out executable assertions is just as easy as leaving out
>non-executable ones, isn't it?

Yes, but once they are in there, they are checked against the code.

>> A mature software process can also use this property by tracking assertion
>> failures and using them to monitor and improve inspection procedures.
>
>Is there a systematic method for reviewing code to determine if the
>right number and type of assertions have been added? 

Yes.  The assertions should express the requirements that the rest of the
system has for the class.  A class with no assertions basically promises
to take any input and either do something or nothing.

(Aside: it puts me in mind of a company prospectus from the South Sea
Bubble: "An undertaking of great advantage, but nobody to know what it is".)

The client code can be checked against the assertions: if the client
relies on undocumented (i.e. unasserted) behaviour then it is at fault.
On the other hand if the supplier class fails to promise anything useful
then its a useless piece of code anyway, and can be rejected on those
grounds.  The whole point is to document the interface, and then check
the documentation for correctness.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
> The client code can be checked against the assertions: if the client
> relies on undocumented (i.e. unasserted) behaviour then it is at fault.
> On the other hand if the supplier class fails to promise anything useful
> then its a useless piece of code anyway, and can be rejected on those
> grounds.  The whole point is to document the interface, and then check
> the documentation for correctness.

Against what? All you have is the code and the assertions created as
part
of the code. Checking them against each other determines internal
consistency between the two, but that's all. Based on the studies I've
seen, most errors aren't to pure internal inconsistencies at the code
level.

It's difficult to explain a software methodology to someone who only
sees
one step: coding. I'd have to type in several pages worth of software
engineering textbook to even try. So (and I hate this phrase!) we'll
just
have to agree to disagree.

> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Paul Johnson]

In article <33F25AA5.49ED@flash.net>, kennieg@flash.net says...
>
>Paul Johnson wrote:

>> The whole point is to document the interface, and then check
>> the documentation for correctness.
>
>Against what? All you have is the code and the assertions created as
>part
>of the code. Checking them against each other determines internal
>consistency between the two, but that's all.

Its a pretty big "all".  Such an inconsistency points to an error
either in the documentation or the code.  Then you can go and figure
out which one is wrong.

>Based on the studies I've
>seen, most errors aren't to pure internal inconsistencies at the code
>level.

I have some difficulty parsing that.  I take it you mean that most
errors in software are not due to inconsistencies in the code.  So what?
Most development systems do not include automatic checking of the
documentation.  This is design-level stuff, not code level.

>It's difficult to explain a software methodology to someone who only
>sees one step: coding.

Please don't talk down to me: you'll only miss.

Try thinking of Eiffel as a software engineering notation, rather than
just a programming language.  Its features allow the code to 
capture information about the analysis, design and implementation.  This
information is kept in one place, in one format and hence can be
checked for consistency.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Paul Johnson wrote:
> 
> In article <33F25AA5.49ED@flash.net>, kennieg@flash.net says...
> >
> >Paul Johnson wrote:
> 
> >> The whole point is to document the interface, and then check
> >> the documentation for correctness.
> >
> >Against what? All you have is the code and the assertions created as
> >part
> >of the code. Checking them against each other determines internal
> >consistency between the two, but that's all.
> 
> Its a pretty big "all".  Such an inconsistency points to an error
> either in the documentation or the code.  Then you can go and figure
> out which one is wrong.
> 
> >Based on the studies I've
> >seen, most errors aren't to pure internal inconsistencies at the code
> >level.
> 
> I have some difficulty parsing that.  I take it you mean that most
> errors in software are not due to inconsistencies in the code.  So what?

So, (a) that's where the difficult part lies and (b) it means a
methodology
that focuses on code inconsistency is not working the difficult part.

> Most development systems do not include automatic checking of the
> documentation.  This is design-level stuff, not code level.

That's why automated checking should not be relied upon to find
the hard errors. 

> 
> >It's difficult to explain a software methodology to someone who only
> >sees one step: coding.
> 
> Please don't talk down to me: you'll only miss.
> 
> Try thinking of Eiffel as a software engineering notation, rather than
> just a programming language.  Its features allow the code to
> capture information about the analysis, design and implementation.  This
> information is kept in one place, in one format and hence can be
> checked for consistency.

Again: You need to have experience in systems analysis and requirements
capture to understand that the hard stuff is not readily expressible
in code. This isn't talking down to you, it's just that you don't
apparently have experience in this area. This issue is described further
in:

  http://www.flash.net/~kennieg/ariane.html

> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
> +44 1245 242244         +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> > ...most
> > errors in software are not due to inconsistencies in the code.
> 
> So, (a) that's where the difficult part lies

Agreed.

> and (b) it means a
> methodology
> that focuses on code inconsistency is not working the difficult part.

The issue is that DBC allows to integrate code and code documentation
better. It is possible to write top-level abstract classes that just
encapsulate a few assertions; there is no need to duplicate these
assertions in other documents, at Eiffel (at this level) is easy to read
even for a non-programmer.

> > Try thinking of Eiffel as a software engineering notation, rather
> > than just a programming language.  Its features allow the code to
> > capture information about the analysis, design and implementation.
> > This information is kept in one place, in one format and hence can
> > be checked for consistency.
> 
> Again: You need to have experience in systems analysis and
> requirements
> capture to understand that the hard stuff is not readily expressible
> in code.

Eiffel assertions are *not* code. They are specifications for code.
 Some of these specifications happen to be checkable at run-time, so
they take the form of executable expressions instead of comments, but
that's a secondary issue.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> > > ...most
> > > errors in software are not due to inconsistencies in the code.
> >
> > So, (a) that's where the difficult part lies
> 
> Agreed.
> 
> > and (b) it means a
> > methodology
> > that focuses on code inconsistency is not working the difficult part.
> 
> The issue is that DBC allows to integrate code and code documentation
> better. It is possible to write top-level abstract classes that just
> encapsulate a few assertions; there is no need to duplicate these
> assertions in other documents, at Eiffel (at this level) is easy to read
> even for a non-programmer.

To demonstrate the problem, attempt to encode the critical Ariane 5
assumption as a "top-level abstract class." It is not directly
representable
as code, even as a "top-level" abstraction.

Said another way, could you write "War and Peace" as a "top-level"
abstraction?

> 
> > > Try thinking of Eiffel as a software engineering notation, rather
> > > than just a programming language.  Its features allow the code to
> > > capture information about the analysis, design and implementation.
> > > This information is kept in one place, in one format and hence can
> > > be checked for consistency.
> >
> > Again: You need to have experience in systems analysis and
> > requirements
> > capture to understand that the hard stuff is not readily expressible
> > in code.
> 
> Eiffel assertions are *not* code. They are specifications for code.
>  Some of these specifications happen to be checkable at run-time,

Read both of these statements carefully, several times.
That, coupled with the experiment I describe above, should demonstrate
the problem with your thinking.


> so
> they take the form of executable expressions instead of comments, but
> that's a secondary issue.
> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

> To demonstrate the problem, attempt to encode the critical Ariane 5
> assumption as a "top-level abstract class." It is not directly
> representable
> as code, even as a "top-level" abstraction.

But neither are any of the specs you have for a fighter aircraft. Just
as you have to decompose your code, you have to decompose you assertions
or specifications. Just because you can't write
'fly plane' and be done with it in Eiffel (or Ada) it doesn't make DBC
wrong.

> Said another way, could you write "War and Peace" as a "top-level"
> abstraction?

Ok.

A hit B and made up.

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Nasser]

In article <33FAB35A.18AA15BB@calfp.co.uk>, Nick says...
>
>> Said another way, could you write "War and Peace" as a "top-level"
>> abstraction?
>
>Ok.
>
>A hit B and made up.
>

I dont think This is abstract enough. too much detailes exposed 
to the client. How about representing "war" and "peace" as object instances of
abstract class "Mixed feelings" , and the "making up" part  is a method 
implemented as a generic instantiation of some "human act <>" function?

I think you'll agree this is more abstract than "A hit B and make up" .

Nasser

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33FAB35A.18AA15BB@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> > To demonstrate the problem, attempt to encode the critical Ariane 5
> > assumption as a "top-level abstract class." It is not directly
> > representable
> > as code, even as a "top-level" abstraction.
> 
> But neither are any of the specs you have for a fighter

That's OK, Ken is not the one claiming that this can be done.  Meyer
and the E-Jihad are the ones making this fatuous claim.


> aircraft. Just as you have to decompose your code, you have to
> decompose you assertions or specifications. Just because you can't
> write 'fly plane' and be done with it in Eiffel (or Ada) it doesn't
> make DBC wrong.

Spoken like a true reductionist.  This is not a decomposition problem.
I tried to point this out before when I spoke about how this problem
is the direct analogue of the problem of "natural kinds" in knowlege
representation.  You can't come up with contextually independent
necessary and sufficient conditions for a definition for these things.
But that is basically what you are trying to claim _is_ possible.


> > Said another way, could you write "War and Peace" as a "top-level"
> > abstraction?
> 
> Ok.
> 
> A hit B and made up.

Not even close, :-)

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Jon S Anthony wrote:
> 
> In article <33FAB35A.18AA15BB@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> 
> > > To demonstrate the problem, attempt to encode the critical Ariane 5
> > > assumption as a "top-level abstract class." It is not directly
> > > representable
> > > as code, even as a "top-level" abstraction.
> >
> > But neither are any of the specs you have for a fighter
> 
> That's OK, Ken is not the one claiming that this can be done.  Meyer
> and the E-Jihad are the ones making this fatuous claim.
> 
> > aircraft. Just as you have to decompose your code, you have to
> > decompose you assertions or specifications. Just because you can't
> > write 'fly plane' and be done with it in Eiffel (or Ada) it doesn't
> > make DBC wrong.
> 
> Spoken like a true reductionist.  This is not a decomposition problem.
> I tried to point this out before when I spoke about how this problem
> is the direct analogue of the problem of "natural kinds" in knowlege
> representation.  You can't come up with contextually independent
> necessary and sufficient conditions for a definition for these things.
> But that is basically what you are trying to claim _is_ possible.

OK, so if you can't write such requirements in a rigorous way, how can
you write the application. If you can write an application that meets
the requirements, you can write a coded spec for the problem. In the
extreme case, the code for the application is the specification. If you
cannot code the spec/requirements you can't check that they work. Just
because you have a deficient spec, or because you cannot envision what a
set of DBC assertions are for a problem doesn't detract from DBC.



> > > Said another way, could you write "War and Peace" as a "top-level"
> > > abstraction?
> >
> > Ok.
> >
> > A hit B and made up.
> 
> Not even close, :-)


Unfortunately, it takes up more characters than 'War and Peace' !

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Nick Leaton wrote:
> 
> OK, so if you can't write such requirements in a rigorous way, how can
> you write the application. If you can write an application that meets
> the requirements, you can write a coded spec for the problem. In the
> extreme case, the code for the application is the specification.

Welcome to the Ariane IV problem!

The code is an _implementation_ of the specification. Except for trivial
cases, it is not the _only_ implementation. Furthermore, the
specification
can state things not related to the implementation -- in particular, the
assumptions of the physical environment -- at a level that can be (a)
subjective and (b) non-implementable as code. The code still works,
since
it doesn't have to encode such assumptions.

> If you
> cannot code the spec/requirements you can't check that they work. Just
> because you have a deficient spec, or because you cannot envision what a
> set of DBC assertions are for a problem doesn't detract from DBC.

Being able to implement a spec, and being able to test the
implementation,
is not the same as saying that the code can replace the spec. This is
a lesson learned from Ariane. For more information, read my paper (or
the inquiry report, referenced from that paper).

> 
> --
> 
> Nick

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> > The issue is that DBC allows to integrate code and code
> documentation
> > better. It is possible to write top-level abstract classes that just
> > encapsulate a few assertions; there is no need to duplicate these
> > assertions in other documents, at Eiffel (at this level) is easy to
> read
> > even for a non-programmer.
> 
> To demonstrate the problem, attempt to encode the critical Ariane 5
> assumption as a "top-level abstract class." It is not directly
> representable
> as code, even as a "top-level" abstraction.
> 
> Said another way, could you write "War and Peace" as a "top-level"
> abstraction?

People keep mixing the documentation aspects and the run-time checking
aspects of Eiffel assertions.

Assertions as documentation *need not be executable* (so there is no
problem encoding the critical Ariane-5 conditions or even War and Peace
as a precondition).
Assertions for run-time checking must be executable, of course. But even
these double up as documentation on the routine.

At its first stage, Design by Contract is just a discipline: write down
the preconditions and postconditions of the routine. Make sure the
preconditions and postconditions match what the routine does (easy, the
assertions are in the vicinity anyway). Have them stand out clearly via
keywords so that the "short" tool can create a documentation that
contains the routine signature with their pre- and postconditions.

The next level is that some assertions may be executable. This allows
run-time checking, and (more important) it encourages the programmer to
actually make assertions and code consistent. Even the non-executable
ones - anybody with some practice in getting the checkable assertions
right will have no trouble putting down precise non-executable
assertions.

> > > Again: You need to have experience in systems analysis and
> > > requirements
> > > capture to understand that the hard stuff is not readily
> > > expressible in code.
> >
> > Eiffel assertions are *not* code. They are specifications for code.
> >  Some of these specifications happen to be checkable at run-time,
> 
> Read both of these statements carefully, several times.
> That, coupled with the experiment I describe above, should demonstrate
> the problem with your thinking.

They don't. Either you don't understand me, or I don't understand you.
(BTW which two statements do you mean?)

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> > > The issue is that DBC allows to integrate code and code
> > documentation
> > > better. It is possible to write top-level abstract classes that just
> > > encapsulate a few assertions; there is no need to duplicate these
> > > assertions in other documents, at Eiffel (at this level) is easy to
> > read
> > > even for a non-programmer.
> >
> > To demonstrate the problem, attempt to encode the critical Ariane 5
> > assumption as a "top-level abstract class." It is not directly
> > representable
> > as code, even as a "top-level" abstraction.
> >
> > Said another way, could you write "War and Peace" as a "top-level"
> > abstraction?
> 
> People keep mixing the documentation aspects and the run-time checking
> aspects of Eiffel assertions.
> 
> Assertions as documentation *need not be executable* (so there is no
> problem encoding the critical Ariane-5 conditions or even War and Peace
> as a precondition).
> Assertions for run-time checking must be executable, of course. But even
> these double up as documentation on the routine.
> 
> At its first stage, Design by Contract is just a discipline: write down
> the preconditions and postconditions of the routine. Make sure the
> preconditions and postconditions match what the routine does (easy, the
> assertions are in the vicinity anyway). Have them stand out clearly via
> keywords so that the "short" tool can create a documentation that
> contains the routine signature with their pre- and postconditions.
> 
> The next level is that some assertions may be executable. This allows
> run-time checking, and (more important) it encourages the programmer to
> actually make assertions and code consistent. Even the non-executable
> ones - anybody with some practice in getting the checkable assertions
> right will have no trouble putting down precise non-executable
> assertions.
> 
> > > > Again: You need to have experience in systems analysis and
> > > > requirements
> > > > capture to understand that the hard stuff is not readily
> > > > expressible in code.
> > >
> > > Eiffel assertions are *not* code. They are specifications for code.
> > >  Some of these specifications happen to be checkable at run-time,
> >
> > Read both of these statements carefully, several times.
> > That, coupled with the experiment I describe above, should demonstrate
> > the problem with your thinking.
> 
> They don't. Either you don't understand me, or I don't understand you.
> (BTW which two statements do you mean?)

Simple: You can't have it both ways, You claim that Eiffel assertions
are
superior because they're executable, while simultaneously claiming they
are
not executable code. Specifically (quoting you):

  1. "Eiffel assertions are *not* code. They are specifications for
code."
  2. "Some of these specifications happen to be checkable at
run-time..."

Which ever way you go, you have a downside by your own
arguments (executable assertions are limiting; non-executable ones can't
be tested during execution). You can't claim the advantages of each
without
also claiming the disadvantages. It's an interesting dance you're doing,
but you will bump into a wall whichever way you jump.

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote (with deletions):

:Don Harrison wrote:

[...]

:> No. If an error doesn't exist, it can't be ported.
:
:Consider the Ariane case. The error didn't exist in the original
:environment
:(Ariane IV). The error only occured during execution in the Ariane 5
:environment (a little too late to fix, unfortunately). Basing your
:argument
:on execution means that any latent error in the system, which might be
:caught in other methodologies through the use of analysis and reviews,
:will
:be missed using DBC/Eiffel.

I disagree. I'll explain below..

[...]

:> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
:> :> "Accessing separate objects", Page 982 ff.)
:> :>
:> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
:> :> To overcome this deficiency, you have to either roll-your-own object protection
:> :> (using semaphores, for example) or use protected objects. Using Ada protected
:> :> objects is fine, but they lack the flexibility of Eiffel separate objects.
:> :
:> :Just the opposite!
:> 
:> Incorrect.
:
:Eiffel separate objects always lock the object. Ada protected records
:can lock the
:object for a given operation or not (at the designer's preference), 

IMO, this is something the designer is better off leaving to the compiler as 
it can be expected to do a better job of it. If Ada protected types allow 
the designer to explicitly leave objects unlocked (which doesn't appear to 
be supported by the Ada95 Rationale), then they are more permissive but 
in a detrimental way, IMO.

:can requeue requests, 

IMO, the situations in which you would use "requeue" are better handled by 
designing differently - perhaps by using an additional class. If anything,
"requeue" probably encourages poor design.

:etc. 

What are these?

More choices for the designer usually means additional
:flexibility, I would think.

Drawing some inspiration from Robert Dewar, "flexibility" and "permissiveness" 
have at their root the same meaning but differ wrt the user perceives a benefit 
or detriment respectively.

[...]

:> :Someone needs to decide if DBC is a coding guideline or a software
:> :development
:> :methodology. My concern is that it is touted as the former, but used as
:> :the latter.
:> 
:> I don't see any problem with using it as both.
:
:However, there is a serious problem when practitioners use it (and
:discuss it) in terms of the former. Note the number of times in this
:post, for example, that DBC has been described in terms of concrete
:capabilities when the subject is code execution, but only vaguely
:(if at all) when described as a methodology..

Your basic worry seems to be that DBC doesn't appear to be an all-embracing, 
formal software engineering methodology.

At this stage, I think you're right. I think the reason why is that DBC 
probably hasn't been used in the context of *formal* software engineering. 
If it had, then it would have been integrated with other complementary 
reliability-enhancing techniques. 

IMO, a methodology centred on DBC, would also include stuff about systematic
testing of components. In the Ariane case, this might involve bolting an IRS
onto some test bench and stimulating it with Ariane 5 data. This may require
simulating the surrounding environment. Then, any assertions assuming Ariane 4 
inputs would be violated (as would the Ada constraint_error). In general, 
the extra checking afforded by DBC would mean more bugs would be identified 
than if it wasn't used. (Yes, I know there is no difference wrt the one that 
caused the failure.)

[...]

:> :So, I'm still at a loss to
:> :see what DBC brings to the table here. It doesn't address my main
:> :problem (requirements/design faults),
:> 
:> Not entirely true. DBC can highlight specification/design inconsistencies.
:> (See my previous posts). Otherwise, I agree.
:
:I saw your previous posts. I quote from the line above:
:
:  "WRT documentation-related problems, these are outside the scope of
:  any runtime error checking mechanism. DBC is *almost* a silver bullet
:  but not quite."

Right person, wrong quote and wrong context. If it's any help to you, the 
comments I'm referring to were about mutually validating requirements. I 
acknowledged not all documentation errors were covered. 

[...]

:> :it's not clear that it scales well,
:> 
:> Not true.
:
:Can you provide evidence to the contrary?

I've already covered this. Nick's experience also endorses it.

[...]

:> :and not much on what to do after the error is detected, for example).
:> 
:> Again, this is usually blindingly obvious.
:> 
:Any time someone says something is obvious, without any evidence or
:argument to support it, I pretty much assume that the point is ceded.

No, it just means I'm just getting impatient. :(
 

Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EEsF5y.F5H@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> it can be expected to do a better job of it. If Ada protected types allow 
> the designer to explicitly leave objects unlocked (which doesn't appear to 
> be supported by the Ada95 Rationale), then they are more permissive but 
> in a detrimental way, IMO.

You're not twigging this stuff.  The objects can be unlocked for
_read_ access, but never for any update access.  Now you can make a
value judgement that this is worthless or misguided, but that's
different.


> :can requeue requests, 
> 
> IMO, the situations in which you would use "requeue" are better handled by 
> designing differently - perhaps by using an additional class. If anything,
> "requeue" probably encourages poor design.

Requeue is specifically there to eliminate in principle any timing
errors.  The way this works is somewhat subtle, so maybe you are not
twigging this either.


> simulating the surrounding environment. Then, any assertions
> assuming Ariane 4 inputs would be violated (as would the Ada
> constraint_error). In general, the extra checking afforded by DBC
> would mean more bugs would be identified than if it wasn't
> used. (Yes, I know there is no difference wrt the one that caused
> the failure.)

The problem with this is the simple observation of "why would the
assertions be there in the first place?"  After all, in the particular
case at hand, they were _intentionally_ removed.  And with perfectly
sound engineering principles in mind.  Assertions in the code _cannot_
capture the constraints presumed for the context of use.  This has to
come from somewhere else (external documentation, "instructions",
"warrenty notes", whatever.)  The odd thing here is that this point
should be "blindingly obvious", to use one of your phrases.

> :Any time someone says something is obvious, without any evidence or
> :argument to support it, I pretty much assume that the point is ceded.
> 
> No, it just means I'm just getting impatient. :(

Same here - In SPADES.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Jon S Anthony wrote:

:In article <EEsF5y.F5H@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> it can be expected to do a better job of it. If Ada protected types allow 
:> the designer to explicitly leave objects unlocked (which doesn't appear to 
:> be supported by the Ada95 Rationale), then they are more permissive but 
:> in a detrimental way, IMO.
:
:You're not twigging this stuff.  

Possibly. 

:The objects can be unlocked for
:_read_ access, but never for any update access.  

Care to give an example?


:> :can requeue requests, 
:> 
:> IMO, the situations in which you would use "requeue" are better handled by 
:> designing differently - perhaps by using an additional class. If anything,
:> "requeue" probably encourages poor design.
:
:Requeue is specifically there to eliminate in principle any timing
:errors.  The way this works is somewhat subtle, so maybe you are not
:twigging this either.

On re-reading the Ada95 Rationale, I think I have a handle on this now.
(See my response to Ken.)


:> simulating the surrounding environment. Then, any assertions
:> assuming Ariane 4 inputs would be violated (as would the Ada
:> constraint_error). In general, the extra checking afforded by DBC
:> would mean more bugs would be identified than if it wasn't
:> used. (Yes, I know there is no difference wrt the one that caused
:> the failure.)
:
:The problem with this is the simple observation of "why would the
:assertions be there in the first place?"  After all, in the particular
:case at hand, they were _intentionally_ removed.  And with perfectly
:sound engineering principles in mind.  Assertions in the code _cannot_
:capture the constraints presumed for the context of use.  This has to
:come from somewhere else (external documentation, "instructions",
:"warrenty notes", whatever.)  The odd thing here is that this point
:should be "blindingly obvious", to use one of your phrases.

Yes, I agree it is. I'm talking about (an aspect of) how I think it *ought* to
be done, not how it *was* done. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EEuDC9.MtH@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> :The problem with this is the simple observation of "why would the
> :assertions be there in the first place?"  After all, in the particular
> :case at hand, they were _intentionally_ removed.  And with perfectly
> :sound engineering principles in mind.  Assertions in the code _cannot_
> :capture the constraints presumed for the context of use.  This has to
> :come from somewhere else (external documentation, "instructions",
> :"warrenty notes", whatever.)  The odd thing here is that this point
> :should be "blindingly obvious", to use one of your phrases.
> 
> Yes, I agree it is. I'm talking about (an aspect of) how I think it
> *ought* to be done, not how it *was* done.

The point is, the significant aspect of your "how it ought to be done"
is _impossible_.  Not just wasn't done, not just impractical, but
outright impossible.

However, you and the E-Jihad have succeeded in wearing me down.  I
give up.  The whole thing is pointless.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Jon S Anthony wrote:

:In article <EEuDC9.MtH@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> :The problem with this is the simple observation of "why would the
:> :assertions be there in the first place?"  After all, in the particular
:> :case at hand, they were _intentionally_ removed.  And with perfectly
:> :sound engineering principles in mind.  Assertions in the code _cannot_
:> :capture the constraints presumed for the context of use.  This has to
:> :come from somewhere else (external documentation, "instructions",
:> :"warrenty notes", whatever.)  The odd thing here is that this point
:> :should be "blindingly obvious", to use one of your phrases.
:> 
:> Yes, I agree it is. I'm talking about (an aspect of) how I think it
:> *ought* to be done, not how it *was* done.
:
:The point is, the significant aspect of your "how it ought to be done"
:is _impossible_.  Not just wasn't done, not just impractical, but
:outright impossible.

But, perhaps, nowhere near as impossible as acheiving a mutual understanding 
as to what would and wouldn't have helped?  :)

:However, you and the E-Jihad have succeeded in wearing me down.  I
:give up.  The whole thing is pointless.

How disappointing.  :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EExM7r.BLA@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> :The point is, the significant aspect of your "how it ought to be done"
> :is _impossible_.  Not just wasn't done, not just impractical, but
> :outright impossible.
> 
> But, perhaps, nowhere near as impossible as acheiving a mutual
> understanding as to what would and wouldn't have helped?  :)

Unlikely.  At least such an understanding is _logically_ possible (in
the formal sense of the term).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Samuel Mize]

Don Harrison wrote:
> 
> Jon S Anthony wrote:
[about Ada protected objects]
> :The objects can be unlocked for
> :_read_ access, but never for any update access.
> 
> Care to give an example?

"Locked" is a common term, but its application to Ada is not
defined by the Ada Reference Manual (ARM), so it may be
unclear or accidentally misleading.

The ARM refers to protected operations being "blocked" if they
cannot "acquire" the "execution resource associated with a
protected object" (ARM 9.4(18)).

"Protected procedures provide exclusive read-write access to ...
a protected object; protected functions provide concurrent
read-only access" (ARM 9.5.1 (1)).  For one protected object,
"a new protected action is not started ... while another ...
is underway, unless both actions are the result of a call on
a protected function." (ARM 9.5.1(4)).

In other words, a protected object can have functions and
procedures (treating entries are a type of procedure).  A
procedure can't start while a function is executing, but a
function can; nothing else can start while a procedure is
executing.

During an operation on the object that can change its value
(a procedure), you can't "unlock" the object for others to
read.  However, an operation that can't change the object's
value (a function) does NOT acquire an exclusive lock, just
a read lock.

Sam Mize

Re: Safety-critical development in Ada and Eiffel

[Robert A Duff]

In article <33F20113.738F@link.com>, Samuel Mize  <smize@link.com> wrote:
>Don Harrison wrote:
>> 
>> Jon S Anthony wrote:
>[about Ada protected objects]
>> :The objects can be unlocked for
>> :_read_ access, but never for any update access.
>> 
>> Care to give an example?
>
>"Locked" is a common term, but its application to Ada is not
>defined by the Ada Reference Manual (ARM), so it may be
>unclear or accidentally misleading.

>The ARM refers to protected operations being "blocked" if they
>cannot "acquire" the "execution resource associated with a
>protected object" (ARM 9.4(18)).

No, that's not how the RM defines "blocked".  A task is blocked when it
is sitting on an entry queue, waiting for the barrier to become true,
and in various other situations, but it is not considered blocked when
it is waiting for the lock on a protected object.  It does have to wait
for the lock, of course, but we don't call that state "blocked".

To answer Don's question: protected objects can be locked for read-only
access, or for read-write access.  Read-only access does not exclude
other readers.

The Ada folks seem to be missing Don's earlier point, which is that in
Eiffel you can lock a bunch of objects all at once, whereas in Ada, you
lock just one object at a time (that is, a protected operation X.Op(Y, Z)
locks X, but not Y and Z (in Ada).

>In other words, a protected object can have functions and
>procedures (treating entries are a type of procedure).

The difference between protected procedures and entries is that entries
can "block" (in the Ada RM sense), whereas protected procedures cannot.

- Bob

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EEvAnx.281@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> The Ada folks seem to be missing Don's earlier point, which is that in
> Eiffel you can lock a bunch of objects all at once, whereas in Ada, you

I don't think people are missing this point at all.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Bob Duff wrote:

:To answer Don's question: protected objects can be locked for read-only
:access, or for read-write access.  Read-only access does not exclude
:other readers.
:
:The Ada folks seem to be missing Don's earlier point, which is that in
:Eiffel you can lock a bunch of objects all at once, whereas in Ada, you
:lock just one object at a time (that is, a protected operation X.Op(Y, Z)
:locks X, but not Y and Z (in Ada).

Thanks (on both counts).


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Bob Duff wrote:
> 
> :To answer Don's question: protected objects can be locked for read-only
> :access, or for read-write access.  Read-only access does not exclude
> :other readers.
> :
> :The Ada folks seem to be missing Don's earlier point, which is that in
> :Eiffel you can lock a bunch of objects all at once, whereas in Ada, you
> :lock just one object at a time (that is, a protected operation X.Op(Y, Z)
> :locks X, but not Y and Z (in Ada).
> 
> Thanks (on both counts).

Actually, this was the source of my concern (automatic locking of all
objects
accessed, vs. per-operation locking). However, since this locking is not
exactly "automatic" (the "dueling" concept can be used to overcome it),
my
concern now is more in terms of

  1. having this part of the system design spread out amongst the
threads,
     instead of a more object-oriented style of containing it within the
     protected object, and

  2. the compiler complexity required to optimize "benign" calls to
avoid
     locks on a given operation in the first place.

Don doesn't see the first issue as a design problem, and doesn't see the
second issue as a difficult compiler problem. We'll have to wait for
implementations to appear to determine who's right, I guess.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Jon S Anthony wrote:
> 
> The problem with this is the simple observation of "why would the
> assertions be there in the first place?"  After all, in the particular
> case at hand, they were _intentionally_ removed.  And with perfectly
> sound engineering principles in mind.  Assertions in the code _cannot_
> capture the constraints presumed for the context of use.  This has to
> come from somewhere else (external documentation, "instructions",
> "warrenty notes", whatever.) [...]
> 

There is an important distinction between including/removing assertions 
and monitoring/not monitoring them during execution.  One of the 
principal benefits of Eiffel is the fact that assertions remain in the 
code (where programmers will see them) even if they are not tested 
dynamically (this is controlled by a compile-time switch).  Whether or 
not this would have saved Ariane V, the documentation and testing 
benefits of Eiffel's assertions would benefit many, many software 
projects.

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33F133D7.71AC@erols.com> Ted Velkoff <velkoff@erols.com> writes:

> Jon S Anthony wrote:
> > 
> > The problem with this is the simple observation of "why would the
> > assertions be there in the first place?"  After all, in the particular
> > case at hand, they were _intentionally_ removed.  And with perfectly
> > sound engineering principles in mind.  Assertions in the code _cannot_
> > capture the constraints presumed for the context of use.  This has to
> > come from somewhere else (external documentation, "instructions",
> > "warrenty notes", whatever.) [...]
> > 
> 
> There is an important distinction between including/removing assertions 
> and monitoring/not monitoring them during execution.  One of the 
> principal benefits of Eiffel is the fact that assertions remain in the 
> code (where programmers will see them) even if they are not tested 
> dynamically (this is controlled by a compile-time switch).  Whether or 
> not this would have saved Ariane V, the documentation and testing 
> benefits of Eiffel's assertions would benefit many, many software 
> projects.

Nobody is saying that assertions are somehow bad or even that they are
somehow not particularly effective _when used where they can actually
say something about what it is you are trying to check_.  Assertions
in the code cannot address the constraints imposed by the intended
context of use.  That's a global multi system variability issue.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Ted Velkoff wrote:
> 
> There is an important distinction between including/removing assertions
> and monitoring/not monitoring them during execution.  One of the
> principal benefits of Eiffel is the fact that assertions remain in the
> code (where programmers will see them) even if they are not tested
> dynamically (this is controlled by a compile-time switch).  Whether or
> not this would have saved Ariane V, the documentation and testing
> benefits of Eiffel's assertions would benefit many, many software
> projects.

This is certainly reasonable. However, once the execution capabilities
are removed, it seems fair to ask what Eiffel provides that comments
(available in most langauges) don't provide. If there is not a
significant
difference, then Eiffel would not be any better (in this context) than
any other language, so long as the DBC principles were followed.

> 
> -- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Ken Garlington responded to an earlier post of mine:
> 
> This is certainly reasonable. However, once the execution capabilities
> are removed, it seems fair to ask what Eiffel provides that comments
> (available in most langauges) don't provide. If there is not a
> significant
> difference, then Eiffel would not be any better (in this context) than
> any other language, so long as the DBC principles were followed.
> 

In my experience, there is a significant difference.  I will not presume 
to make a scientific claim; rather I will offer a personal, anecdotal 
example.

About two years ago, I built a modest enhancement to a system which 
amounted to 4K lines each of Ada and C++.  In the package specs and 
module headers I included preconditions, postconditions and invariants 
as comments.  In the Ada bodies, I wrote if-then-else clauses to test 
preconditions (violations led to a chain of exceptions raised out to 
the main program).  In the C++ implementations, I included conditionally 
compiled calls to the assert macro (which does a core dump and spits out 
a file and line number) for preconditions and trivial 
postconditions.

This approach worked really well for me because I was very motivated and 
willing to do certain things.  Those things included: Step 1) write the 
assertions as comments in the specs; Step 2) update comments in the 
specs when testing revealed missing assertions (it's against the rules 
to introduce a precondition and not tell anyone about it - a contract 
with secret codicils, so to speak); Step 3) write the code to test the 
conditions, raise exceptions and generate a trace (in the Ada code).  

This approach was not without flaws:  Flaw 1) In the Ada code, for 
instance, there was no conditional compilation; to remove the assertion 
monitoring would have been a tedious exercise;  Flaw 2) I didn't even 
attempt to monitor postconditions - this is harder, even for simple ones 
(e.g. count = old count + 1); Flaw 3) as implied above, information had 
to be kept in synch in two places: the specs and bodies.

In my opinion, this won't scale up to a large team.  20% might see the 
benefit and be willing to do the many tedious manual tasks I described; 
20% will see no benefit, and even if they did, wouldn't do it; the other 
60% could be persuaded that it would help but wouldn't tolerate the 
extra upfront burden and wouldn't adopt it (in particular, steps 2 and 
3).  I should say I haven't tried it out on a team; this is pure 
conjecture.  (If anything, this appraisal is optimistic.)

Meanwhile at home I write software in Eiffel, where assertions are built 
into the language.  In Eiffel, all I do is Step 1: write the 
pre/post-conditions and invariants.  I don't need to do Step 2 (keep 
spec and body in synch) since in Eiffel, the spec (properly speaking, 
the short form) is automatically generated by tools.  Step 3, (coding 
the assertion tests, handling failures, providing useful diagnostics) is 
provided automatically by the environment.  Furthermore, the three flaws 
are eliminated: 1) with a compile-time switch I can turn off monitoring 
(I don't have to go through and "comment out" reams of code); 2) it's 
easy to monitor post-conditions, since this is provided by the tools 
(caveat - this is useful for testing and integration; postcondition 
monitoring necessarily incurs a performance penalty); 3) mentioned 
above, there is no spec/body redundancy to be managed by the programmer.

Returning to my view of scalability, I think the same 20% of 
programmers would love to work in a programming environment with these 
capabilities, 20% would still dislike it; but the other 60% - I think 
they would like it.  I say that because the cost/benefit is easier to 
see.  It doesn't take much time to write assertions, so when the rest 
comes for free (documentation and testing), programmers will want to 
write them.

Finally, I'll contrast Eiffel's assertions with comments (in any 
language).  I conjecture that because they can be monitored easily, 
Eiffel's assertions affect programmer psychology.  As a supplier, if I 
write postconditions or invariants as comments, I might be merely making 
promises.  If I know those assertions are easily monitored, I will be 
careful about what I promise: the auditor might show up at any minute.

I can imagine that Eiffel may not be suitable for certain real-time 
applications mentioned in this thread.  Nevertheless, I am convinced 
that a large number of software projects would benefit from employing 
"Design By Contract", and that Eiffel is the only language I know 
that makes its application practical and cost-effective 

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Matt Austern]

Ted Velkoff <velkoff@erols.com> writes:

> Meanwhile at home I write software in Eiffel, where assertions are built 
> into the language.  In Eiffel, all I do is Step 1: write the 
> pre/post-conditions and invariants.  I don't need to do Step 2 (keep 
> spec and body in synch) since in Eiffel, the spec (properly speaking, 
> the short form) is automatically generated by tools.  Step 3, (coding 
> the assertion tests, handling failures, providing useful diagnostics) is 
> provided automatically by the environment.  Furthermore, the three flaws 
> are eliminated: 1) with a compile-time switch I can turn off monitoring 
> (I don't have to go through and "comment out" reams of code); 2) it's 
> easy to monitor post-conditions, since this is provided by the tools 
> (caveat - this is useful for testing and integration; postcondition 
> monitoring necessarily incurs a performance penalty); 3) mentioned 
> above, there is no spec/body redundancy to be managed by the programmer.

Have preconditions and postconditions been extended in recent versions
of Eiffel?  I haven't yet read the second editon of Eiffel: The
Language yet, and I haven't used Eiffel for a year or so.  When I last
did, though, there were a number of restrictions on them.  I note
that, because of those restrictions, many of the interesting
preconditions and postconditions in ETL itself were written as
comments rather than as executable code.

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Matt Austern wrote:
> 
> Have preconditions and postconditions been extended in recent versions
> of Eiffel?  I haven't yet read the second editon of Eiffel: The
> Language yet, and I haven't used Eiffel for a year or so.  When I last
> did, though, there were a number of restrictions on them.  I note
> that, because of those restrictions, many of the interesting
> preconditions and postconditions in ETL itself were written as
> comments rather than as executable code.

You are correct that there are (still) limitations to the expressiveness 
of assertions.  In particular, one cannot write executable quantified 
expressions, e.g. "for_all x in y it_holds x.item > 0".  This would be a 
valuable capability indeed, since one could, for instance, compile 
(that is, type check) an analysis or design, including its assertions.

In my view, the fact that some kinds of assertions are not executable 
does not lesson the value of Eiffel.  I would hazard a guess that at 
least 75% to 80% of the assertions one would want to write are of the 
form that are supported.  For me, that is still a big gain.

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Matt Austern]

Ted Velkoff <velkoff@erols.com> writes:

> Matt Austern wrote:
> > 
> > Have preconditions and postconditions been extended in recent versions
> > of Eiffel?  I haven't yet read the second editon of Eiffel: The
> > Language yet, and I haven't used Eiffel for a year or so.  When I last
> > did, though, there were a number of restrictions on them.  I note
> > that, because of those restrictions, many of the interesting
> > preconditions and postconditions in ETL itself were written as
> > comments rather than as executable code.
> 
> You are correct that there are (still) limitations to the expressiveness 
> of assertions.  In particular, one cannot write executable quantified 
> expressions, e.g. "for_all x in y it_holds x.item > 0".  This would be a 
> valuable capability indeed, since one could, for instance, compile 
> (that is, type check) an analysis or design, including its assertions.
> 
> In my view, the fact that some kinds of assertions are not executable 
> does not lesson the value of Eiffel.  I would hazard a guess that at 
> least 75% to 80% of the assertions one would want to write are of the 
> form that are supported.  For me, that is still a big gain.

That hasn't been my experience: my experience, when I did use Eiffel,
was that most of the interesting preconditions, postconditions, and
invariants tended to be complicated enough that I couldn't express
them within the language itself.

For example, what's the postcondition for a function that sorts a
range?  Three postconditions, of course: the range is sorted, the
range has the same number of elements as it did before, and the new
range is a permutation of the old range. (Depending on the sorting
algorithm, you might also have a postcondition that guarantees
stability of equivalent elements.) It's the last one that's a problem;
I never did figure out how to write a postcondition like that in
Eiffel, and I as far as I know it isn't possible.

In every language, it's certainly important to document carefully what
a function requires and what it guarantees to do.  Eiffel is similar
to all other languages in that many of these requirements and
guarantees have to live in the documentation rather than in the code.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Matt Austern wrote:
> For example, what's the postcondition for a function that sorts a
> range?  Three postconditions, of course: the range is sorted, the
> range has the same number of elements as it did before, and the new
> range is a permutation of the old range. (Depending on the sorting
> algorithm, you might also have a postcondition that guarantees
> stability of equivalent elements.) It's the last one that's a problem;
> I never did figure out how to write a postcondition like that in
> Eiffel, and I as far as I know it isn't possible.

I wouldn't write any of these postconditions in Eiffel; I'd include them
in comments. The environment won't check these postconditions for me,
true - but I retain the documentation of the routine, at a place where
it is easily accessible.

> In every language, it's certainly important to document carefully what
> a function requires and what it guarantees to do.  Eiffel is similar
> to all other languages in that many of these requirements and
> guarantees have to live in the documentation rather than in the code.

Document non-executable stuff in comments. Have your documentation
generated automatically. No redundancy, documentation is easy to do
along with the formal specs (class interfaces) and/or the coding
(routines).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33FA3B0F.62780A5C@munich.netsurf.de> Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:

> Matt Austern wrote:
> > For example, what's the postcondition for a function that sorts a
> > range?  Three postconditions, of course: the range is sorted, the
> > range has the same number of elements as it did before, and the new
> > range is a permutation of the old range. (Depending on the sorting
> > algorithm, you might also have a postcondition that guarantees
> > stability of equivalent elements.) It's the last one that's a problem;
> > I never did figure out how to write a postcondition like that in
> > Eiffel, and I as far as I know it isn't possible.
> 
> I wouldn't write any of these postconditions in Eiffel; I'd include them
> in comments. The environment won't check these postconditions for me,
> true - but I retain the documentation of the routine, at a place where
> it is easily accessible.

So, how why write them in such a limited language (either Eiffel or
its assertion sublanguage).  What's the point?  Seems like if this is
your stance but you still want some formalism, you should write the
things in FOL.


> > In every language, it's certainly important to document carefully what
> > a function requires and what it guarantees to do.  Eiffel is similar
> > to all other languages in that many of these requirements and
> > guarantees have to live in the documentation rather than in the code.
> 
> Document non-executable stuff in comments. Have your documentation
> generated automatically. No redundancy, documentation is easy to do
> along with the formal specs (class interfaces) and/or the coding
> (routines).

Sounds OK (note that the non-executable stuff is typically the most
important in this sort of context).  Of course this is easily done in
any language...

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Jon S Anthony wrote:
>
> In article <33FA3B0F.62780A5C@munich.netsurf.de> Joachim Durchholz
> <joachim.durchholz@munich.netsurf.de> writes:
>
> > Document non-executable stuff in comments. Have your documentation
> > generated automatically. No redundancy, documentation is easy to do
> > along with the formal specs (class interfaces) and/or the coding
> > (routines).
> 
> Sounds OK (note that the non-executable stuff is typically the most
> important in this sort of context).  Of course this is easily done in
> any language...

Well, I'd like to actually see it in any other language. The obstacles
seem to be:
- Ignorance (DBC is quite new, I've been aware of it since just 5
years...)
- No conventions how and where the assertions should be written
- No binary formats that retain the assertions (this goes from object
formats to CORBA)
- It is serious work to write a "flat-short" tool that scans the
inheritance hierarchy and extracts all contracts

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Ted Velkoff wrote:
> 
> Ken Garlington responded to an earlier post of mine:
> >
> > This is certainly reasonable. However, once the execution capabilities
> > are removed, it seems fair to ask what Eiffel provides that comments
> > (available in most langauges) don't provide. If there is not a
> > significant
> > difference, then Eiffel would not be any better (in this context) than
> > any other language, so long as the DBC principles were followed.
> >
> 
> In my experience, there is a significant difference.  I will not presume
> to make a scientific claim; rather I will offer a personal, anecdotal
> example.
> 
> About two years ago, I built a modest enhancement to a system which
> amounted to 4K lines each of Ada and C++.  In the package specs and
> module headers I included preconditions, postconditions and invariants
> as comments.  In the Ada bodies, I wrote if-then-else clauses to test
> preconditions (violations led to a chain of exceptions raised out to
> the main program).  In the C++ implementations, I included conditionally
> compiled calls to the assert macro (which does a core dump and spits out
> a file and line number) for preconditions and trivial
> postconditions.

I think you're anwering the wrong mail :)

Please re-read the first paragraph. The discussion is about the value of
Eiffel assertions if they are _always_ turned off, vs. comments.

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Ken Garlington wrote:
> 
> Ted Velkoff wrote:
> >
> > Ken Garlington responded to an earlier post of mine:
> > >
> > > This is certainly reasonable. However, once the execution capabilities
> > > are removed, it seems fair to ask what Eiffel provides that comments
> > > (available in most langauges) don't provide. If there is not a
> > > significant
> > > difference, then Eiffel would not be any better (in this context) than
> > > any other language, so long as the DBC principles were followed.
> > >
> >
> > In my experience, there is a significant difference.  I will not presume
> > to make a scientific claim; rather I will offer a personal, anecdotal
> > example.
> >[ Example followed here...]
> 
> I think you're anwering the wrong mail :)

I'll try again.
> 
> Please re-read the first paragraph. The discussion is about the value of
> Eiffel assertions if they are _always_ turned off, vs. comments.

To begin with, by "_always_ turned off", I assume what is meant is 
"turned off during execution of a delivered system", not "turned off 
during execution of a delivered system and during its entire development 
phase".

If an Eiffel executable is built with assertion monitoring turned off, 
it is indeed no different than, say, an Ada executable built using 
pragma Suppress (Range_Check, for example).  This would be appropriate 
during the final stages of testing a product, for Factory/Site 
Acceptance Test, and delivery to a customer.

For the bulk of development, from design through code, unit and 
integration testing, one would certainly want to monitor assertions (in 
Eiffel) or Range_Checks, for instance (in Ada).  Clearly these sorts of 
compile- and run-time checks are far more powerful than mere comments 
and aid in earlier detection and correction of errors.  I say that using 
Eiffel is superior to using another language with commented assertions 
because Eiffel makes it so easy and cost-effective to write AND test 
Boolean-valued assertions during the bulk of the development life-cycle.

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Ted Velkoff wrote:
> 
> Ken Garlington wrote:
> >
> > Ted Velkoff wrote:
> > >
> > > Ken Garlington responded to an earlier post of mine:
> > > >
> > > > This is certainly reasonable. However, once the execution capabilities
> > > > are removed, it seems fair to ask what Eiffel provides that comments
> > > > (available in most langauges) don't provide. If there is not a
> > > > significant
> > > > difference, then Eiffel would not be any better (in this context) than
> > > > any other language, so long as the DBC principles were followed.
> > > >
> > >
> > > In my experience, there is a significant difference.  I will not presume
> > > to make a scientific claim; rather I will offer a personal, anecdotal
> > > example.
> > >[ Example followed here...]
> >
> > I think you're anwering the wrong mail :)
> 
> I'll try again.
> >
> > Please re-read the first paragraph. The discussion is about the value of
> > Eiffel assertions if they are _always_ turned off, vs. comments.
> 
> To begin with, by "_always_ turned off", I assume what is meant is
> "turned off during execution of a delivered system", not "turned off
> during execution of a delivered system and during its entire development
> phase".

Not how the original argument was phrased. However if you want to argue
the merits of turning them on during development and then off for
released
code, see section 3.2.2 of

  http://www.flash.net/~kennieg/ariane.html

for my rebuttal.

> If an Eiffel executable is built with assertion monitoring turned off,
> it is indeed no different than, say, an Ada executable built using
> pragma Suppress (Range_Check, for example).  This would be appropriate
> during the final stages of testing a product, for Factory/Site
> Acceptance Test, and delivery to a customer.
> 
> For the bulk of development, from design through code, unit and
> integration testing, one would certainly want to monitor assertions (in
> Eiffel) or Range_Checks, for instance (in Ada).  Clearly these sorts of
> compile- and run-time checks are far more powerful than mere comments
> and aid in earlier detection and correction of errors.  I say that using
> Eiffel is superior to using another language with commented assertions
> because Eiffel makes it so easy and cost-effective to write AND test
> Boolean-valued assertions during the bulk of the development life-cycle.
> 
> -- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33F5D274.30C4@flash.net> Ken Garlington <kennieg@flash.net> writes:

> > To begin with, by "_always_ turned off", I assume what is meant is
> > "turned off during execution of a delivered system", not "turned off
> > during execution of a delivered system and during its entire development
> > phase".
> 
> Not how the original argument was phrased. However if you want to argue
> the merits of turning them on during development and then off for
> released
> code, see section 3.2.2 of
> 
>   http://www.flash.net/~kennieg/ariane.html
> 
> for my rebuttal.

You know, it would really help if most of the people trying to "argue"
some contrary point here, would read this paper and understand it
before going off.  Most of the counter arguments pretty much simply
evaporate at that point.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Jon S Anthony wrote:
> 
> In article <33F5D274.30C4@flash.net> Ken Garlington <kennieg@flash.net> writes:
> 
> > > To begin with, by "_always_ turned off", I assume what is meant is
> > > "turned off during execution of a delivered system", not "turned off
> > > during execution of a delivered system and during its entire development
> > > phase".
> >
> > Not how the original argument was phrased. However if you want to argue
> > the merits of turning them on during development and then off for
> > released
> > code, see section 3.2.2 of
> >
> >   http://www.flash.net/~kennieg/ariane.html
> >
> > for my rebuttal.
> 
> You know, it would really help if most of the people trying to "argue"
> some contrary point here, would read this paper and understand it
> before going off.  Most of the counter arguments pretty much simply
> evaporate at that point.

Thanks for the vote of confidence, although I don't think the paper's
_that_ strong :)

Perhaps it's because there's not enough people who (a) use Eiffel,
(b) use the Internet, (c) care about this discussion, and (d) have
experience in Ariane 5-type systems, but I have been disappointed that
there's been very little movement of the discussion from my arguments,
as included in the paper. Most of the responses have either been

1. Repetitions of the "party line" (no specific discussion of any of
the arguments in the paper), or

2. Emotional reactions to the idea that Eiffel might not be the best
solution.

Neither has been particularly interesting. The SCOOP thread has been
useful, but it doesn't really relate to the Ariane 5 discussion. I am
particularly disappointed that the example in the Web version of the
Eiffel paper hasn't been corrected. Mr. Meyer and others may
disagree with my opinions, but I would think they would at least
correct obvious errors of fact once identified.

> /Jon
> --
> Jon Anthony
> OMI, Belmont, MA 02178, 617.484.3383
> "Nightmares - Ha!  The way my life's been going lately,
>  Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

I wrote:
> > > To begin with, by "_always_ turned off", I assume what is meant is
> > > "turned off during execution of a delivered system", not "turned off
> > > during execution of a delivered system and during its entire development
> > > phase".

Ken Garlington wrote:
> > Not how the original argument was phrased. However if you want to argue
> > the merits of turning them on during development and then off for
> > released
> > code, see section 3.2.2 of
> >
> >   http://www.flash.net/~kennieg/ariane.html
> >
> > for my rebuttal.

Jon S Anthony wrote:
> You know, it would really help if most of the people trying to "argue"
> some contrary point here, would read this paper and understand it
> before going off.  Most of the counter arguments pretty much simply
> evaporate at that point.
> 

For the record, I have read Bertrand Meyer's article on Ariane V; the 
European Space Agency's report; and at least a week ago, Ken 
Garlington's paper.  I have endeavored to the best of my ability to 
understand all of them.

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Ted Velkoff]

Ken Garlington wrote:
> 
> Ted Velkoff wrote:
> > To begin with, by "_always_ turned off", I assume what is meant is
> > "turned off during execution of a delivered system", not "turned off
> > during execution of a delivered system and during its entire development
> > phase".[...]
> 
> Not how the original argument was phrased. However if you want to argue
> the merits of turning them on during development and then off for
> released
> code, see section 3.2.2 of
> 
>   http://www.flash.net/~kennieg/ariane.html
> 
> for my rebuttal.
> 

All the points made in section 3.2.2 are valid (meeting deadlines, 
issues in regression testing, limits to development resources).  But is 
it really never appropriate to monitor assertions at any time in the 
development life-cycle?

Forget about Eiffel for a moment, and consider Ada.  I'm starting to 
think that the approach being advocated would suggest using "pragma 
Supress" throughout the entire development cycle, starting with unit 
test.  Without ever having tried to do things that way, it seems on the 
surface that it would be harder to detect and correct bugs in the early 
going.  Isn't there some amount of run-time checking that is appropriate 
during development even if it is turned off later?

-- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Ted Velkoff wrote:
> 
> Forget about Eiffel for a moment, and consider Ada.  I'm starting to
> think that the approach being advocated would suggest using "pragma
> Supress" throughout the entire development cycle, starting with unit
> test.  Without ever having tried to do things that way, it seems on the
> surface that it would be harder to detect and correct bugs in the early
> going.  Isn't there some amount of run-time checking that is appropriate
> during development even if it is turned off later?

Only if you believe the benefits outweigh the penalties described in my
paper. I have delivered Ada systems where checking was never enabled,
and
where the "assertions" were checked using non-intrusive debugger
commands.
Of course, I still got the benefit of the static checking, which
(usually)
exists even if the run-time code is suppressed.

Note that, for non-safety-critical code written in Ada, I have delivered
the
code where the checks were left on in the production system. Again, this
is a very narrowly-focused domain we are discussing (which just happens
to
potentially include the Ariane 5 IRS).

> 
> -- Ted Velkoff

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Ken Garlington wrote:
> 
> Ted Velkoff wrote:
> >
> > There is an important distinction between including/removing assertions
> > and monitoring/not monitoring them during execution.  One of the
> > principal benefits of Eiffel is the fact that assertions remain in the
> > code (where programmers will see them) even if they are not tested
> > dynamically (this is controlled by a compile-time switch).  Whether or
> > not this would have saved Ariane V, the documentation and testing
> > benefits of Eiffel's assertions would benefit many, many software
> > projects.
> 
> This is certainly reasonable. However, once the execution capabilities
> are removed, it seems fair to ask what Eiffel provides that comments
> (available in most langauges) don't provide. If there is not a
> significant
> difference, then Eiffel would not be any better (in this context) than
> any other language, so long as the DBC principles were followed.

There is one advantage. If your assertions are compiled, they must
conform to a set restricted style. Comments are, on the other hand very
free form. I think it is reasonable to say that the compiled
assertions are less likely to be ambiguous than if they are just
a comment. They are more likely to be correct if they have been executed
and tested.

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Nick says

<<There is one advantage. If your assertions are compiled, they must
conform to a set restricted style. Comments are, on the other hand very
free form. I think it is reasonable to say that the compiled
assertions are less likely to be ambiguous than if they are just
a comment. They are more likely to be correct if they have been executed
and tested.>>


That is most definitely true, however, if you restrict assertions to
executable form, that is most certainly a fierce restriction, particularly
in languages like Ada and Eiffel whose expressive power is nowhere near
that of full set theory. 

It is perfectly reasonable to have assertions in comments that are impractical
to execute, or even to talk about infinite sets where the assertions are not
even conceptually computable.

I would not rule out the utility of such assertions, though there is always
considerable value in putting assertions (or specs of any kind) into 
executable form where possible.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> This is certainly reasonable. However, once the execution capabilities
> are removed, it seems fair to ask what Eiffel provides that comments
> (available in most langauges) don't provide. If there is not a
> significant
> difference, then Eiffel would not be any better (in this context) than
> any other language, so long as the DBC principles were followed.

Even if the assertions were ignored by the compiler there is a
difference.
There is a tool called "flat" that examines a class and its ancestors
and produces an equivalent class without inheritance. In particular, it
collects all assertions from all ancestors and lists them with the final
routine. (There is even an option that gives just the signatures and
assertions, leaving out the routine bodies.)
This gives us full documentation about every routine of every class,
without having to refer to ancestor classes. So even if assertions are
comments, these comments get included in the flat form of any descendant
class.

> There is one advantage. If your assertions are compiled, they must
> conform to a set restricted style. Comments are, on the other hand
> very
> free form.

Actually it's not restricted style. It is just that comments that are in
certain parts of the class text (namely, the assertion sections)
automatically gets included in the flat form of descendants.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> Ken Garlington wrote:
> > This is certainly reasonable. However, once the execution capabilities
> > are removed, it seems fair to ask what Eiffel provides that comments
> > (available in most langauges) don't provide. If there is not a
> > significant
> > difference, then Eiffel would not be any better (in this context) than
> > any other language, so long as the DBC principles were followed.
> 
> Even if the assertions were ignored by the compiler there is a
> difference.
> There is a tool called "flat" that examines a class and its ancestors
> and produces an equivalent class without inheritance. In particular, it
> collects all assertions from all ancestors and lists them with the final
> routine. (There is even an option that gives just the signatures and
> assertions, leaving out the routine bodies.)
> This gives us full documentation about every routine of every class,
> without having to refer to ancestor classes. So even if assertions are
> comments, these comments get included in the flat form of any descendant
> class.

Can't such an extra-language tool be equally valid with comments in any
language (that has classes)?

> 
> > There is one advantage. If your assertions are compiled, they must
> > conform to a set restricted style. Comments are, on the other hand
> > very
> > free form.
> 
> Actually it's not restricted style. It is just that comments that are in
> certain parts of the class text (namely, the assertion sections)
> automatically gets included in the flat form of descendants.

This doesn't sound like Eiffel assertions, which are compiled.

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Ken Garlington wrote:
> > There is a tool called "flat" that ... collects all assertions
> > from all ancestors and lists them with the final
> > routine. (There is even an option that gives just the signatures and
> > assertions, leaving out the routine bodies.)
> > This gives us full documentation about every routine of every class,
> > without having to refer to ancestor classes. So even if assertions
> are
> > comments, these comments get included in the flat form of any
> descendant
> > class.
> 
> Can't such an extra-language tool be equally valid with comments in
> any
> language (that has classes)?

Yes, and I'd advocate some tool of this type for every language.
Something similar is done for the Java AWT, where each routine is
documented via some comments with standardized keywords (the "keywords"
being single letters, making the comment rather unreadable...); the HTML
documentation for the AWT is obviously generated with a tool.
Unfortunately, inheritance isn't considered by that tool.

The advantage of this being part of the language definition is that
a) the conventions are the same for every shop (a mere comment
convention might be different, creating incompatibilities not with the
executable code but with the development environments)
b) Eiffel can make use of executable assertions and compile them as
run-time checks.

> > Actually it's not restricted style. It is just that comments that
> are in
> > certain parts of the class text (namely, the assertion sections)
> > automatically gets included in the flat form of descendants.
> 
> This doesn't sound like Eiffel assertions, which are compiled.

Eiffel assertions are not compiled if they take the form of a comment.
You can write something like

  feature sqrt (x: real): real is
  require
    nonnegative_argument: x >= 0
  do
    ... (lots of code omitted)
  ensure
    nonnegative_result: Result >= 0
    maximum_precision: -- Every mantissa bit except the last is correct
  end

The short tool will report this routine as

  feature sqrt (x: real): real is
  require
    nonnegative_argument: x >= 0
  ensure
    nonnegative_result: Result >= 0
    maximum_precision: -- Every mantissa bit except the last is correct
  end

so executable and non-executable assertions aren't handled any
differently for documentation purposes.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Joachim Durchholz wrote:
> 
> The advantage of this being part of the language definition is that
> a) the conventions are the same for every shop (a mere comment
> convention might be different, creating incompatibilities not with the
> executable code but with the development environments)
> b) Eiffel can make use of executable assertions and compile them as
> run-time checks.
>
> [snip] 
>
> Eiffel assertions are not compiled if they take the form of a comment.

Then they aren't Eiffel assertions, per the definition you gave in (a)
and (b)!

> You can write something like
> 
>   feature sqrt (x: real): real is
>   require
>     nonnegative_argument: x >= 0
>   do
>     ... (lots of code omitted)
>   ensure
>     nonnegative_result: Result >= 0
>     maximum_precision: -- Every mantissa bit except the last is correct
>   end
> 
> The short tool will report this routine as
> 
>   feature sqrt (x: real): real is
>   require
>     nonnegative_argument: x >= 0
>   ensure
>     nonnegative_result: Result >= 0
>     maximum_precision: -- Every mantissa bit except the last is correct
>   end
> 
> so executable and non-executable assertions aren't handled any
> differently for documentation purposes.

Nor would they be handled any differently in Ada, etc.
To repeat: For those items in comments, what advantage does
Eiffel provide?

> 
> Regards,
> Joachim
> --
> Please don't send unsolicited ads.

Re: Design by Contract

[Bertrand Meyer]

In my message on the "second historic mistake" I had
written that, whereas Eiffel has successful commercial
applications approaching the million lines of source
code, there was no comparable experience in Java outside
of applets and the Java tools themselves. 

A few weeks ago there was an interesting exchange:

	[Ken Garlington]

	!!! The discussion is interesting in that Meyer
	!!! (a) criticizes Java for not being used on large
	!!! projects (whatever happened to unfair criticism
	!!! of new languages?

	[Robert Dewar]

	> > Hmmm! I guess he does not consider the Corel office
	> > suite large. Or perhaps simply does not know about it.

	[Bertrand Meyer]

	> It would be difficult not to know about it,
	> as it gets hammered over and again by Java proponents
	> (along with Java tools themselves) as the example of
	> completed Java development, to the extent that one
	> may wonder whether there is any other.

It's really fascinating to read this again a month later,
with the recent announcements -- widely reported by the
press -- that Corel is dropping its Java strategy altogether.

So much for the showcase success...

-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Design by Contract

[Bertrand Meyer]

on S Anthony wrote:
 
> Isn't this simply amazing?  I mean, really - what do these people
> think they are saying anyway?  To me this has long since pushed my
> "boggo-meter" off the scale and crossed into the mind-numbingly
> fatuous.
 
where "these people", if I understand properly, means advocates
of Design by Contract.

Insulting the other side is not a substitute for rational argument
(but tends to suggest fragility of one's case).

In a related message, W. Wesley Groleau writes

 >       I say again: If [Design by Contract]
 >       is defined as "Associating specifications 
 >       with software elements", then Eiffel indeed directly
 >       supports a SUBSET of DBC.  Ada directly supports another
 >       subset of DBC. C++ (shudder) directly supports yet
 >       another subset of DBC.  And  with a little extra work,
 >       the user of any of these languages can  handle a larger
 >       subset.  But none of them can completely support 
 >       the whole thing.  And the intersection of the subsets
 >       is not empty.

which the 3 or 4 strident Ada advocates in this thread now
repeat in all tunes to assert that, after all, Ada supports
Design by Contract just as much as Eiffel, only differently.

This is a sophism. Of course in any typed language you can
express some specification elements;
e.g. by declaring f (x: INTEGER) in
Pascal or the equivalent in Fortran, C, Ada etc. you are
placing some restrictions on what kind of argument f admits.
But this is a far cry from what you need to express useful
specifications:

        - Routine preconditions -- semantic conditions
          (not just type constraints).

        - Routine postconditions (how do you state that
          at the end of the procedure `withdraw' the balance
          must have been decreased by `sum'?).

        - Class invariants, expressing general integrity
          constraints.

        - The relationship with inheritance (precondition weakening
          and postcondition strengthening in redeclaration;
          invariant accumulation).

        - The relationship with documentation tools.

        - The relationship with exception handling.

Common languages support at most a minute subset of the 1st
and 3rd items. To use this observation to justify a Turing-tarpit
kind of argument -- "all languages support Design by Contract,
only in various ways" -- is a fallacy. So huge a "difference of
degree" becomes a difference of nature. Just take any of the
assertions of the classes of EiffelBase and try to express
them in C, Ada, C++ or Java. You will be able to write almost
nothing.

What *is* true is that in such languages without assertions
you can and should still apply Design by Contract purely as
a methodological discipline. Although you won't get the
language and tool support, you will still get some of the benefits.
But, no, declaring variables with interval types as in Pascal
or Ada is not Design by Contract.

The rear-guard battle waged by a few people against Design
by Contract on comp.lang.ada and comp.lang.eiffel --
oscillating between "it's useless", "it can all be done in Ada",
"it's nothing new", "it's irrelevant to the real problems",
"it's not enough", "it's snake oil" and other endless
if often contradictory variations -- is saddening.
Saddening because as soon as Design by Contract is applied
systematically (whether as pure methodology, or better
yet in a language like Eiffel that directly supports them)
the benefits in reliability are immediate and huge.
We constantly hear from our customers and our own work
of major potential bugs that are caught before they
have had time to strike, simply thanks to contracts.
And bug avoidance is only one of the applications.
The ability to do serious object-oriented analysis,
for example, is just as important.

All the rhetoric in the world fades away when assessed
against the potential for dramatic improvements in
software quality. That's what counts  -- not who shouts
louder. 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Design by Contract

[Nick Leaton]

Joerg Rodemann wrote:
> And exactly for that reason I would like to join the opinion that source
> seperation of specification and implementation is very useful as well.
> As far as I can tell this is a feature that Eiffel seems to be missing, as
> many other language. E. g. I rather liked Oberon for quite a while for its
> clean and simple concept. But the merging of definition and module files (as
> spec and implementation are called there) I found somewhat annoying. Surely
> I could see some benefits of this 'new' mechanism if Oberon is used within
> that graphical Oberon System. But I used an implementation of Oberon
> developped at the University of Ulm that simply sat on top of a Unix system.
> I thinks this mixin of spec and body would have messed up things a lot.
> 
> My experience with C++ and C supports this believe as well (note: this is
> just MY experience.) for people often do not care about this seperation.
> the craziest thing IMO is the inlining of methods within the class header
> in C++. If the code is not very well structured you can spend hours and days
> about just searching for the specifications. (And the debugger won't be of
> much help either... *sigh*)
> 
> As I see it a separation of spec and body is VERY useful and indeed some
> kind of contract as well. If it has to be counted among the constructs for
> DBC depends of this term's actual definition...

There are different ways of approaching the separation. I suspect the 
majority of people agree that separation is a good thing, but there are
more
than one way of achieving the aim. Approach one is the C++ way, separate
files.
The problem here is keeping them in line, consistent names etc. The
other approach
is to have one file, but have the ability to view the files in different
ways.
Extract the spcification, view everything. I believe the second way to
be the
better way as it is simpler, and you use the machine for something it is
good at
doing.

The drawbacks are if you want to publish a specification that won't
compile.
Why is my immediate response.

You need a means to publish specifications for libraries where you only
release
the compiled code, thereby hiding the implementation. 

-- 

Nick

Re: Design by Contract

[Matt Kennel (Remove 'NOSPAM' to reply)]

On 26 Aug 1997 17:33:11 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
:That's truly surprising. One of the things that virtually everone who
:uses Ada agrees on is that the separation of spec and body is an invaluable aid
:to system structuring. 

Can you explain how that works exactly?

Personally I would imagine that one can get approximately the same benefit
by using abstract classes as specifications, with a nice conceptual
simplification of the language.

This is not a flame, btw, but I've always had the gut feeling that a
Modula-2 like package spec vs. implementation separation was a good idea,
but only in the days before a ''real'' complete OO language.

If you're going from a generally ad-hoc procedural design, I can imagine it
would feel nice, but in a language which already includes abstract interfaces
for other reasons, it seems like it would be needless bureaucracy. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           -
* "People who send spam to Emperor Cartagia... vanish! _They say_ that
* there's a room where he has their heads, lined up in a row on a desk...
* _They say_ that late at night, he goes there, and talks to them... _they
*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"

Re: Design by Contract

[Ted Velkoff]

Robert Dewar wrote:
> 
> Nick said
> 
> <<But if you are allowed to change the merged specification/implementation
> and check
> that you haven't caused problems else where you are ok. It is true that
> with C++
> you have problems and have to be careful. Eiffel you don't, because
> there is just one file. Modula II as you point out you don't. Give the
> choice of the two different approaches, and having used both I would now
> always go for spec and impl. in one file.
> >>
> 
> That's truly surprising. One of the things that virtually everone who
> uses Ada agrees on is that the separation of spec and body is an invaluable aid
> to system structuring. Of course there is no concern about incomaptibilities
> in Ada, since everything is always checked for consistency -- I
> see that in C++ this would be a prblem, but
> going to a single file is a horrible way to solve the problem.

Having used each of the languages cited, I vote for Eiffel's one file 
with extracted specification.  When needing to change an interface, I've 
found it annoying to have to make the same change in two different 
places.  Of course, Ada's compilable package specs are infinitely better 
than C++ header files.

-- Ted Velkoff

Re: Interface/Implementation (was Re: Design by Contract)

[Bertrand Meyer]

Here is the reasoning behind the Eiffel approach to
separating interface from implementation. It was designed
in full knowledge of the Modula-2/Ada-83 mechanisms, in an
attempt to draw the lessons of both their advantages and
limitations, taking advantage of newer software technology
and of O-O principles.

The goals are clear:

        G1. Allow people to consider separately the
            interface and the implementation of a module
            -- class in Eiffel, module in Modula, package
            in Ada.

        G2.(Closely related to G1.) Allow a developer
            to write a client class of a class C without
            knowing what C's implementation is, or even
            prior to the existence of such an implementation,
            as long as C's interface is known.

	G3 (Closely related to G2.) Allow a project leader
	   to restrict the list of who can access the
	   implementation of a module, allowing others access
	   to the interface only. This is also of interest
	   to vendors of reusable components, who may want
	   to make source not available to their customers
	   in some or all cases. (Whether this is good or
	   bad is another topic; it is a fact that some
	   vendors want this possibility.)

        G4. Allow multiple implementations of a given
            interface, including the possibility for
            clients to switch easily and implicitly
            between various implementations at run time
            (not possible, at least not possible simply,
            in Modula/Ada). This of course will take advantage
            of polymorphism and dynamic binding.

        G5. Minimize the programmer's work. In particular
            it is crucial to avoid forcing the programmer
            to duplicate text. Duplication is almost always
            bad, especially with respect to ease of maintenance,
            one of the central goals of software engineering.
            It also hampers reuse, reliability (when you
            duplicate code, you duplicate its bugs, and
            the more software you write the more likely
            it is that it will include bugs), and ease
            of change.

        G6. Favor seamlessness: the Eiffel method emphasizes
            the notion of a "single product" around which
            all software development activities revolve.
            This is in opposition to the traditional
            multi-product view ("the analysis", "the
            design",  "the documentation", "the code"
            -- including ,for the latter,
            "the interface", "the implementation").
            We may not always succeed in putting
            everything into one place (i.e. we will probably
            retain the need for some external documentation)
            but will try to get as close as possible to this
            goal; the benefits for the software process
            are enormous.

The Eiffel policy is a result of these considerations:

        E1. If a class has a single implementation, write
            everything at the same place: interface and
            implementation. This directly addresses 
            requirements G5 and G6 and differs markedly
            from the Modula, Ada etc. practice of
            writing the interface twice (once in the
            interface part, once in the body), which in
            my opinion is a nuisance, not just because
            of the initial duplication of work but because
            of the added maintenance burden.

        E2. Provide tools in the environment to produce
            the interface of a class, automatically from
            the class text. In Eiffel environments this is the
            role of the short and flat-short tools, which
            reconstruct the interface from the class.
            In ISE Eiffel you click on the "short" or
            "flat-short" icons of a Class Tool and the
            contents change to show the interface,
            pretty-printed, or in HTML format (with
	    references to other classes turned into
	    hyperlinks), RTF, FrameMaker etc.

        E3. A generalization of E2 follows from the
            observation that instead of just
            "implementation" and "interface" we should be
            talking about various *views* of a class, and
            rely on the power of the *computer* to produce
            these views as we need them.
            The implementation is one such view; the interface
            is another; but there are more. Short and flat-short
            are indeed examples of different abstract views
            (short considers only the features introduced
            in the class; flat-short integrates inherited
            features too). An environment can also provide
            many intermediate views, such as "the features
            available to a client class C" (i.e. the interface
            of the class as viewed by the author of C),
            "the interface as available to a descendant
            class", etc. This is only possible because we
            do NOT require the class author to write the
            interface separately; generalized, this idea
            would become absurd since it would mean that
            you have to write lots of different interfaces
            (views) for each class. Instead, the Eiffel view
            is that you should write the class -- the single
            product, see goal G6 -- and concentrate on
            equipping it with everything that it needs:
            useful features, complete preconditions,
            expressive postconditions, insightful class
            invariants, efficient implementations. You don't
            want to be bothered by e.g. having to write
            routine interfaces twice.
            Then if you or one of your client authors needs
            information about apecific properties of the
            class you will rely on tools to get it.

            Like many other differences with common languages,
            this Eiffel policy results from a difference of
            appreciation as to what should be done by humans
            and what by the computer. We want to let humans
            concentrate on creative, insightful work (e.g.
            designing a class), and rely on the computer
            for automatable and potentially tedious tasks.
            It is the same spirit that explains Eiffel's
            policy (in contrast variously with Ada, C++
            etc.) with respect to dynamic binding, garbage
            collection, routine inlining (in the ISE
            implementation), etc.

        E4. There remains the case in which you do want to
            write the interface as a separate module, because
            it can have several implementations. The technique
            then is easy: write it as a deferred class; then
            the various implementations can inherit from it.
            But then it will truly deserve to be called a
            "specification" (the Ada term) because, unlike
            other languages, Eiffel makes it possible to
            attach true semantic properties to the components
            of a deferred class: routine preconditions, routine
            postconditions, class invariants. (This is missing
            from Ada "specifications" and Java "interfaces"
            and, in my opinion, regrettably limits their 
            usefulness.) These specification elements
            are binding on all redeclarations in descendant
            classes ("effectings" in Eiffel terminology,
            i.e. a descendant providing an actual implementation
            for a feature that in the parent was deferred,
            i.e. specified but not implemented).

        E5. In case E4, it is of course possible to switch
            at run time between the various alternative
            implementations provided, thanks to polymorphism
            and dynamic binding. If I have t: TABLE [SOME_TYPE]
            where TABLE has various descendants providing
            alternative table implementations, I can write

                  t.search (some element)
        
            without knowing what kind of table `t' denotes
            (although I know it can only be a table, thanks
            to the type rules). Then various executions of the
            call, including during the same session of the system,
            can refer to different implementations and
            consequently use different versions of `search',
            automatically selected by the dynamic binding
            mechanism so that they will always be the appropriate
            one in each case.

        E5. Sometimes you may start out with a concrete
            class of which you consider only one possible
            implementation (case E1), and hence not bother
            to write a separate deferred class. Then later
            you may realize that you need other implementations
            too. Then the switch to case E4 is easy: just
            use a "short"-like tool to produce a deferred class
            from the original and rewrite that original to
            inherit from the deferred class. This is an
            easy change and in particular is painless for
            the existing client classes, since they only
            relied on the interface (as produced by short
            or flat-short) and hence will not be affected
            at all by the change; they may not even have
            to be recompiled. This is a direct implementation
            of information hiding principles.

	E6. An Eiffel implementation may permit the author of
	    a class library to make it available precompiled,
	    without giving access to the source. (This is
	    the case with ISE Eiffel 4.) The short and
	    flat-short forms are of course available through
	    the tools of the environment. This directly
	    addresses goal G3.
        
In short, the Eiffel approach proceeds from the same general
ideas as the technique of "separating interface from
implementation" but goes further; it considers the
whole software engineering picture, takes into account
the problems encountered with the Modula-Ada approach,
and of course takes advantage of object technology.

These issues are discussed in more detail in "Object-Oriented
Software Construction, 2nd edition" (Prentice Hall);
see in particular chapter 23, "Principles of Class Design",
pages 747-808.


-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Interface/Implementation (was Re: Design by Contract)

[Bertrand Meyer]

(This is a revised version as I had forgotten point E8.)

Here is the reasoning behind the Eiffel approach to
separating interface from implementation. It was designed
in full knowledge of the Modula-2/Ada-83 mechanisms, in an
attempt to draw the lessons of both their advantages and
limitations, taking advantage of newer software technology
and of O-O principles.

The goals are clear:

        G1. Allow people to consider separately the
            interface and the implementation of a module
            -- class in Eiffel, module in Modula, package
            in Ada.

        G2.(Closely related to G1.) Allow a developer
            to write a client class of a class C without
            knowing what C's implementation is, or even
            prior to the existence of such an implementation,
            as long as C's interface is known.

        G3 (Closely related to G2.) Allow a project leader
           to restrict the list of who can access the
           implementation of a module, allowing others access
           to the interface only. This is also of interest
           to vendors of reusable components, who may want
           to make source not available to their customers
           in some or all cases. (Whether this is good or
           bad is another topic; it is a fact that some
           vendors want this possibility.)

        G4. Allow multiple implementations of a given
            interface, including the possibility for
            clients to switch easily and implicitly
            between various implementations at run time
            (not possible, at least not possible simply,
            in Modula/Ada). This of course will take advantage
            of polymorphism and dynamic binding.

        G5. Minimize the programmer's work. In particular
            it is crucial to avoid forcing the programmer
            to duplicate text. Duplication is almost always
            bad, especially with respect to ease of maintenance,
            one of the central goals of software engineering.
            It also hampers reuse, reliability (when you
            duplicate code, you duplicate its bugs, and
            the more software you write the more likely
            it is that it will include bugs), and ease
            of change.

        G6. Favor seamlessness: the Eiffel method emphasizes
            the notion of a "single product" around which
            all software development activities revolve.
            This is in opposition to the traditional
            multi-product view ("the analysis", "the
            design",  "the documentation", "the code"
            -- including ,for the latter,
            "the interface", "the implementation").
            We may not always succeed in putting
            everything into one place (i.e. we will probably
            retain the need for some external documentation)
            but will try to get as close as possible to this
            goal; the benefits for the software process
            are enormous.

The Eiffel policy is a result of these considerations:

        E1. If a class has a single implementation, write
            everything at the same place: interface and
            implementation. This directly addresses 
            requirements G5 and G6 and differs markedly
            from the Modula, Ada etc. practice of
            writing the interface twice (once in the
            interface part, once in the body), which in
            my opinion is a nuisance, not just because
            of the initial duplication of work but because
            of the added maintenance burden.

        E2. Provide tools in the environment to produce
            the interface of a class, automatically from
            the class text. In Eiffel environments this is the
            role of the short and flat-short tools, which
            reconstruct the interface from the class.
            In ISE Eiffel you click on the "short" or
            "flat-short" icons of a Class Tool and the
            contents change to show the interface,
            pretty-printed, or in HTML format (with
            references to other classes turned into
            hyperlinks), RTF, FrameMaker etc.

        E3. A generalization of E2 follows from the
            observation that instead of just
            "implementation" and "interface" we should be
            talking about various *views* of a class, and
            rely on the power of the *computer* to produce
            these views as we need them.
            The implementation is one such view; the interface
            is another; but there are more. Short and flat-short
            are indeed examples of different abstract views
            (short considers only the features introduced
            in the class; flat-short integrates inherited
            features too). An environment can also provide
            many intermediate views, such as "the features
            available to a client class C" (i.e. the interface
            of the class as viewed by the author of C),
            "the interface as available to a descendant
            class", etc. This is only possible because we
            do NOT require the class author to write the
            interface separately; generalized, this idea
            would become absurd since it would mean that
            you have to write lots of different interfaces
            (views) for each class. Instead, the Eiffel view
            is that you should write the class -- the single
            product, see goal G6 -- and concentrate on
            equipping it with everything that it needs:
            useful features, complete preconditions,
            expressive postconditions, insightful class
            invariants, efficient implementations. You don't
            want to be bothered by e.g. having to write
            routine interfaces twice.
            Then if you or one of your client authors needs
            information about apecific properties of the
            class you will rely on tools to get it.

            Like many other differences with common languages,
            this Eiffel policy results from a difference of
            appreciation as to what should be done by humans
            and what by the computer. We want to let humans
            concentrate on creative, insightful work (e.g.
            designing a class), and rely on the computer
            for automatable and potentially tedious tasks.
            It is the same spirit that explains Eiffel's
            policy (in contrast variously with Ada, C++
            etc.) with respect to dynamic binding, garbage
            collection, routine inlining (in the ISE
            implementation), etc.

        E4. There remains the case in which you do want to
            write the interface as a separate module, because
            it can have several implementations. The technique
            then is easy: write it as a deferred class; then
            the various implementations can inherit from it.
            But then it will truly deserve to be called a
            "specification" (the Ada term) because, unlike
            other languages, Eiffel makes it possible to
            attach true semantic properties to the components
            of a deferred class: routine preconditions, routine
            postconditions, class invariants. (This is missing
            from Ada "specifications" and Java "interfaces"
            and, in my opinion, regrettably limits their 
            usefulness.) These specification elements
            are binding on all redeclarations in descendant
            classes ("effectings" in Eiffel terminology,
            i.e. a descendant providing an actual implementation
            for a feature that in the parent was deferred,
            i.e. specified but not implemented).

        E5. In case E4, it is of course possible to switch
            at run time between the various alternative
            implementations provided, thanks to polymorphism
            and dynamic binding. If I have t: TABLE [SOME_TYPE]
            where TABLE has various descendants providing
            alternative table implementations, I can write

                  t.search (some element)
        
            without knowing what kind of table `t' denotes
            (although I know it can only be a table, thanks
            to the type rules). Then various executions of the
            call, including during the same session of the system,
            can refer to different implementations and
            consequently use different versions of `search',
            automatically selected by the dynamic binding
            mechanism so that they will always be the appropriate
            one in each case.

        E6. Sometimes you may start out with a concrete
            class of which you consider only one possible
            implementation (case E1), and hence not bother
            to write a separate deferred class. Then later
            you may realize that you need other implementations
            too. Then the switch to case E4 is easy: just
            use a "short"-like tool to produce a deferred class
            from the original and rewrite that original to
            inherit from the deferred class. This is an
            easy change and in particular is painless for
            the existing client classes, since they only
            relied on the interface (as produced by short
            or flat-short) and hence will not be affected
            at all by the change; they may not even have
            to be recompiled. This is a direct implementation
            of information hiding principles.

        E7. An Eiffel implementation may permit the author of
            a class library to make it available precompiled,
            without giving access to the source. (This is
            the case with ISE Eiffel 4.) The short and
            flat-short forms are of course available through
            the tools of the environment. This directly
            addresses goal G3.
       

        E8. An interface-implementation separation a la
            Modula or Java gives you only two kinds of
            modules: fully implemented versions (the bodies
            of packages) and headers without any implementation
            at all (package specifications; also Java
            "interfaces"). This is too restrictive. With
            Eiffel's deferred classes you have the whole
            spectrum: fully implemented (a class with no
            deferred features), fully abstract (a class
            with only deferred features), but also partially
            implemented. This is one of the key mechanisms
            of object technology, and without it one is
            severely constrained. A typical example is class
            COMPARABLE from the Eiffel Library Kernel Standard
            (ELKS) which describes order relations. Feature
            infix "<" is deferred; but the others, such as
            ">", "<=", ">=" are not, and they should not be,
            since they can be defined in terms of "<" and
            equality (for example a > b is defined as b < a).
            You can't do that with pure interfaces.

In short, the Eiffel approach proceeds from the same general
ideas as the technique of "separating interface from
implementation" but goes further; it considers the
whole software engineering picture, takes into account
the problems encountered with the Modula-Ada approach,
and of course takes advantage of object technology.

These issues are discussed in more detail in "Object-Oriented
Software Construction, 2nd edition" (Prentice Hall);
see in particular chapter 23, "Principles of Class Design",
pages 747-808.
 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <3404909F.2C67412E@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

>         G4. Allow multiple implementations of a given
>             interface, including the possibility for
>             clients to switch easily and implicitly
>             between various implementations at run time
>             (not possible, at least not possible simply,
>             in Modula/Ada). This of course will take advantage
>             of polymorphism and dynamic binding.

More to the point: not _relevant_ in the Ada case as this is handled
by a different orthogonal capability (instead of conflating it with
module as in Eiffel).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Jon Anthony says

<<More to the point: not _relevant_ in the Ada case as this is handled
by a different orthogonal capability (instead of conflating it with
module as in Eiffel).>>


Nice word (conflate) :-)
I often point out that unify and confuse mean the same thing (join
together), but express a different point of view about the desirability
of doing so -- conflate is nicely neutral.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFqDAG.2zn@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >> >More to the point: not _relevant_ in the Ada case as this is handled
> >> >by a different orthogonal capability (instead of conflating it with
> >> >module as in Eiffel).
> >> 
> >>   I think this is a case of Ada hairsplitting, where something
> >> which is really a single concept is split into two "orthogonal"
> >> concepts for no particular benefit.  Specifying an interface
> >
> >Irrelevant.  Given the case being discussed, the point about
> >polymorphism not being available on Ada modules (packages) is just
> >plain irrelevant as that is not what they are for.  You might as well
> >complain about the lack of feathers on mammals for crying out loud.
> 
>   Hey, read my quote; I never even *hinted* at polymorphism on
> Ada modules.

Hey - follow the thread.  BM _explicitly stated_ this as a flaw in Ada
modules and was the very thing I responded to as irrelevant.


>  You might as well bash me for complaining about
> the lack of feathers on mammals.

No, now I'm wondering why you even replied to my first post which was
a direct reply to the "polymorphism" aspect as noted above.  Sheesh!


> >For boatloads of reasons that have been gone over in painstaking
> >detail in the past.  If you don't like them, use Eiffel or C++ or
> >something.  If you like the Ada way, use it or CLOS (which treats
> >module (actually called "packages" similarly) or some such.
> 
>   Hey, Jon, easy boy. 

I see no "shouting" there.  This paragraph should be read as a
"*sigh*" and one big shoulder shrug.


>   Jon, why do you insist on these personal attacks?  I thought it

I don't see these as "personal attacks".  For crying out loud...


> bothered, and just want to refer me to Deja News, fine, but
> lets keep these shots above the belt.

Believe me - there are no shots being fired here.  This is another
good example how the inexpressive medium of news can set entire
threads into flames simply because someone took a simple statement as
a "shot".

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <JSA.97Aug29191413@alexandria.organon.com>,
:Jon S Anthony <jsa@alexandria.organon.com> wrote:
:>In article <EForsv.Fqo@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
:>
:>> >More to the point: not _relevant_ in the Ada case as this is handled
:>> >by a different orthogonal capability 

Agree. Multiple, polymorphic implementations are provided by deferred classes
and abstract types in Eiffel and Ada respectively. As Jon says, this is an 
orthogonal concept to interfaces.

:>> >(instead of conflating it with module as in Eiffel).

This is a different issue.


:>> using a deferred class is more powerful than a simple interface
:>> file, and can accomplish all the same things, so why split
:>> this into two concepts?

Because they serve different purposes. (See my previous post).

:  The Deja News suggestion is a good idea.  I'll take a look there
:when I get a moment.

You could, but you may get more confused. :(

Try thinking along the lines of

  a) Ada interfaces correspond to Eiffel short forms, and
  b) Ada abstract types correspond to Eiffel deferred classes.

In terms of b), the Ada (corrections welcome):

package P is
  type T is abstract tagged private;
  procedure Do_Something (X: T) is abstract;      -- deferred/abstract
private
  type T is tagged record 
    Y: Integer;
  end record;
end;


is basically equivalent to the Eiffel:

deferred class T
  feature
    do_something is deferred end                  -- deferred/abstract
  feature {NONE}
    y: INTEGER
end.


Deriving effective (concrete) descendants from these, we might have the Ada: 

with P;
package Q is
  type New_T is new P.T;
  procedure Do_Something (X: T);
end;

package body Q is
  procedure Do_Something (X: T) is begin .. end;      -- effective
end;


and the corresponding Eiffel:

deferred class NEW_T
  inherit T
  feature
    do_something is do .. end                         -- effective
end.


:>>   And, as far as the class-as-module approach in Eiffel goes, I
:>> once thought this was a bad idea too, but I'm not so sure any
:>> more.  Do you have some arguments against it?
:>
:>Tons.  See DejaNews...  

Whether or not they convinced anyone is another matter, however.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFv7yL.yr@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> Try thinking along the lines of
> 
>   a) Ada interfaces correspond to Eiffel short forms, and
>   b) Ada abstract types correspond to Eiffel deferred classes.

Agreed.


> In terms of b), the Ada (corrections welcome):
> 
> package P is
>   type T is abstract tagged private;
>   procedure Do_Something (X: T) is abstract;      -- deferred/abstract
> private
>   type T is tagged record 
>     Y: Integer;
>   end record;
> end;
> 
> 
> is basically equivalent to the Eiffel:
> 
> deferred class T
>   feature
>     do_something is deferred end                  -- deferred/abstract
>   feature {NONE}
>     y: INTEGER
> end.

This looks right to me.

> Deriving effective (concrete) descendants from these, we might have the Ada: 
> 
> with P;
> package Q is
>   type New_T is new P.T;
>   procedure Do_Something (X: T);
> end;
> 
> package body Q is
>   procedure Do_Something (X: T) is begin .. end;      -- effective
> end;

Actually, the body has nothing to do with it.  The concrete
declaration in the spec. is the "effective" one (there could be many
[completely different] bodies implementing it)


> and the corresponding Eiffel:
> 
> deferred class NEW_T
>   inherit T
>   feature
>     do_something is do .. end                         -- effective
> end.

Agreed.


> :>Tons.  See DejaNews...  
> 
> Whether or not they convinced anyone is another matter, however.

Convincing has nothing to do with it.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Jon S Anthony wrote:

:In article <EFv7yL.yr@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

[..]

:> package body Q is
:>   procedure Do_Something (X: T) is begin .. end;      -- effective
:> end;
:
:Actually, the body has nothing to do with it.  

It's there for completeness.

:The concrete declaration in the spec. is the "effective" one (there could be many
:[completely different] bodies implementing it)

True, just as you could have different versions of an Eiffel class that match 
the same short form (possibly previously generated by another version and 
frozen in CM).


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[John G. Volan]

Patrick Doyle wrote:
> 
> It's my position (until further enlightenment :-) that abstract/
> deferred classes can do what separate interfaces do, and more, so
> why do we need separate interfaces?

Well, one problem with using abstract/deferred classes as a simulation
for separate interfaces, is that the former might do _too much_. You
wind up getting polymorphic dynamic dispatching in situations that don't
really call for it.  This can result in an unnecessary run-time
performance penalty when a given program includes only one concerete
implementation class for a given abstract class (unless your programming
environment is able to detect and optimize this situation).

In Ada, every single package must have a separate spec, so Ada
programmers are used to applying this pattern everywhere.  But I'd wager
that very few Eiffel programmers would consider introducing an abstract
parent class for every one of their concrete classes, just to simulate
Ada packaging.  I'd assume that abstract/deferred classes appear in
typical Eiffel programs just as frequently as abstract tagged types do
in Ada95 programs, and that they typically serve the same role:
implementing generalization/specialization hierarchies. 

So I don't see abstract classes as a very good mapping for Ada package
specs, and I agree with those who compare Ada specs to Eiffel short
forms.

One thing I'm curious about: Can an Eiffel environment tell the
difference between an interface modification and an implementation
modification?  Suppose a programmer edits a class text and only makes
changes to its implementation (like changing a few statements in the
body of a method) but doesn't make any interface changes (like changing
the number and/or types of the method arguments).  Semantically, an
implementation change shouldn't obsolete the compilation of any client
that only depends on the class interface.  Will a typical Eiffel IDE be
able to distinguish this as an implementation-only change, or will it
force the recompilation of all client classes?

Conversely, suppose you do make an interface change. Will the IDE detect
this and require that all client classes be recompiled?  Or is it
possible in Eiffel to generate an incorrect executable by linking a
class's object code with obsolete client object code?

An Ada system can easily distinguish these situations, because the spec
and body of a package are separate constructs, typically in separate
files.  But an Eiffel system would need to be able to take a class text
and sift the interface out from the implementation, in order to avoid
recompilations when they are not needed but enforce them when they are
needed.  Do Eiffel systems, in practice, do a good job with this?
-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> In Ada, every single package must have a separate spec, so Ada
> programmers are used to applying this pattern everywhere.  But I'd 
> wager that very few Eiffel programmers would consider introducing an 
> abstract parent class for every one of their concrete classes, just to 
> simulate Ada packaging.  ....

Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
he/she could actually use Ada?  (And vice versa, lest anyone think
I'm making another language-bigot comment...)

The discussion of language merits is not served by either side
trying to avoid consideration of a difference by offering a kludgy
workaround of the other language's feature.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <340F39E3.4B71@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
>he/she could actually use Ada?  (And vice versa, lest anyone think
>I'm making another language-bigot comment...)
>
>The discussion of language merits is not served by either side
>trying to avoid consideration of a difference by offering a kludgy
>workaround of the other language's feature.

  Being the one who seems to be pursuing this quest, I'll explain
myself.

  I'm not trying to emulate Ada.  Creating an interface that can be
frozen for programmers to work against is a very important thing.
On first glance, it seems there's no easy way to do that in Eiffel,
besides using the Short tool and checking the output for changes.

  My point is that deferred classes *are* interfaces, so if you
want to freeze an interface, freeze a deferred class.

  See--it has little to do with Ada.  I'm simply referring to Ada
because it has a built-in facility for creating interfaces for
every class, and so the Ada people have a great deal of experience
with this methodology; so I was asking them about using deferred
classes because presumably they'd be the best ones to find the
flaws in the deferred class methodology.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Patrick Doyle wrote:
> 
> >Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
> >he/she could actually use Ada?  (And vice versa, lest anyone think
> >I'm making another language-bigot comment...)
> >
> >The discussion of language merits is not served by either side
> >trying to avoid consideration of a difference by offering a kludgy
> >workaround of the other language's feature.
> 
>   Being the one who seems to be pursuing this quest, I'll explain
> myself.
> 
>   I'm not trying to emulate Ada.  Creating an interface that can be
> frozen for programmers to work against is a very important thing.
> On first glance, it seems there's no easy way to do that in Eiffel,
> .... and so the Ada people have a great deal of experience
> with this methodology; so I was asking them about using deferred
> classes because presumably they'd be the best ones to find the
> flaws in the deferred class methodology.

Well, your rationale for the question is valid.  I was responding
to those who want to deny that a good feature language X is not
an advantage because language Y can accomplish the same thing by
an unintended use of features it DOES have.  Those are the folks 
that first brought up the idea.

It happens on the Ada side, too.  "Multiple inheritance is not
important because we can simulate it this way."  What the Ada advocate
should say is one of (1) "We think MI is bad because"  OR (2) "We
looked at the _goal_ of multiple inheritance and decided that _goal_
could be better acheived by..." OR (3) "OK, we'll let you have that 
as an advantage of your language."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <34103462.1D86@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>Patrick Doyle wrote:
>> 
>>   Being the one who seems to be pursuing this quest, I'll explain
>> myself.
>
>Well, your rationale for the question is valid.  I was responding
>to those who want to deny that a good feature language X is not
>an advantage because language Y can accomplish the same thing by
>an unintended use of features it DOES have.  Those are the folks 
>that first brought up the idea.

My argument is that Eiffel already has a facility to freeze an
interface.  In other words, Ada's extra interface file can be
simulated in Eiffel with *no extra effort* than is required
in Ada.

(BTW, I'm starting to be convinced that the extra interface
file is a Good Thing, but I'm not fully decided just yet... :-)

>It happens on the Ada side, too.  "Multiple inheritance is not
>important because we can simulate it this way."  What the Ada advocate
>should say is one of (1) "We think MI is bad because"  OR (2) "We
>looked at the _goal_ of multiple inheritance and decided that _goal_
>could be better acheived by..." OR (3) "OK, we'll let you have that 
>as an advantage of your language."

  Or (4) "Here's a simple elegant way to get all the benefits if MI
using existing Ada techniques".

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <34103462.1D86@pseserv3.fw.hac.com>, wwgrol@pseserv3.fw.hac.com 
says...
> What the Ada advocate
>should say is one of (1) "We think MI is bad because"  OR (2) "We
>looked at the _goal_ of multiple inheritance and decided that _goal_
>could be better acheived by..." OR (3) "OK, we'll let you have that 
>as an advantage of your language."

The Language Rationale does (2).  I just wish I understood the examples.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG1Iz4.5po@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

>   My point is that deferred classes *are* interfaces, so if you
> want to freeze an interface, freeze a deferred class.

And?  I'm not sure what you are fishing for - an Ada spec. is simply a
different kind of thing.  It _provides_ a "bundled" (aka packaged)
interface or several interfaces depending on what is packaged up in
it.


>   See--it has little to do with Ada.  I'm simply referring to Ada
> because it has a built-in facility for creating interfaces for
> every class, and so the Ada people have a great deal of experience
> with this methodology; so I was asking them about using deferred
> classes because presumably they'd be the best ones to find the
> flaws in the deferred class methodology.

Maybe that's the problem.  Why should there be a "flaw"?  It's just a
different thing.  Package specs provide encapsulated interfaces.  The
package specs. themselves can't be derived and can't be inherited.
They have nothing corresponding to them at runtime (whereas a deferred
or abstract class should have a jump table.  Well, probably...)

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Wes says

<<Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
he/she could actually use Ada?  (And vice versa, lest anyone think
I'm making another language-bigot comment...)>>


Very often in such discussions, you see claims that

"feature x in language y can easily be simulated in language w using approach z"

The trouble with such statements is that they are almost always true, and
there almost always exists w,z for all x,y, but the observation is 
meaningless.

For instance, a C programmer by very restricted, very stylized use of
headers, together with amazing tools that enforce and monitor these
restrictions, essentially complete duplicate the effect of the separation
of Ada specs and bodies.

But the issue is not whether C programmers *could* do this, but whether
they *do* do this in practice? And certainly for that example, the answer
is (rather universally) no.

SO the issue with Eiffel is not whether you *could* get the effects, e.g.
ease of ability to separate spec and body in a CM environment, but whether
people *in practice* work this way.

Note how significant it is that I make a simple request for anyone to 
report in on how Eiffel would work together with a typical CM tool
like Continuus or Clearcase to achieve this kind of separation.

The only responses have been theoretical, pointing out that in very general
terms, with some unspecified additional tools, it could be achieved. But
even these theoretical reponses have not shown any awareness of these
CM tools -- one would almost begin to get the feeling that typical Eiffel
projects are not using CM tools at all, though that cannot be right (probably,
as is the case for Ada, most of the people working on real live projects
have better things to do with their time than read, let alone contribute to,
this rather wandering thread.

Still it would be nice to have at least ONE concrete experience report
that shows that the engineering details of this approach are practical.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <dewar.873725590@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>SO the issue with Eiffel is not whether you *could* get the effects, e.g.
>ease of ability to separate spec and body in a CM environment, but whether
>people *in practice* work this way.

I don't think that's the issue.  If Ada people generally use a technique
which is superior to what I do, I'd like to find a way to do it using
Eiffel.  I don't care what people to in practice.  I'm here to learn
and to hone my own skills.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <EG7tIq.n0F@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>>SO the issue with Eiffel is not whether you *could* get the effects, e.g.
>>ease of ability to separate spec and body in a CM environment, but whether
>>people *in practice* work this way.
>
>I don't think that's the issue.  If Ada people generally use a technique
>which is superior to what I do, I'd like to find a way to do it using
>Eiffel.  I don't care what people to in practice.  I'm here to learn
>and to hone my own skills.

Don't fight the language.  Something that's naturally expressable in one
language may be quite klunky in another.

You have to consider the features of a language in their _totality_.  Just
because a certain thing may be easier to do in language A than in B,
doesn't mean B is a lesser language than A because of it.  B may have many
other benefits not present in A, and to try to bend B to get that certain
thing, you can acually make B worse.

A designer or systems theorist will tell you to think holistically, and to
not be such a reductionist.

If you really want to hone your skills, then immerse yourself in a language
that uses a completely different paradigm.  Spend a few weeks or months
programming in a functional language or a logic language.

And you should care what others do "in practice."  You don't live on an
island, and so you have to work with other programmers.  Accept what the
standard practice is, because that will make it easier for others to read
and understand your code.  If you're doing a lot of idiomatic stuff, you're
going to be ostracised, even if your intentions are good.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <mheaney-ya023680000909970052480001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In article <EG7tIq.n0F@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
>Doyle) wrote:
>
>>I don't think that's the issue.  If Ada people generally use a technique
>>which is superior to what I do, I'd like to find a way to do it using
>>Eiffel.  I don't care what people to in practice.  I'm here to learn
>>and to hone my own skills.
>
>Don't fight the language.  Something that's naturally expressable in one
>language may be quite klunky in another.

Give me some credit.  :-)  I'm not going to force myself to use some
methodology which makes my life harder.

>You have to consider the features of a language in their _totality_.  Just
>because a certain thing may be easier to do in language A than in B,
>doesn't mean B is a lesser language than A because of it.  B may have many
>other benefits not present in A, and to try to bend B to get that certain
>thing, you can acually make B worse.
>
>A designer or systems theorist will tell you to think holistically, and to
>not be such a reductionist.

Woah, now you're reading more into my comment than I put there.  Plus,
you've move into name-calling.  I think this has gone far enough.

I just meant that I'm trying to learn methodologies from other people.
If those people use different tools, then I'd like to know how to do
what they do with my tools.  Clearly, if this turns out to be so
difficult as to offer no advantage, I won't end up doing it.  But I'm
still allowed to ask the question.

>If you really want to hone your skills, then immerse yourself in a language
>that uses a completely different paradigm.  Spend a few weeks or months
>programming in a functional language or a logic language.

Great idea.  Then, presumably, I'd take what I'd learned and apply
whatever I could to my old paradigm.  If it's not helpful, of course
I'd stop.

And in the mean time, I can still ask others in this newsgroup about
their methodologies and try to learn from them.

>And you should care what others do "in practice."  You don't live on an
>island, and so you have to work with other programmers.  Accept what the
>standard practice is, because that will make it easier for others to read
>and understand your code.  If you're doing a lot of idiomatic stuff, you're
>going to be ostracised, even if your intentions are good.

I think this stuff is pretty self-evident.  All I was trying to
say is that this discussion is not merely about what is done in
practice, because some of us would like to learn new things.

Clearly, I was a bit overzealous when I said I don't care what others
do in practice.  :-)

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <dewar.873725590@merv>, dewar@merv.cs.nyu.edu says...

>Note how significant it is that I make a simple request for anyone to 
>report in on how Eiffel would work together with a typical CM tool
>like Continuus or Clearcase to achieve this kind of separation.

This is a reasonable request.  I, too, find the lack of response interesting.

There are a number of possible reasons:

1: It can't be done, and the people who have tried it are lying low.

2: Its not actually necessary.

3: It can be done, but the people who are doing it are lying low.

4: It is necessary, but nobody is actually doing it.

I think we can discount (1).  It looks like a pretty simple problem,
and if people here had tried it and failed then I think they would 
have spoken up pretty quickly.

(2) is an interesting possibility.  Most organisations with configuration
control have some kind of test or inspection procedure before release.
Either of these would be sufficient to enforce the existing interface.
Tests would fail with changed interfaces, and inspectors would reject
changed interfaces precisely because they will break existing software.

(3) is also unlikely, for much the same reasons as (1).  Anyone with such a
system would have spoken up by now, and probably offered copies of the
scripts.

(4) is also possible.  If an organisation using Eiffel has sufficiently
chaotic CM processes then it will keep breaking existing software, and
generally fail to make progress.  They would also have a good motive to
keep quiet.  But I doubt that any language feature can rescue such an
organisation.

So in summary, I doubt that separate CM of interface and implementation
is that important.  The only requirement is that they can be examined
separately.

If I were running a multi-person Eiffel project I would put in CM
procedures, including test and inspection, which would check for changes
in interfaces.  If I were running a project with dozens of developers then
I might want something a little more formal.  CM of short forms plus
manual inspection of diffs before internal release would seem to be 
perfectly adequate.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Paul says

<<(2) is an interesting possibility.  Most organisations with configuration
control have some kind of test or inspection procedure before release.
Either of these would be sufficient to enforce the existing interface.
Tests would fail with changed interfaces, and inspectors would reject
changed interfaces precisely because they will break existing software.>>

This misses the point. That is like saying, never mind we don't need CM
at all, because our integration testing will catch any errors.

You cannot rely on test and inspection to catch errors. The whole point
of high quality software production procedures, such as are enforced
by typical ISO 9000 registrations, or high CMM level organizations, is
that every element of the production process is well controlled.

If lack of proper CM has allowed interfaces to wander, then who knows
what other resultant errors have been produced.

Perhaps the real truth is that there are not many organizations using
Eiffel for large critical programs. A simple question, does anyone know
of an organization using Eiffel that is a CMM level of 3 or higher, or
which has received ISO 9000 certification (I do not mean to imply that
these are the *only* valid measures, but they are indicative.

Re: Interface/Implementation (was Re: Design by Contract)

[Veli-Pekka Nousiainen]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.873952419@merv>...
> Paul says
> 
> <<(2) is an interesting possibility.  Most organisations with
configuration
> control have some kind of test or inspection procedure before release.
> Either of these would be sufficient to enforce the existing interface.
> Tests would fail with changed interfaces, and inspectors would reject
> changed interfaces precisely because they will break existing software.>>
> 
> This misses the point. That is like saying, never mind we don't need CM
> at all, because our integration testing will catch any errors.
> 
> You cannot rely on test and inspection to catch errors. The whole point
> of high quality software production procedures, such as are enforced
> by typical ISO 9000 registrations, or high CMM level organizations, is
> that every element of the production process is well controlled.
> 
> If lack of proper CM has allowed interfaces to wander, then who knows
> what other resultant errors have been produced.
> 
> Perhaps the real truth is that there are not many organizations using
> Eiffel for large critical programs. A simple question, does anyone know
> of an organization using Eiffel that is a CMM level of 3 or higher, or
> which has received ISO 9000 certification (I do not mean to imply that
> these are the *only* valid measures, but they are indicative.
> 
You got me ! Please, anybody - help. More info about CM & Eiffel !!! 
For what use it is to have the best of the world - DbC 
when rest of the quality is below that !?
> 

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <dewar.873952419@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>Paul says
>
>>is an interesting possibility.  Most organisations with configuration
>>control have some kind of test or inspection procedure before release.
>>Either of these would be sufficient to enforce the existing interface.
>>Tests would fail with changed interfaces, and inspectors would reject
>>changed interfaces precisely because they will break existing
>>software.
>
>This misses the point. That is like saying, never mind we don't need CM
>at all, because our integration testing will catch any errors.

No, I don't think it does.

>You cannot rely on test and inspection to catch errors.

I agree that automated trapping of errors is better (its one of the
reasons I like Eiffel).  I just raised the possibility that in practice
this particular catagory of error had not caused enough trouble to make
someone implement it.  The origin of this, if you recall, was that
someone had wondered why nobody was doing this.

>If lack of proper CM has allowed interfaces to wander, then who knows
>what other resultant errors have been produced.

Which is rather the point: does this lack of separate CM for interfaces
and implementation actually cause that much trouble in practice?

In another thread I was criticised for claiming that the theoretical
foundation for Eiffel exception handling made it superior to Ada
exception handling.  Now I'm being criticised for not recognising
separate interfaces as superior because they stem from another theory of
software engineering.  I agree that separate CM of interfaces is better,
but I wonder if it makes enough difference to be worth while
implementing.

Paul.

--------------------------------+---------------------------------
Paul Johnson                    | You are lost in a maze of twisty
Email: Paul@treetop.demon.co.uk | little standards, all different.
       paul.johnson@gecm.com    |

Re: Interface/Implementation (was Re: Design by Contract)

[Ken Garlington]

Paul Johnson wrote:
> 
> Which is rather the point: does this lack of separate CM for interfaces
> and implementation actually cause that much trouble in practice?

Certainly, poor CM for interface definitions is one of the primary
historical reasons for problems in the integration of large systems.
I can think of at least one specific example on my last project, where
two
organizations built to different versions of an interface specification,
and caused a problem that was not detected until the final system
integration. The resulting rework was expensive in both finances and
time.

> In another thread I was criticised for claiming that the theoretical
> foundation for Eiffel exception handling made it superior to Ada
> exception handling.  Now I'm being criticised for not recognising
> separate interfaces as superior because they stem from another theory of
> software engineering.  I agree that separate CM of interfaces is better,
> but I wonder if it makes enough difference to be worth while
> implementing.

I think there is sufficient practical experience that this is much
more than a theory.

> 
> Paul.
> 
> --------------------------------+---------------------------------
> Paul Johnson                    | You are lost in a maze of twisty
> Email: Paul@treetop.demon.co.uk | little standards, all different.
>        paul.johnson@gecm.com    |

Re: Interface/Implementation (was Re: Design by Contract)

[Robert S. White]

In article <dewar.873725590@merv>, dewar@merv.cs.nyu.edu says...

>Still it would be nice to have at least ONE concrete experience report
>that shows that the engineering details of this approach are practical.

  Sorry can't speak for an Eiffel example.  But IME   PCMS (LM F-22), 
DEC CMS and Rational CMVC do a nice job of controlling Ada spec's and
bodies.  But then as you point out the language itself does a good job
of seperating the interface from the implementation.  Note some of the 
compilers used with the CM software above allow the spec to be in the
same file as the body, but in practice we _never_ do that!  We do not
want to.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Interface/Implementation (was Re: Design by Contract)

[Matt Kennel (Remove 'NOSPAM' to reply)]

On Thu, 4 Sep 1997 22:44:51 GMT, W. Wesley Groleau:
:
:> In Ada, every single package must have a separate spec, so Ada
:> programmers are used to applying this pattern everywhere.  But I'd 
:> wager that very few Eiffel programmers would consider introducing an 
:> abstract parent class for every one of their concrete classes, just to 
:> simulate Ada packaging.  ....
:
:Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
:he/she could actually use Ada?  (And vice versa, lest anyone think
:I'm making another language-bigot comment...)

I agree. 

If few Eiffel programmers consider introducing an abstract parent class for
every one of their concrete classes, perhaps this is an indication that such
a thing is not generally needed or wanted --- merely for the purpose of
forcing a separate spec from every implementation?  Ada might have other
needs or uses for it. 

I suspect that Eiffel programmers have little reluctance introducing
abstract classes when they make sense as specification.

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[John Viega]

In article <slrn61bgd3.fkc.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:

> I agree. 
> 
> If few Eiffel programmers consider introducing an abstract parent class for
> every one of their concrete classes, perhaps this is an indication that such
> a thing is not generally needed or wanted --- merely for the purpose of
> forcing a separate spec from every implementation?  Ada might have other
> needs or uses for it. 
> 
> I suspect that Eiffel programmers have little reluctance introducing
> abstract classes when they make sense as specification.

Don't consider what I have to say hard evidence, but from what I have
seen in C++ programmers, they are less likely to seperate interface
from implementation by useing purely abstract classes than say a Java
programmer, because it just never occurs to most of them to do so.
Many such people consider themselves to be excellent OO designers,
too.  I have seen such people write in Java, appreciate the explicit
interface construct, use it extensively, and then go back to their
same old habits when they return to C++.

From what I've seen, even Java programmers rarely have an interface
that maps to every concrete class they write.

Re: Interface/Implementation (was Re: Design by Contract)

[Matt Kennel (Remove 'NOSPAM' to reply)]

On 10 Sep 1997 16:57:20 GMT, John Viega <jtv2j@cobra.cs.virginia.edu> wrote:
:
:In article <slrn61bgd3.fkc.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:
:
:> 
:> I suspect that Eiffel programmers have little reluctance introducing
:> abstract classes when they make sense as specification.
:
:Don't consider what I have to say hard evidence, but from what I have
:seen in C++ programmers, they are less likely to seperate interface
:from implementation by useing purely abstract classes than say a Java
:programmer, because it just never occurs to most of them to do so.
:Many such people consider themselves to be excellent OO designers,
:too.  I have seen such people write in Java, appreciate the explicit
:interface construct, use it extensively, and then go back to their
:same old habits when they return to C++.

I can see this, and I think the Eiffel practice and cleanliness is closest
to the Java side than the C++ side. 

:From what I've seen, even Java programmers rarely have an interface
:that maps to every concrete class they write.

That may be the case.  Some people might consider this foolish laziness, but
I'm not so convinced.  It may in fact be a recognition that not every concrete
class deserves a separate interface. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <340F20A0.49B5@ac3i.dseg.ti.com>,
John G. Volan <johnv@ac3i.dseg.ti.com> wrote:
>
>Well, one problem with using abstract/deferred classes as a simulation
>for separate interfaces, is that the former might do _too much_. You
>wind up getting polymorphic dynamic dispatching in situations that don't
>really call for it.  This can result in an unnecessary run-time
>performance penalty when a given program includes only one concerete
>implementation class for a given abstract class (unless your programming
>environment is able to detect and optimize this situation).

The only time when dynamic dispatching can be avoided is when the
call is not polymorphic.  If it is polymorphic, then the compiler
can still optimize it anyway, so we haven't lost anything in this
department.

>In Ada, every single package must have a separate spec, so Ada
>programmers are used to applying this pattern everywhere.  

But is it really necessary everywhere?  Or just where interfaces
need to be frozen?

>But I'd wager
>that very few Eiffel programmers would consider introducing an abstract
>parent class for every one of their concrete classes, just to simulate
>Ada packaging.  I'd assume that abstract/deferred classes appear in
>typical Eiffel programs just as frequently as abstract tagged types do
>in Ada95 programs, and that they typically serve the same role:
>implementing generalization/specialization hierarchies. 

I'd tend to agree.  Using abstract parent classes in this manner
is a very important usage.  Using them to freeze an interface is
another important usage.

>So I don't see abstract classes as a very good mapping for Ada package
>specs, and I agree with those who compare Ada specs to Eiffel short
>forms.

I've argued before that an Eiffel short form is just an abstract
parent class generated after the fact.  So if Ada specs compare with
Eiffel short forms, then they compare with abstract parent classes.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Franck Arnaud]

John G. Volan:

> This can result in an unnecessary run-time performance penalty when 
> a given program includes only one concerete implementation class for 
> a given abstract class (unless your programming environment is able 
> to detect and optimize this situation).

All Eiffel compilers do that optimisation (and they have to as any
routine could be polymorphic).

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EFv7yL.yr@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>:>> >More to the point: not _relevant_ in the Ada case as this is handled
:>:>> >by a different orthogonal capability 
:>
:>Agree. Multiple, polymorphic implementations are provided by deferred classes
:>and abstract types in Eiffel and Ada respectively. As Jon says, this is an 
:>orthogonal concept to interfaces.
:
:Thanks, but I didn't say that.  I think Jon said it.

Yes, he did and I was aware of it. I admit my attribution wasn't clear.

:>:>> using a deferred class is more powerful than a simple interface
:>:>> file, and can accomplish all the same things, so why split
:>:>> this into two concepts?
:>
:>Because they serve different purposes. (See my previous post).
:
:But the deferred class can serve both purposes, can't it?

Not in the Ada or Modula sense of the term "interface". I expect the situation 
is made somewhat confusing by different nomenclature. Equating Eiffel deferred
classes with Java "interfaces" may make sense, for example. (Not sure as 
I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
(which is the context of this discussion - separate interface and implementation), 
deferred classes are not the correct analogue. 

For example, consider an effective class which inherits only from effective 
classes. There is no deferred class in this situation, so you obviously can't 
use one as an interface. But, clearly, the class *does* have an interface and
we see it exists as the short form. I dismiss as nonsensical the notion that 
a deferred class can be the analogue in one situation and the short form in 
another.

Also, this example shows that it's false to claim that deferred classes can do 
all that separate interfaces (or short forms) can do. 

Something that may further help to cement the difference is to consider that 
a deferred class has a short form and hence has an interface in the Ada/Modula
sense. If the deferred class itself is an interface, how can it also have 
its *own* interface? This would be a meta-interface - a nonsensical concept.
The fact that it *does* legitimately have an interface suggests that it isn't 
an interface in the first place in the Ada/Modula sense.

I think the key to getting a handle on this is to recognise that short forms 
and deferred classes serve different, *non-overlapping* purposes.

:>Try thinking along the lines of
:>
:>  a) Ada interfaces correspond to Eiffel short forms, and
:>  b) Ada abstract types correspond to Eiffel deferred classes.
:
:Yes, I'm aware that there is an analogy there.  

Okay.

:But I think the analogy is granted too much weight in terms of its importance 
:to programming.
:
:It's my position (until further enlightenment :-) that abstract/
:deferred classes can do what separate interfaces do, and more, so
:why do we need separate interfaces?

A few things here..

First, deferred classes *can't* do everything a short form (or separate 
interface) can do - see our example above.

Second, they serve a different purpose completely unrelated to interface 
specification (in the Ada/Modula sense) so are irrelevant to the separate
interface - implementation issue.

Third, if we compare the mechanisms that *are* relevant to this issue -
Eiffel short form and Ada package specs - we can see that we don't need 
separate interfaces. (I won't repeat what others have already covered.) 
In other words, I agree that we don't need separate interfaces, but disagree 
with your reasoning.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <EFyK17.2wD@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>Patrick Doyle wrote:
>
>:In article <EFv7yL.yr@syd.csa.com.au>,
>:Don Harrison <nospam@thanks.com.au> wrote:
>:>
>:>Because they serve different purposes. (See my previous post).
>:
>:But the deferred class can serve both purposes, can't it?
>
>Not in the Ada or Modula sense of the term "interface". I expect the situation 
>is made somewhat confusing by different nomenclature. Equating Eiffel deferred
>classes with Java "interfaces" may make sense, for example. (Not sure as 
>I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
>(which is the context of this discussion - separate interface and implementation), 
>deferred classes are not the correct analogue. 

  Ok, let's boil this down to two questions:

1. What is the purpose of short forms/Ada interfaces?
2. Why can't deferred classes accomplish this purpose?

>For example, consider an effective class which inherits only from effective 
>classes. There is no deferred class in this situation, so you obviously can't 
>use one as an interface. But, clearly, the class *does* have an interface and
>we see it exists as the short form. I dismiss as nonsensical the notion that 
>a deferred class can be the analogue in one situation and the short form in 
>another.

Well, before you dismiss it, let me make a case for a very similar
situation...

If you want to look at the whole interface of a class, you can use
Eiffel's "short" tool to extract it.  What the short tool produces is
code which is, effectively, the deferred class which would correspond
to the effective class in question (except that it is missing the
word "deferred" in certain places).

So if you want to specify an interface, use a deferred class.  If you
already have an effective class and want to see its interface, you
can simply look at its deferred parent class (if it was designed with
one) or, failing that, the "short" tool can rig one up for you.

>Also, this example shows that it's false to claim that deferred classes can do 
>all that separate interfaces (or short forms) can do. 

I haven't yet seen you describe just what an interface or short form *does*.

>Something that may further help to cement the difference is to consider that 
>a deferred class has a short form and hence has an interface in the Ada/Modula
>sense. If the deferred class itself is an interface, how can it also have 
>its *own* interface? This would be a meta-interface - a nonsensical concept.

I think this still makes sense.  The short form is only missing the
word "deferred" (and some other trivial syntactical niceties) in the
appropriate places.  Add these back in, and the resulting deferred
class is exactly the same as the original class.  Thus, the class *is*
its interface.  

I could create a DoyleShort tool which produces the same thing as the
Short tool, except with the "deferred" etc. in the appropriate places.
If I follow your reasoning, the Short tool's output would then correspond
to an Ada interface, while DoyleShort's output would correspond to an
abstract package (is that the term?) in Ada.  Yet the only difference
is the word "deferred".  How can such a trivial difference make the
two concepts orthogonal?

>The fact that it *does* legitimately have an interface suggests that it isn't 
>an interface in the first place in the Ada/Modula sense.

Unless the interface is identical to the class itself.

>I think the key to getting a handle on this is to recognise that short forms 
>and deferred classes serve different, *non-overlapping* purposes.

I'm ready to accept this if someone would just tell me what these purposes
are.

>:It's my position (until further enlightenment :-) that abstract/
>:deferred classes can do what separate interfaces do, and more, so
>:why do we need separate interfaces?
>
>A few things here..
>
>First, deferred classes *can't* do everything a short form (or separate 
>interface) can do - see our example above.

I'm sorry--it's been a long day--but I didn't see you explain what
short forms or interfaces *do* at all.

>Second, they serve a different purpose completely unrelated to interface 
>specification (in the Ada/Modula sense) so are irrelevant to the separate
>interface - implementation issue.
>
>Third, if we compare the mechanisms that *are* relevant to this issue -
>Eiffel short form and Ada package specs - we can see that we don't need 
>separate interfaces. (I won't repeat what others have already covered.) 
>In other words, I agree that we don't need separate interfaces, but disagree 
>with your reasoning.

Well, thanks for your patient attempts to persuade me :-) but I'm still
a bit puzzled...

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EFyK17.2wD@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>Patrick Doyle wrote:
:>
:>:In article <EFv7yL.yr@syd.csa.com.au>,
:>:Don Harrison <nospam@thanks.com.au> wrote:
:>:>
:>:>Because they serve different purposes. (See my previous post).
:>:
:>:But the deferred class can serve both purposes, can't it?
:>
:>Not in the Ada or Modula sense of the term "interface". I expect the situation 
:>is made somewhat confusing by different nomenclature. Equating Eiffel deferred
:>classes with Java "interfaces" may make sense, for example. (Not sure as 
:>I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
:>(which is the context of this discussion - separate interface and implementation), 
:>deferred classes are not the correct analogue. 
:
:  Ok, let's boil this down to two questions:
:
:1. What is the purpose of short forms/Ada interfaces?

To provide visibility information to a client and the compiler about a class's 
exported features. That is, it documents the client relation.

By comparison, the purpose of deferred classes is to specify what functionality 
will be provided by descendants of a class. That is, it documents the inheritance
relation. This purpose is orthogonal to that of visibility. We may declare, for
example, a deferred class which exports nothing. Such a class doesn't have 
much of client relation with client classes but does have an inheritance relation
with its descendants.

:2. Why can't deferred classes accomplish this purpose?

The issue is clouded a bit by the fact that deferred classes *contain* 
visibility information. So, if you attempt to emulate Ada package specs using
deferred classes, you're not using deferred classes per se to do it, but their
export aspects. 

:>For example, consider an effective class which inherits only from effective 
:>classes. There is no deferred class in this situation, so you obviously can't 
:>use one as an interface. But, clearly, the class *does* have an interface and
:>we see it exists as the short form. I dismiss as nonsensical the notion that 
:>a deferred class can be the analogue in one situation and the short form in 
:>another.
:
:Well, before you dismiss it, let me make a case for a very similar
:situation...
:
:If you want to look at the whole interface of a class, you can use
:Eiffel's "short" tool to extract it.  What the short tool produces is
:code which is, effectively, the deferred class which would correspond
:to the effective class in question (except that it is missing the
:word "deferred" in certain places).

I disagree, the short form is not code, but documentation. As such, they 
can't be regarded as the same thing. 

[..]

:>Also, this example shows that it's false to claim that deferred classes can do 
:>all that separate interfaces (or short forms) can do. 
:
:I haven't yet seen you describe just what an interface or short form *does*.

See above.

:>Something that may further help to cement the difference is to consider that 
:>a deferred class has a short form and hence has an interface in the Ada/Modula
:>sense. If the deferred class itself is an interface, how can it also have 
:>its *own* interface? This would be a meta-interface - a nonsensical concept.
:
:I think this still makes sense.  The short form is only missing the
:word "deferred" (and some other trivial syntactical niceties) in the
:appropriate places.  Add these back in, and the resulting deferred
:class is exactly the same as the original class.  Thus, the class *is*
:its interface.  

I think there are some non-trivial, semantic niceties that make a difference. :)

[..]

:Well, thanks for your patient attempts to persuade me :-) but I'm still
:a bit puzzled...

Hope this has helped.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> I disagree, the short form is not code, but documentation. As such, 
> they can't be regarded as the same thing.

In Ada, a package spec is code AND documentation.  It is, in a way, 
a contract with all clients of the package, and a precondition for
the implementation.  However, in Eiffel, since the short form comes
FROM the implementation, "documentation" is a good word.  In Ada,
since the specification conceptually precedes and constrains the
implementation, the word we've chosen--specification--is more 
precise than the broader "documentation."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Veli-Pekka Nousiainen]

W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote in article
<3415B700.1088@pseserv3.fw.hac.com>...
> 
> > I disagree, the short form is not code, but documentation. As such, 
> > they can't be regarded as the same thing.
> 
> In Ada, a package spec is code AND documentation.  It is, in a way, 
> a contract with all clients of the package, and a precondition for
> the implementation.  However, in Eiffel, since the short form comes

That is not the way I create my interfaces in Eiffel. 
I succest that you try EiffelCase and forward engineering. 
See what it generates from your detail design. 
Apply then 'short' and compare the results. Suprise might follow... 
VP 

> FROM the implementation, "documentation" is a good word.  In Ada,
> since the specification conceptually precedes and constrains the
> implementation, the word we've chosen--specification--is more 
> precise than the broader "documentation."
> 
> -- 
> ----------------------------------------------------------------------
>     Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
> Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
>                     wwgrol AT pseserv3.fw.hac.com
> 
> Don't send advertisements to this domain unless asked!  All disk space
> on fw.hac.com hosts belongs to either Hughes Defense Communications or 
> the United States government.  Using email to store YOUR advertising 
> on them is trespassing!
> ----------------------------------------------------------------------
> 

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Veli-Pekka Nousiainen wrote:
> That is not the way I create my interfaces in Eiffel.
> I succest that you try EiffelCase and forward engineering.
> See what it generates from your detail design.
> Apply then 'short' and compare the results. Suprise might follow...
> VP

This might well be a compelling argument, if everyone working
in Ada had EiffelCase available and knew your methods.

Since we don't, if you want to convince us, you'll have to
describe the tool, the method, and the results.

Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

(Sorry for not responding to you earlier. I wasn't ignoring you - just 
short on time.)

W. Wesley Groleau wrote:

:> I disagree, the short form is not code, but documentation. As such, 
:> they can't be regarded as the same thing.
:
:In Ada, a package spec is code AND documentation.  It is, in a way, 
:a contract with all clients of the package, and a precondition for
:the implementation.  

Agree. The use of "precondition" is a bit loose, however..

:However, in Eiffel, since the short form comes
:FROM the implementation, "documentation" is a good word. 

Some of us in this thread have associated Ada package specs with Eiffel short
forms. This is not strictly true. More accurate may be:

  - The human readable view of package specs is analogous to the short 
    form (hence my use of the term documentation), and

  - The software client view of package specs is analogous to the interface
    embedded in the class text, loosely called the class implementation.
    (This embedded interface is what is extracted to become the short form.)

Why bother making this distintion? Because the ability of software clients 
to use a class doesn't depend on whether a short form has been generated
but on the existence of the embedded interface. These two aspects of clientship 
which are combined in Ada are separated in Eiffel. 

Further, considering that an Eiffel class designer establishes the client 
aspects of a class first (conceiving the (embedded) interface), and then 
proceeds to implement it (probably first in stubbed form), we see that rather 
than the interface trailing the implementation, it precedes it, as in Ada.

Consequently, I disagree with John Volan's observation..

:.. Eiffel treats the notion of
:an "interface-only view of a class which describes its contract" as
:something of an afterthought.


Due to the fact that the short form is always generated from the class text,
there is a slight advantage in this approach:

  - The system is always executable, even if only with stubbed bodies. 
    Yes, I know you can generate such stubs with Ada tools, but..

  - Humans can generate more meaningful stubs, returning sensible default 
    values - zero rather than Integer'First, for example.


:In Ada, since the specification conceptually precedes and constrains the
:implementation, the word we've chosen--specification--is more 
:precise than the broader "documentation."

Strictly speaking, you could say Eiffel short forms *document* the 
specification - they are not the specification itself. The specification
is embedded in the class text and that's what is used by the compiler.

This is why I think it's important for an Eiffel environment to be able to 
freeze that embedded specification. As any Ada programmer knows, this is 
crucial in a team environment.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <EG7zJn.366@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>
>Patrick Doyle wrote:
>
>:  Ok, let's boil this down to two questions:
>:
>:1. What is the purpose of short forms/Ada interfaces?
>
>To provide visibility information to a client and the compiler about a class's 
>exported features. That is, it documents the client relation.

Ok, I agree with that.

>By comparison, the purpose of deferred classes is to specify what functionality 
>will be provided by descendants of a class. 

...which includes visibility information.  (Just for the record.  :-)

>That is, it documents the inheritance
>relation. This purpose is orthogonal to that of visibility. 

I think this seems to be using a pretty loose definition of "orthogonal".

Inheritance can be inheritance of interface and/or inheritance of
implementation.  Interface inheritance means inheriting visibility
information.

Orthogonal means that anything achieved using one technique cannot
be achieved using the other.  But specifying implementation (ie.
the client relationship) can be accomplished by inheritance, so I'm
not clear on how these are orthogonal.  (Perhaps I'm mistaken about
what "orthogonal" means?  I'm going on recollections of a book I
read a while back.)

>We may declare, for
>example, a deferred class which exports nothing. Such a class doesn't have 
>much of client relation with client classes but does have an inheritance relation
>with its descendants.

Couldn't you also have an empty package spec?

>:2. Why can't deferred classes accomplish this purpose?
>
>The issue is clouded a bit by the fact that deferred classes *contain* 
>visibility information. So, if you attempt to emulate Ada package specs using
>deferred classes, you're not using deferred classes per se to do it, but their
>export aspects. 

Ok.  I'll go for that, because my argument all along has been that
abstract superclasses can do as much as *and more than* Ada specs.
So let's consider just the export aspects of an abstract class.  Is
there anything that they can't do which Ada specs can do?

>:If you want to look at the whole interface of a class, you can use
>:Eiffel's "short" tool to extract it.  What the short tool produces is
>:code which is, effectively, the deferred class which would correspond
>:to the effective class in question (except that it is missing the
>:word "deferred" in certain places).
>
>I disagree, the short form is not code, but documentation. As such, they 
>can't be regarded as the same thing. 

The Short tool could very easily be modified to put the word "deferred"
in the right places and produce actual code.  Does this change so
fundamentally alter the resulting file that they are now "orthogonal"
to each other?  IMO clearly it doesn't.

>:I think this still makes sense.  The short form is only missing the
>:word "deferred" (and some other trivial syntactical niceties) in the
>:appropriate places.  Add these back in, and the resulting deferred
>:class is exactly the same as the original class.  Thus, the class *is*
>:its interface.  
>
>I think there are some non-trivial, semantic niceties that make a difference. :)

Ok, we can agree to disagree on this, but either way, it seems to me
that the fact remains that there's nothing that Ada specs can do that
Eiffel's deferred classes can't do.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Patrick Doyle (doylep@ecf.toronto.edu) wrote:
> Ok.  I'll go for that, because my argument all along has been that
> abstract superclasses can do as much as *and more than* Ada specs.
> So let's consider just the export aspects of an abstract class.  Is
> there anything that they can't do which Ada specs can do?

How do you prevent that the implemented class derived from an abstract
specification class can add public methods to those mentioned in that
abstract class? Using Ada we have just two possibilities for add-ons:
   1.) Create a child package and thus gain full access to the internals
       of a class.
   2.) Create a new package and derive a new class from the former one or
       define classwide methods. All you can do now are overriding
       existing operations and use the methods exported by the former
       package.
Also do not forget that Ada packages often contain more than one class
declaration.

By the way: I would like to hear from anyone who uses ClearCase along with
Eiffel, too. Or is the usual development environment already multi-user,
multi-platform capable?

Yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <34167245.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>
>Patrick Doyle (doylep@ecf.toronto.edu) wrote:
>> Ok.  I'll go for that, because my argument all along has been that
>> abstract superclasses can do as much as *and more than* Ada specs.
>> So let's consider just the export aspects of an abstract class.  Is
>> there anything that they can't do which Ada specs can do?
>
>How do you prevent that the implemented class derived from an abstract
>specification class can add public methods to those mentioned in that
>abstract class? 

Close, but IMO no cigar.  If we are faithfully to compare Ada and
Eiffel ways of doing this, then just as an Ada package is accessed
through its interface, so would the Eiffel class be accessed only
through the abstract superclass.  Thus, even if the subclass
added public features, the client couldn't use them.

Besides, it's hard to see how the ability to extend the interface
would be a liability anyway.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Matt Austern]

doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Close, but IMO no cigar.  If we are faithfully to compare Ada and
> Eiffel ways of doing this, then just as an Ada package is accessed
> through its interface, so would the Eiffel class be accessed only
> through the abstract superclass.  Thus, even if the subclass
> added public features, the client couldn't use them.

Except that that's impossible.  You have to know the name of the
derived class, and the signatures of its creation functions, in order
to create objects of that class.  So the interface of the derived
class cannot be completely hidden.

(Or, alternatively, you could have a third class, a "factory" class,
that exists only to create instance of the derived implementation
class.  In that case, you could hide the derived class completely.
Even so, though, you would have to know the interfaces of at least two
classes; the abstract base class does not suffice.  And note that
Eiffel doesn't let you use this method for expanded classes or
objects.)

The bottom line: inheritance is useful for some purposes, but it is
not a panacea.  Base-derived semantics is not at all the same as
interface-implementation semantics.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <fxtiuw7ert4.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:

> The bottom line: inheritance is useful for some purposes, but it is
> not a panacea.  Base-derived semantics is not at all the same as
> interface-implementation semantics.

Absolutely!  And I find it rather stunning that some here can't twig
this fact (yes, this particular bit is objective fact).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <fxtiuw7ert4.fsf@isolde.mti.sgi.com>,
Matt Austern  <austern@isolde.mti.sgi.com> wrote:
>
>doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Close, but IMO no cigar.  If we are faithfully to compare Ada and
>> Eiffel ways of doing this, then just as an Ada package is accessed
>> through its interface, so would the Eiffel class be accessed only
>> through the abstract superclass.  Thus, even if the subclass
>> added public features, the client couldn't use them.
>
>Except that that's impossible.  You have to know the name of the
>derived class, and the signatures of its creation functions, in order
>to create objects of that class.  So the interface of the derived
>class cannot be completely hidden.

Right, we can't create an object without using its creation features.
Beyond that, we can go through the abstract interface.

The trouble is, I don't know if what I just said makes sense, because
I can't imagine a reason to want to restrict interface extension.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Joerg Rodemann wrote:
> How do you prevent that the implemented class derived from an abstract
> specification class can add public methods to those mentioned in that
> abstract class?

Why should I want to do that?
(I could think of some situations where such a restriction might be
useful, but these are rather exotic.)

In what ways is the Ada way of doing that useful?

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Joachim Durchholz (joachim.durchholz@munich.netsurf.de) wrote:
> Joerg Rodemann wrote:
> > How do you prevent that the implemented class derived from an abstract
> > specification class can add public methods to those mentioned in that
> > abstract class?

> Why should I want to do that?
> (I could think of some situations where such a restriction might be
> useful, but these are rather exotic.)

> In what ways is the Ada way of doing that useful?

Because this is the essence of the spec/impl concept in languages as Ada,
Modula, the older Oberon dialects. The spec is a _complete_ specification
of everything that is exported. Well, in Ada this might be a bit obscured
by the fact that the full type and some other things have to be mentionened
in the 'private' part of the spec. But at least I understand the reason for
this decision and can life with it. On the other hand: I never understood,
why Wirth switched from the two file variant to a all-in-one solution.
Sure, it makes sense if you take into account the whole Oberon environ-
ment --- they have some really astonishing features --- but I still think
the language itself lost an important thing. (And there where lots of points
I did not like that environment also. But that's a different story.)

Well, since it was mentionened by someone else: one thing as important
as a complete spec of a package/module (perhaps class/interface) is in
my opinion a list of those things that are imported. Of course, if the
language is completely class oriented there are no name ambiguities but
I often liked to know what packages are directly relevant to a specific
package. This often gives an insight-at-a-glance what mechanisms are used.
To return to the spec issue: IMHO there should be only included those
things that are important to the spec. The body might have a much longer
'IMPORT' list.

Regards

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Interface/Implementation (was Re: Design by Contract)

[Robert S. White]

In article <EG9wrJ.F3t@ecf.toronto.edu>, doylep@ecf.toronto.edu says...
>
>In article <EG7zJn.366@syd.csa.com.au>,
>Don Harrison <nospam@thanks.com.au> wrote:
>>
>>By comparison, the purpose of deferred classes is to specify what 
>>functionality will be provided by descendants of a class. 
>
>...which includes visibility information.  (Just for the record.  :-)
>
>>That is, it documents the inheritance
>>relation. This purpose is orthogonal to that of visibility. 
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I think this seems to be using a pretty loose definition of "orthogonal".

   Don seems to be using the word orthogonal in a common usage i.e "right 
angles" per the root of the Greek word "orthos" (straight, regular, upright, 
correct, standard).

>Inheritance can be inheritance of interface and/or inheritance of
>implementation.  Interface inheritance means inheriting visibility
>information.
>
>Orthogonal means that anything achieved using one technique cannot
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>be achieved using the other.  But specifying implementation (ie.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the client relationship) can be accomplished by inheritance, so I'm
>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>what "orthogonal" means?  I'm going on recollections of a book I
>read a while back.)

  I just now went back to Webster's New Universal Unabridged (not quite
the OED?) but fairly long for its 2000+ pages.  Seems to me that your
definition of orthogonal is a bit restrictive.  In the context of 
Don's use it seems the word orthogonal is being used to say that the 
reason behind the functionality purpose is at "right angles" to that 
of the visibility purpose.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert S. White wrote:

:   Don seems to be using the word orthogonal in a common usage i.e "right 
:angles" per the root of the Greek word "orthos" (straight, regular, upright, 
:correct, standard).

[..]

:In the context of 
:Don's use it seems the word orthogonal is being used to say that the 
:reason behind the functionality purpose is at "right angles" to that 
:of the visibility purpose.

Yes, that's what I mean. 

Just quietly, my understanding of the word in the CS sense is gleaned solely 
from its (mis)use on Usenet. So, if I got it wrong, I can, at least, blame 
someone else. :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

doyle says

<<>Inheritance can be inheritance of interface and/or inheritance of
>implementation.  Interface inheritance means inheriting visibility
>information.
>
>Orthogonal means that anything achieved using one technique cannot
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>be achieved using the other.  But specifying implementation (ie.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the client relationship) can be accomplished by inheritance, so I'm
>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>what "orthogonal" means?  I'm going on recollections of a book I
>read a while back.)>>


The word orthogonal came into common usage in programming languages from
the Algol-68 design, where AVW coined the use of the term to describe
features of a programming language that are essentially independent from
a semantic point of view.

The principle of orthogonality says that if two features are orthogonal,
then you can derive the semantics of the interaction of the two features
from the semantics of the individual features (much as you can derive
a position in 3 space, from independnet rules and knowledge about its
position in each separate dimension.

Words can of course mean anything you want (reference: Alice in Wonderland),
but it is usual in discussions about programming languages to adopt
AVW's usage.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <5v7mhr$meo$2@flood.weeg.uiowa.edu>,
Robert S. White <nospam@somewhere.ia.us> wrote:
>In article <EG9wrJ.F3t@ecf.toronto.edu>, doylep@ecf.toronto.edu says...
>>
>>Orthogonal means that anything achieved using one technique cannot
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>be achieved using the other.  But specifying implementation (ie.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>the client relationship) can be accomplished by inheritance, so I'm
>>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>>what "orthogonal" means?  I'm going on recollections of a book I
>>read a while back.)
>
>  I just now went back to Webster's New Universal Unabridged (not quite
>the OED?) but fairly long for its 2000+ pages.  Seems to me that your
>definition of orthogonal is a bit restrictive.  In the context of 
>Don's use it seems the word orthogonal is being used to say that the 
>reason behind the functionality purpose is at "right angles" to that 
>of the visibility purpose.

  You must admit that this "right-angles" definition can't be applied
literally to programming languages.  It makes the definition very
vague and subject to interpretation.

  So let's look for an analogy.  In mathematics, two vectors are
orthogonal if their scalar product is zero.  It's not enough that
they're linearly independent.  Any n linearly independent vectors
will span n-space, but that doesn't make them orthogonal.

  Likewise, simply because every desirable objective can be expressed
as a combination of two (or more) features doesn't make them orthogonal.
That just makes them linearly independent.  To be orthogonal, as you
say, implies that they're at "right angles", so that they go in two
unrelated directions.  

  With vectors, if we want to move in the direction of one vector,
it will not help to move in the direction of an orthogonal vector.
It will not progress you whatsoever in the direction you desire.
Likewise, using one feature of a language should not take you in the
"direction" of an orthogonal language feature.

  So in summary, it's not enough that the entire "program space"
can be spanned by a set of features--that just makes them linearly
independent.  It's necessary that these features go in unrelated
directions, so that one cannot accomplish what another can.

  Also, I just remembered where I read this definition.  It was in
Object-Oriented Type Systems, by Palsberg and Schwartzbach.  So
I'm not alone in this.  :-)

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Ok.  I'll go for that, because my argument all along has been that
> abstract superclasses can do as much as *and more than* Ada specs.
> So let's consider just the export aspects of an abstract class.  Is
> there anything that they can't do which Ada specs can do?

Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
different interfaces.  These can be abstract and/or concrete.

You're earlier remark about not saying anything more on this until
you've read up on the relevant Ada bits seems really apropos...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Sep11211209@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Ok.  I'll go for that, because my argument all along has been that
>> abstract superclasses can do as much as *and more than* Ada specs.
>> So let's consider just the export aspects of an abstract class.  Is
>> there anything that they can't do which Ada specs can do?
>
>Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
>different interfaces.  These can be abstract and/or concrete.

An abstract class could have some concrete features.  Is that
similar?

>You're earlier remark about not saying anything more on this until
>you've read up on the relevant Ada bits seems really apropos...

You're right that I should be more experienced with Ada, but I'll
have to disappoint you on the "not saying anything more" front. :-)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Brian Rogoff]

On Sat, 13 Sep 1997, Patrick Doyle wrote:
> In article <JSA.97Sep11211209@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >
> >In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
> >
> >> Ok.  I'll go for that, because my argument all along has been that
> >> abstract superclasses can do as much as *and more than* Ada specs.
> >> So let's consider just the export aspects of an abstract class.  Is
> >> there anything that they can't do which Ada specs can do?
> >
> >Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
> >different interfaces.  These can be abstract and/or concrete.
> 
> An abstract class could have some concrete features.  Is that
> similar?

No. I don't want to second-guess Jon, but one of the things you can do in 
Ada is have a (generic package) spec with no body. Read the Ada Rationale, 
in particular 12.6, for examples. After you understand this, we can discuss 
the similarities and differences between package specs and abstract classes 
at a higher level.

> You're right that I should be more experienced with Ada, but I'll
> have to disappoint you on the "not saying anything more" front. :-)

That's fine, just don't expect anyone to take what you are saying seriously 
until you've read the (easily and freely available) description of Ada 95. 
BTW, where is the free version of OOSC II that I can peruse for these 
discussions? ;-).

-- Brian

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <3404909F.2C67412E@eiffel.com>,
Bertrand Meyer  <Bertrand.Meyer@eiffel.com> wrote:
>
>The goals are clear:

  I agree with most of these goals, but I have an issue with one
of them:

>        G5. Minimize the programmer's work. In particular
>            it is crucial to avoid forcing the programmer
>            to duplicate text. Duplication is almost always
>            bad, especially with respect to ease of maintenance,
>            one of the central goals of software engineering.
>            It also hampers reuse, reliability (when you
>            duplicate code, you duplicate its bugs, and
>            the more software you write the more likely
>            it is that it will include bugs), and ease
>            of change.

  Of course duplication is bad, but this is a special case which
is not nearly so bad.  These, if I understand, are your reasons
for disliking code duplication:

 1. Too much typing
 2. Duplicate code duplicates bugs
 3. More code means more bugs
 4. Too hard to change

  Here's why I don't think any of these are serious problems here:

 1. The same tools which provide interface files for documentation
   in Eiffel could provide them for compiler usage in another
   language, so there is no more typing than in the Eiffel approach.

 2. This is true, but is no more a problem than a single bug in this
   case because if the bug is fixed in one place, the compiler will
   force us to fix it in the other place.

 3. Certainly, given two independent code fragments, the total
   expected number of bugs would be greater than that of a single
   fragment.  But in this case, the fragments are not independent:
   if the implementation (which includes the interface) is bug-free,
   then so is the interface.  If the interface has a bug, then so
   does the implementation; but this is really one bug as argued
   in #2.  So by adding an interface file, we haven't added any
   extra potential for bugs.

 4. The interface of a class is the part that the rest of the
   system relies on.  Perhaps it should be hard to change.  I
   think there is merit in making a programmer aware that certain
   changes could have repercussions outside the module in
   question.  So, while true, point #4 may not be a problem at all.

Having said all that, I'm not particularly in favour of one method
over the other.  To me, it seems like a very minor issue compared
with the complexities programmers have to deal with.  I don't
think the one-file-versus-two issue has any real lasting effects
on the development process.

One last argument...

In Eiffel, a short form can be produced for documentation.  Why not
give the compiler the capability to ensure that the short form
matches the code being compiled?  And if we do that, aren't we
back to the separate-interface-file model again?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Patrick Doyle wrote:
> Bertrand Meyer  <Bertrand.Meyer@eiffel.com> wrote:
> >The goals are clear:
> 
>   I agree with most of these goals, but I have an issue with one
> of them:

I'm still looking at them (actually, waiting for enough free time)
but I also disagree for similar reasons with this one:

> >        G5. Minimize the programmer's work. .....
>              ..... Duplication is almost always
> >            bad, especially with respect to ease of maintenance,
> >            one of the central goals of software engineering.
> >            It also hampers reuse, reliability (when you
> >            duplicate code, you duplicate its bugs, and
> >            the more software you write the more likely
> >            it is that it will include bugs), and ease
> >            of change.

>  1. Too much typing
>  4. Too hard to change

This is what a C bigot would say.  An Ada bigot (indeed, everyone
on the Ada side of the average) would say, "Absolutely not an issue"
(1) & (4) are almost the same, but discouraging change (4) in a SPEC 
(interface) is a Good Thing.

>  2. Duplicate code duplicates bugs
>  3. More code means more bugs

Both of these are incorrect in this case.  A bug that is repeated
is still only one bug  IF  it is repeated in the parts of the 
spec/body that are required to conform by the language.

I could add another argument that others have already offered:

5. A corollary of Murphy's law is that duplicate information
   will inevitably become non-duplicate.

This argument is applicable in C, where header files can easily
not match the implementation, yet still compile.  It does not
apply to Ada specs and bodies, since duplication that is required
is compiler-enforced to be a perfect match.  You can't even 
deviate as much as

  spec:

      Proc ( X : Pkg.X_Type );

  body:

      package P renames Pkg;

      Proc ( X : P.X_Type ) is ...

And duplication that is not required is not allowed (such as
redeclared variables).
-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:

: Here is the reasoning behind the Eiffel approach to
: separating interface from implementation. It was designed
: in full knowledge of the Modula-2/Ada-83 mechanisms, in an
: attempt to draw the lessons of both their advantages and
: limitations, taking advantage of newer software technology
: and of O-O principles...

In my experience, separating the spec and body physically is
extremely advantageous, and the need to have redundancy between
the spec and body is an important feature in a multi-person
project, not an "inconvenience."  In Ada (and to some extent in C/C++
when you use header files in a disciplined way), changing the interface
to a public routine, or adding a new public routine, or removing
one, is a fundamentally different kind of operation, and *intentionally* 
requires more effort and care.


: ...
:         G5. Minimize the programmer's work. In particular
:             it is crucial to avoid forcing the programmer
:             to duplicate text. Duplication is almost always
:             bad, especially with respect to ease of maintenance,
:             one of the central goals of software engineering.
:             It also hampers reuse, reliability (when you
:             duplicate code, you duplicate its bugs, and
:             the more software you write the more likely
:             it is that it will include bugs), and ease
:             of change.

Basically, this is the paragraph I don't agree with, since the
"duplication" one is talking about is duplication of the
parameter/result/constraint profile in the spec and body of 
a package/class.  The compiler checks for conformance, so the issue
of forgetting to fix bugs in all copies doesn't arise.  The compiler
catches such gaffes.  On the other hand, duplicating a chunk of
algorithmic code in two places is undeniably bad news.  But we
aren't talking about that here.

The programmer's work spent duplicating the interface in the
spec and body is truly trivial, whereas the advantages of having
a physically separate interface are profound in a multi-person
(or just long-lived) project.

I can believe this is somewhat just a matter of personal taste,
and where one believes programmers should put their energy.
However, there are some interesting anecdotes about programmers
who go from a language like Fortran or old-style C where there
is often no separate spec, to a language like Ada or Modula with
physical separation.  They suddenly realize that the spec is itself
an important design object, something for potential users and
implementors of an abstraction to work on together early in a project,
and something which will allow users and implementors of the abstraction
to go off and work relatively independently once agreement on the spec
is reached.  It becomes very clear that the spec is not "owned" by
either the users or the implementors, but is rather the contract between
them which will thereafter change only through collaborative renegotiation.

: -- 
: Bertrand Meyer, President, ISE Inc.
: ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
: 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
: http://www.eiffel.com, with instructions for download

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

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Tucker Taft wrote:
> In my experience, separating the spec and body physically is
> extremely advantageous, and the need to have redundancy between
> the spec and body is an important feature in a multi-person
> project, not an "inconvenience."  

The redundancy itself is not needed.  A language _like_ C or Ada
could be defined where the compiler uses the spec/prototype
of a function _from_ the other file in compiling the body of the
function.  But it would certainly be a productivity hit if the coder
had to do extra work to _see_ the interface while coding the
implementation.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <34059557.37C0@pseserv3.fw.hac.com> "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes:

> Tucker Taft wrote:
> > In my experience, separating the spec and body physically is
> > extremely advantageous, and the need to have redundancy between
> > the spec and body is an important feature in a multi-person
> > project, not an "inconvenience."  
> 
> The redundancy itself is not needed.  A language _like_ C or Ada
> could be defined where the compiler uses the spec/prototype
> of a function _from_ the other file in compiling the body of the
> function.  But it would certainly be a productivity hit if the coder
> had to do extra work to _see_ the interface while coding the
> implementation.

Another thing to note here; as (since) people are bandying about
automated tool support for extracting spec or whatever, they need to
realize the dual of this is also readily available: automated support
for generating the operation signatures and stubs for the body from
the spec.

IMO, the spec. is much more important for design than the body and so
having automated support spec.->implementation is much more
appropriate than having automated support implementation->spec.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFnK8D.Lsv@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >
> >IMO, the spec. is much more important for design than the body and so
> >having automated support spec.->implementation is much more
> >appropriate than having automated support implementation->spec.
> 
>   I don't know if spec is more important than implementation, but
> that's another debate...

No it is not "another debate" - it is simply my opinion, as noted.
That's part of the problem here - I've (and probably loads of others)
already thought these issues through and have made up my mind after
carefully weighing the various options.  Overall, my view is that the
Eiffel way is significantly less expressive and capable than the Ada
way.  Period.  End of story for me.  I'm more than willing to discuss
the various characteristics of each and the various tradeoffs in
objective fashion - but for "value judgements", I've already
deliberated and made them.


>   As for your comment above, for Eiffel in particular one would put
> spec and implementation in the same file, and to be able to extract
> spec at will.  Thus, it's not a case of implementation -> spec so
> much as implementation+spec -> spec.

A rose by any other name Patrick.


>   In other words, don't think that Eiffel encourages the
> implementation to drive the specification (which would indeed be a
> bad thing).  It simple mixes the two into the same file and provides
> tools to separate them again.

Fine.  And I do.  And IMO, the evidence is there with enough authority
to convince me of this.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Aug29152222@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFnK8D.Lsv@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Jon S Anthony <jsa@alexandria.organon.com> wrote:
>> >
>> >IMO, the spec. is much more important for design than the body and so
>> >having automated support spec.->implementation is much more
>> >appropriate than having automated support implementation->spec.
>> 
>>   I don't know if spec is more important than implementation, but
>> that's another debate...
>
>No it is not "another debate" - it is simply my opinion, as noted.

  That's funny, I thought these newsgroups were for discussion.

>That's part of the problem here - I've (and probably loads of others)
>already thought these issues through and have made up my mind after
>carefully weighing the various options.  Overall, my view is that the
>Eiffel way is significantly less expressive and capable than the Ada
>way.  Period.  End of story for me.  I'm more than willing to discuss
>the various characteristics of each and the various tradeoffs in
>objective fashion - but for "value judgements", I've already
>deliberated and made them.

  And this means we can't debate things any more?

>>   As for your comment above, for Eiffel in particular one would put
>> spec and implementation in the same file, and to be able to extract
>> spec at will.  Thus, it's not a case of implementation -> spec so
>> much as implementation+spec -> spec.
>
>A rose by any other name Patrick.

  Not at all.  Having a tool which "guesses" the spec from the
implementation is dangerous.  But simply extracting the existing
spec from a spec+implementation document is a trivial process
which it easily automated.

>>   In other words, don't think that Eiffel encourages the
>> implementation to drive the specification (which would indeed be a
>> bad thing).  It simple mixes the two into the same file and provides
>> tools to separate them again.
>
>Fine.  And I do.  And IMO, the evidence is there with enough authority
>to convince me of this.

  And you'll make no effort to convince me I'm wrong?  Then why
to you participate in newsgroups?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFqDLs.3FL@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >>   I don't know if spec is more important than implementation, but
> >> that's another debate...
> >
> >No it is not "another debate" - it is simply my opinion, as noted.
> 
>   That's funny, I thought these newsgroups were for discussion.

Firing loaded opinions around back and forth is not my idea of
"discussion".  Especially given the lack of nuances capable in NG
text.  If it's yours - have at it.  Of course, you should expect to
encounter all the worthless flames and inflammatory rhetoric that goes
with it.


>   And this means we can't debate things any more?

I don't see these "yes it is!  no it isn't!" or (even worse) "you're a
FOOL for not using X because _I_ think it's COOL (BETTER, SUPERIOR,
whatever)" exchanges as particularly insightful or useful.


> >A rose by any other name Patrick.
> 
>   Not at all.  Having a tool which "guesses" the spec from the
> implementation is dangerous.  But simply extracting the existing
> spec from a spec+implementation document is a trivial process
> which it easily automated.

Whatever.


> >Fine.  And I do.  And IMO, the evidence is there with enough authority
> >to convince me of this.
> 
>   And you'll make no effort to convince me I'm wrong?  Then why
> to you participate in newsgroups?

Because every once in a while (less lately due to a certain someone's
series of heavily x-posted inflammatory rhetoric) there are real
technical exchanges with real content that have real use.  Trying to
convince someone simply for the sake of convincing or ramming your
view down their throats with the zeal of a religous fanatic is lame
and useless.  Wanna do that?  Go be a lawyer or politician.  Best
thing is to simply present as much of the facts as you can in the best
light you can and let people make up their own minds.  If at the end
of the day they want to use C++ and VB or Eiffel or Ada, or Lisp or
..., so be it.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Aug30150959@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFqDLs.3FL@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> >>   I don't know if spec is more important than implementation, but
>> >> that's another debate...
>> >
>> >No it is not "another debate" - it is simply my opinion, as noted.
>> 
>>   That's funny, I thought these newsgroups were for discussion.
>
>Firing loaded opinions around back and forth is not my idea of
>"discussion".  Especially given the lack of nuances capable in NG
>text.  If it's yours - have at it.  Of course, you should expect to
>encounter all the worthless flames and inflammatory rhetoric that goes
>with it.

  Here's what I see: I stated an opinion and invited a debate.  You
put a stop to that, saying it is your opinion and not a debate.  Yet
in another thread, you said that simply stating opinion was a
"waste of bandwidth".

  I can't for the life of me see why you're here at all, so I 
guess we'll have to agree to disagree and spare others from our
diatribes.

>>   And this means we can't debate things any more?
>
>I don't see these "yes it is!  no it isn't!" or (even worse) "you're a
>FOOL for not using X because _I_ think it's COOL (BETTER, SUPERIOR,
>whatever)" exchanges as particularly insightful or useful.

  It's only useless when opinions are not backed up by thoughtful
arguments, as in your case above regarding the importance of
interface versus implementation.  To me, that's the waste of
time.

>> >Fine.  And I do.  And IMO, the evidence is there with enough authority
>> >to convince me of this.
>> 
>>   And you'll make no effort to convince me I'm wrong?  Then why
>> to you participate in newsgroups?
>
>Because every once in a while (less lately due to a certain someone's
>series of heavily x-posted inflammatory rhetoric) there are real
>technical exchanges with real content that have real use.  Trying to
>convince someone simply for the sake of convincing or ramming your
>view down their throats with the zeal of a religous fanatic is lame
>and useless.  

  But I'm here to have people try to convince me of their views.
I think that's the best part.  You learn the most from that sort
of thing--not just mere information, but different ways to think.
If you don't want to do me that favour, I can't possibly hold
a grudge, but I still wonder why you're here.

>Wanna do that?  Go be a lawyer or politician.  Best
>thing is to simply present as much of the facts as you can in the best
>light you can and let people make up their own minds.  If at the end
>of the day they want to use C++ and VB or Eiffel or Ada, or Lisp or
>..., so be it.

  I agree completely.  I've been asking you to back up your opinions
(ie. "present the facts as you can in the best light you can"), and
you don't want to.  And that's fine.  Just so we understand each other.

  So, in the hopes of sparing others from more wasted bandwidth,
perhaps we should be more selective from now on as to which of
each others' comments we respond to.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Suzanne Zampella]

Jon S Anthony wrote:

> In article <34059557.37C0@pseserv3.fw.hac.com> "W. Wesley Groleau
> x4923" <wwgrol@pseserv3.fw.hac.com> writes:
>
> > Tucker Taft wrote:
> > > In my experience, separating the spec and body physically is
> > > extremely advantageous, and the need to have redundancy between
> > > the spec and body is an important feature in a multi-person
> > > project, not an "inconvenience."
> >
> > The redundancy itself is not needed.  A language _like_ C or Ada
> > could be defined where the compiler uses the spec/prototype
> > of a function _from_ the other file in compiling the body of the
> > function.  But it would certainly be a productivity hit if the coder
>
> > had to do extra work to _see_ the interface while coding the
> > implementation.
>
> Another thing to note here; as (since) people are bandying about
> automated tool support for extracting spec or whatever, they need to
> realize the dual of this is also readily available: automated support
> for generating the operation signatures and stubs for the body from
> the spec.
>

   Oh, to be back on the Rat.....  We had this way back in '87, 10 years
ago... .. code the specification for detailed design -- baseline it in
the environment so everyone who interfaced had a stable target, then the
CASE generated the body stub and you could change the body till it
worked while your fellow team members coded and compiled against your
<baselined> specification.  If you wanted to see the specification of
something you just put your cursor on it and pressed a function key and
up popped a window showing the definition of the item (procedure,
variable, whatever).  If you didn't remember the parameters of a
procedure call, with the a press of a function key the CASE would prompt
you for them.

Separate bodies and specification are NOT the problem.  They are
incredibly helpful from a firewall (coding changes stop here without
approval) point of view and from the point of view of producing designs
that stay with the code. They are also great if you have to have
separate bodies on different platforms. What you need is a good CASE.


Suzanne Zampella
{include STD-Disclaimer}

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <3406CF60.11A867C4@trcinc.com> Suzanne Zampella <suzanne.zampella@trcinc.com> writes:

> > Another thing to note here; as (since) people are bandying about
> > automated tool support for extracting spec or whatever, they need to
> > realize the dual of this is also readily available: automated support
> > for generating the operation signatures and stubs for the body from
> > the spec.
>
>    Oh, to be back on the Rat.....  We had this way back in '87, 10 years
> ago... .. code the specification for detailed design -- baseline it in
> the environment so everyone who interfaced had a stable target, then the
> CASE generated the body stub and you could change the body till it
> worked while your fellow team members coded and compiled against your
> <baselined> specification.  If you wanted to see the specification of
> something you just put your cursor on it and pressed a function key and
> up popped a window showing the definition of the item (procedure,
> variable, whatever).  If you didn't remember the parameters of a
> procedure call, with the a press of a function key the CASE would prompt
> you for them.

Never fear, Emacs is here!  Seriously, Emacs ada-mode does all of this
for you now.  What's more, it's completely open and you have complete
control over it (can change it if you wish, etc.)  And it is much
easier to integrate it with other things.

Emacs is KING! :-) :-)
[yes, Robert, I know I probably shouldn't have said that!]

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

<<Therefore I also prefer the spec to be completely seperated which
doesn't exclude some good (CASE) tools auto-generating a code framework.
Also I got the feeling people here mix up 'spec', 'description of
interfaces as derived out of the requirements specification', 'detailed
description of implementation interfaces' (which would more be a part of
the design IMO). Maybe even I am the one who doesn't get the meaning
right. :-)
And finally, in my specific environment, I would be happy to have a
early, stable spec and a good design documentation at all. :-(>>

This is confusing things. The specification of an interface at a suitably
abstract level is quite a different thing from the package declaration in
an Ada program. Have you written in Ada? I would guess not, or you would
have a better feel of what is being talked about here. Give it a try, even
a little experience here will be very helpful.

P.S. no one yet answered by question about people having actually interfaced
Eiffel to Continuus or Clearcase to show how the CM problems are overcome.
I am beginning to assume that no one has done it (not surprising, because
the point of my question was that it does not look easily doable, and people
tend simply not to do what is not easy to do!)

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Graham Perkins (gperkins@dmu.ac.uk) wrote:
> But really, this whole discussion indicates to me that we are still in
> the stone
> age with our tools.  Why are we still talking about "files"?!! 
> Presumably stored
> in DOS or Unix directories ?!!  Uggghhhh!!!!

Well, perhaps the reason is somewhat called the least common denominator?
I'd love to have powerful tools that keep me from caring about my 'files'
a lot and give me lots of other support. But(!) the more tools you have the
more work is needed to port these tools to different platforms. Have a look
at GNAT or gcc: that is really good work and it is available on many 
platforms.  Yet there are a lot more platforms that are not covered that
well.  And here we are talking only about the compiler. Not any additional
tools that 'make life easy'. 

To keep this short: When will Eiffel be available for the Cray T3E? Or the
NEC SX-4? :-) Maybe I should try a gcc/GNAT port first instead of waiting...

Yours 

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Interface/Implementation (was Re: Design by Contract)

[Ralph Paul]

Joerg Rodemann wrote:
> 
> To keep this short: When will Eiffel be available for the Cray T3E? Or the
> NEC SX-4? :-) Maybe I should try a gcc/GNAT port first instead of waiting...

You did forget the mighty little Intel Paragon ? (:-).

Ralph Paul

a fairy tale (was: Re: Interface/Implementation )

[Fred Long]

In article <3406A707.787D@dmu.ac.uk>, Graham Perkins <gperkins@dmu.ac.uk> writes:
.... some stuff deleted ....
|> 
|> But really, this whole discussion indicates to me that we are still in
|> the stone
|> age with our tools.  Why are we still talking about "files"?!! 
|> Presumably stored
|> in DOS or Unix directories ?!!  Uggghhhh!!!!
|> 
|> Software components and their assemblages are amongst the most
|> complicated 
|> and highly structured, semantic rich, artefacts to be found in the human
|> world.
|> And yet we store, retrieve, and view them as STRINGS (for that is what a
|> file
|> is) organised into a labelled CABINET (which is about as powerful as
|> today's
|> filing systems are !!!!!
|> 
|> Yet when it comes to simple structures like Customer, Employee, Account,
|> OrderLine, etc. we use incredibly sophisticated and powerful
|> repositories
|> (such as Ingres).  They can present multiple views of underlying
|> components;
|> limit or allow different kinds of read/update access by component, user, 
|> or view; manage batched and online transactions with or without backup,
|> rollback
|> etc; keep version history and audit trail of all components; support or
|> enforce
|> corporate workflow policy; handle co-ordination of multiple users and
|> multi-threaded tasks; .....
|> 
|> If our software components were stored properly, then much of this 
|> usenet discussion would be unnecessary.  The Eiffel/Ada/Java vendors who
|> were
|> configuring the repository to work with their compilers could choose as
|> an
|> implementation issue whether an interface is a view of the full
|> component
|> or a separate component.  As a completely orthogonal issue, they could
|> decide
|> how to authorise and manage changes to interface and implementation.  If
|> they
|> keep them separately, then have to make repository do some work to
|> synchronise
|> them.  If they just have one component, then have to control change
|> management
|> at the view level.
|> 
|> Proper repository could also support a lot more, eg keep the syntactic
|> and
|> static semantic structure that is normally thrown away by compiler; add
|> more static semantic structure from the developer's software engineering
|> process rather than just the language definition.
|> 
|> Now where is that repository with all that power I want ... 
|>   [if you're setting up a team to develop such a beast, please
|>    count me in]
|> 
|> maybe Eiffel vendors are further down that road than many (or Unisys
|> UREP might
|> be the right track to follow) but we still seem a long way from open
|> repositories
|> than support full process

Once apon a time there was a Stoneman.  He was lonely and wanted a
better environment, so he married DIANA and they had two daughters,
ALS and AIE.  Unfortunately, the two daughters were not as close to
each other as they should have been.

So Stoneman and DIANA had another daughter CAIS, and then yet another
daughter, CAIS-A.  But CAIS and CAIS-A had a rival, PCTE.  PCTE was
fed by ECMA and ISO and grew big and strong.  CAIS-A and PCTE married,
and had a daughter, PCIS. 

In the end, PCTE went EAST searching for a second ENTERPRISE and
nothing has been heard of him since.  PCIS must have married, since
there was news about a NAPI. 

Some thought it was all just a big song and dance, or OPERA.  But it
wasn't.  It was all true, and eventually they all discovered a place
called Repository and lived there, in integrated harmony, happily ever
after.

	Fred Long.

In defence of plain ascii files ( was Re: Interface/Implementation (was Re: Design by Contract)

[Chris RL Morgan]

In article <3406A707.787D@dmu.ac.uk>,
	Graham Perkins <gperkins@dmu.ac.uk> wrote:
[SNIP]
>But really, this whole discussion indicates to me that we are still in
>the stone
>age with our tools.  Why are we still talking about "files"?!! 
>Presumably stored
>in DOS or Unix directories ?!!  Uggghhhh!!!

You don't work for a tool vendor by any chance do you?

Seriously though every time you move away from human readable plan text files you risk losing some flexibility or the use of some tool or other. Yes ascii is the lowest common denominator but nearly every tool in, for example, a Unix system will work with it. Not only the compiler, but also grep, awk, perl, sed, gdb, diff, cat, tr, more, less, all will do a simple albeit mediocre job of understanding your files. For example if the IDE with a new compiler system is great but third party debuggers or memory leak tools can't show me my code as I step through it line by line then it loses, end of story. Source code navigation tools in a commercial product would have to be _very_ good to make me by them when I have gnatf and emacs for free.

To my mind non-ascii files are uncivil, they are needed in many cases but where they aren't people should have the decency to work with ascii so that when their software goes wrong I can see what they're up to. Of course this is part of what Unix is about and I can see other people don't agree. Last time I looked at Solaris for example it still starts up simply by running a load of text files (scripts) in the lexical order of their filenames (something like rc1, rc2 etc) - simple but effective. Perhaps if we tell them we use a "lightweight, platform-independent, vendor-neutral, open, standards-based interchange format" for our "repository" they'll like it better ;^)

Chris

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Graham Perkins wrote:

:Tucker Taft wrote:
:> In my experience, separating the spec and body physically is
:> extremely advantageous, and the need to have redundancy between
:
:Personally I prefer the single file approach as with Eiffel..

Thought you might. :)

:But really, this whole discussion indicates to me that we are still in
:the stone age with our tools..

[lots of good stuff about how a software repository ought to work]

:Now where is that repository with all that power I want ... 
:  [if you're setting up a team to develop such a beast, please
:   count me in]

.. and me!  :)

:maybe Eiffel vendors are further down that road than many (or Unisys UREP might
:be the right track to follow) but we still seem a long way from open repositories
:than support full process

Agree.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Design by Contract

[Robert Dewar]

<<Not at all. There would be better solutions possible, but the single
file
with good extraction tools works well. It's even possible in C if you
can
stand the pain.>>


The reason I disagree is that it makes configuration management much more
complex.

Obviously changing a spec is a much different activity than changing
a body. The set of people who are allowed to make the change will typically
be different, and the procedures to be followed to allow the change to be
made will most certainly be different.

By having separate files, one can control CM at the file level, which is
the natural way of doing things.

I don't know Eiffel well enough to know how easy it would be to make the
CM system aware of *what kind* of change you were making, from what I know
of Eiffel, it sounds difficult.

Re: Design by Contract

[Paul Johnson]

In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says...

>I don't know Eiffel well enough to know how easy it would be to make the
>CM system aware of *what kind* of change you were making, from what I know
>of Eiffel, it sounds difficult.

No, its easy.  Eiffel systems come with tools to extract class interfaces.
You just put those interfaces under change control and then compare the
stored versions with the newly generated versions.

A combination of "diff" with a simple Perl script to distinguish between
formatting or comment changes, and more significant interface changes
would do the job nicely.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Design by Contract

[Matt Kennel (Remove 'NOSPAM' to reply)]

On 29 Aug 1997 08:38:34 GMT, Paul Johnson <paul.johnson@gecm.com> wrote:
:In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says...
:
:>I don't know Eiffel well enough to know how easy it would be to make the
:>CM system aware of *what kind* of change you were making, from what I know
:>of Eiffel, it sounds difficult.
:
:No, its easy.  Eiffel systems come with tools to extract class interfaces.
:You just put those interfaces under change control and then compare the
:stored versions with the newly generated versions.

In truth, isn't the right management procedure for this situation to control
abstract classes, and have programmers write concrete ones to that spec?

:Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |


*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           -
* "People who send spam to Emperor Cartagia... vanish! _They say_ that
* there's a room where he has their heads, lined up in a row on a desk...
* _They say_ that late at night, he goes there, and talks to them... _they
*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"

Re: Design by Contract

[John F. Bell III]

It seems to me that if you want to keep someone from changing the interface to 
a class, or anything else for that matter, you stand in front of the 
development staff and say in a clear voice "Don't change the interface.".

If that doesn't work you might try "Don't change the interface or I'll fire 
you.".

Jeez, doesn't anyone work with folks that follow directions anymore?

John
jfb3@pdq.net

(A gun, but one that can follow directions.)


=======================================================
>In article <slrn60himi.su2.kennel@lyapunov.ucsd.edu>, 
>kennel@NOSPAMlyapunov.ucsd.edu wrote:
>On 29 Aug 1997 08:38:34 GMT, Paul Johnson <paul.johnson@gecm.com> wrote:
>:In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says...
>:
>:>I don't know Eiffel well enough to know how easy it would be to make the
>:>CM system aware of *what kind* of change you were making, from what I know
>:>of Eiffel, it sounds difficult.
>:
>:No, its easy.  Eiffel systems come with tools to extract class interfaces.
>:You just put those interfaces under change control and then compare the
>:stored versions with the newly generated versions.
>
>In truth, isn't the right management procedure for this situation to control
>abstract classes, and have programmers write concrete ones to that spec?
>
>:Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions.
> |
>
>
>*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           -
>* "People who send spam to Emperor Cartagia... vanish! _They say_ that
>* there's a room where he has their heads, lined up in a row on a desk...
>* _They say_ that late at night, he goes there, and talks to them... _they
>*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"

Re: Design by Contract

[Ken Garlington]

John F. Bell III wrote:
> 
> It seems to me that if you want to keep someone from changing the interface to
> a class, or anything else for that matter, you stand in front of the
> development staff and say in a clear voice "Don't change the interface.".
> 
> If that doesn't work you might try "Don't change the interface or I'll fire
> you.".
> 
> Jeez, doesn't anyone work with folks that follow directions anymore?

Put that with the direction, "Oh, and don't make any typos, either." If
the engineer has direct access to the file containing the spec, (s)he
might inadvertantly change the spec while attempting to change the body.
There is also the issue of verification. If a file is modified, it
requires
extra effort to determine the exact nature of the modification.

> 
> John
> jfb3@pdq.net

Re: Design by Contract

[Robert Dewar]

John said

<<> It seems to me that if you want to keep someone from changing the interface to
> a class, or anything else for that matter, you stand in front of the
> development staff and say in a clear voice "Don't change the interface.".
>
> If that doesn't work you might try "Don't change the interface or I'll fire
> you.".
>
> Jeez, doesn't anyone work with folks that follow directions anymore?>>


Hmmm! I do not think this will stand up as an ISO 9000 consistent documented
procedure, but if it works, then we can augment Ken's suggestion, tell
people in addition not to making typos to write efficient codfe and never
introduce regressions -- that way you can do away with the nuisance of
regression testing :-)

Re: Design by Contract

[Ken Garlington]

Robert Dewar wrote:
> 
> Can we hear from someone who has used Eiffel with, say, either Clearcase
> or Continuus, and has cleanly solved the problem of giving different
> access rights for spec and implementation changes.

I can't speak for those cases, but with PCMS you can distinguish between
files
that represent a spec (either Eiffel or Ada) and those that represent a
body.
Furthermore, you can define different "life cycles" (who gets to do what
to each
file at a given time) for each type of object.

Personally, given that you can (a) mimic Ada specs in Eiffel with
deferred classes,
(b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and,
in the case
of GNAT, with gnatchop), and (c) mix and match deferred and concrete
operations
in both languages, I don't see a huge difference between the two
languages in this
area. Bad CM will defeat either language's approach...

Re: Design by Contract

[Thomas Beale]

Ken Garlington wrote:
> 
> Robert Dewar wrote:
> >
> > Can we hear from someone who has used Eiffel with, say, either Clearcase
> > or Continuus, and has cleanly solved the problem of giving different
> > access rights for spec and implementation changes.
>
>....
> Personally, given that you can (a) mimic Ada specs in Eiffel with
> deferred classes, (b) mimic Eiffel combined specs/bodies in Ada with 
> a decent editor (and,  in the case of GNAT, with gnatchop), and 
> (c) mix and match deferred and concrete operations in both languages, 
> I don't see a huge difference between the two languages in this
> area. Bad CM will defeat either language's approach...

Unfortunately this approach equates to introducing SPECIFICATION v 
IMPLEM (or SPEC/DESIGN/IMPL, or more levels if you want) as one 
of the dimensions of inheritance. Eiffel for example has no
problem with extensive MI; the problem is that the traits of
SPEC v IMPL are orthogonal to all the rest of the things you are
modelling - they are not (shouldn't be) in the model at all. To
see this, just imagine an MI situation: C inherits A and B. You
potentially want SPEC and IMPL versions of all these classes:

	SPEC_A	SPEC_B
	   ^      ^
	   |	  |
	    SPEC_C

... now where to put the IMPL_A etc classes? You can't really
do anything sensible, because denoting classes as "specification"
or "implementation" is a process concept. Next week you may want
to change it, but if it's in your inheritance model, you're
in big trouble.

Now, IMO, achieving the required result requires three things:

       - a repository representation of programming artifacts
	(normally classes, or patterns in e.g. beta), where
	representation is fine enough to allow syntactic 
	elements to be controlled separately. E.g. method	
	name, Result type, arg names and types etc etc.

      - a CM system which can be told to manipulate the 
	contents of this repository in the same way files
	are manipulated by the (fairly pedestrian) CM 
	systems of today. I.e., treat selected groups of 
	programming artifacts as configurations in the CM
	sense.

      - The combined CM system/repository must be capable
	of understanding dependencies between artifacts so 
	that a change to a specification-level artifact 
	(e.g. a result type) reports the affected 
	implementation-level artifacts. Conversely, an attempt 
	to alter an artifact already constrained by anpther
	artifact must be stopped with a sensible indication
	of why. Such "understanding" requires a language tool
	e.g. an Eiffel or ADA compiler.

This allows you to say that certain aspects of an individual
class are "specification", and cannot be changed in that
class (achieved by CM ownership, permissions etc), or in
inheriting classes (achieved by the language tool). But since
we are controlling parts of classes (not whole files), 
there is no problem with an implementor adding implementation
details to a class containing "locked" specification details.

Actually, in the case of inheritance, you can do something
very nice. Let's say you have a class feature
	address:LIST[ADDRESS_ITEM] -- eiffel
which you want to "lock" as specification. Inheritors
should be allowed to do:
	address:LINKED_LIST[ADDRESS_ITEM] -- conformant redef
but not (say):
	address:SET[ADDRESS_ITEM] -- non conformant
The language processor in the repository will allow you
to define such a constraint, by simply saying that the 
descendant class must compile.

In summary: a repository whose elements are transparent
(therefore processable) by language tools, and whose same
elements are also transparent (therefore maniplatable)
to CM or VC systems is required; further, the CM system
must be able to use the language processing tool to define
and test dependencies. A simple example of this would be
a constraint that forces all descendants of class C to
have the same short-form as that of C.

- thomas beale

Re: Design by Contract

[Thomas Beale]

Patrick Doyle wrote:
> 
> In article <340CDE84.6ACC@invest.amp.com.au>,
> Thomas Beale  <thomas_beale@invest.amp.com.au> wrote:
> >
> >... now where to put the IMPL_A etc classes? You can't really
> >do anything sensible, because denoting classes as "specification"
> >or "implementation" is a process concept. Next week you may want
> >to change it, but if it's in your inheritance model, you're
> >in big trouble.
> 
>   I think this is where the Bridge pattern somes in.  (I hope that's
> the right name.)  You'd have a similar heirarchy for the IMPL_x
> classes, and the SPEC_x classes would have a member of type IMPL_x.
> 
>   Would this solve the problem?

This pattern is a similar idea, but it corresponds to the idea of 
interface/implementation - i.e. exported/hidden rather than different
levels of access. It works (forgetting the problems of MI) as long as
access restrictions (or change control levels) correspond exactly
to interface v implmentation classes in the model. However, if the
project wants to place any restrictions on say part of a design-level
or implementation detail (a particular algorithm, for example), again
it won't work.

The point is that software engineering processes often do not correspond
cleanly to the object model of the thing being engineered.

- thomas beale

Re: Design by Contract

[Robert Dewar]

Ken said

<<I can't speak for those cases, but with PCMS you can distinguish between
files
that represent a spec (either Eiffel or Ada) and those that represent a
body.
Furthermore, you can define different "life cycles" (who gets to do what
to each
file at a given time) for each type of object.

Personally, given that you can (a) mimic Ada specs in Eiffel with
deferred classes,
(b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and,
in the case
of GNAT, with gnatchop), and (c) mix and match deferred and concrete
operations
in both languages, I don't see a huge difference between the two
languages in this
area. Bad CM will defeat either language's approach...>>


Sure, but that's the whole point, PCMS is file based, and from your
description will not easily handle a single file that is both the spec
and body in Ada terms. If you want to think in Ada terms, think how
you would handle a single file with spec and body in the same file, giving
different permissions to people to modify the spec part or body part, sounds
awkward to me using PCMS (or any other CM system I am familiar with). 

Re: Design by Contract

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken said
> 
> <<I can't speak for those cases, but with PCMS you can distinguish between
> files
> that represent a spec (either Eiffel or Ada) and those that represent a
> body.
> Furthermore, you can define different "life cycles" (who gets to do what
> to each
> file at a given time) for each type of object.
> 
> Personally, given that you can (a) mimic Ada specs in Eiffel with
> deferred classes,
> (b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and,
> in the case
> of GNAT, with gnatchop), and (c) mix and match deferred and concrete
> operations
> in both languages, I don't see a huge difference between the two
> languages in this
> area. Bad CM will defeat either language's approach...>>
> 
> Sure, but that's the whole point, PCMS is file based, and from your
> description will not easily handle a single file that is both the spec
> and body in Ada terms. If you want to think in Ada terms, think how
> you would handle a single file with spec and body in the same file, giving
> different permissions to people to modify the spec part or body part, sounds
> awkward to me using PCMS (or any other CM system I am familiar with).

Understood - however, if I followed the thread correctly, I could in
either
Eiffel or Ada: (a) keep the spec and body separate [works better with
file
oriented CM, etc.] or (b) keep the spec and body together [easier to
code
for simple cases, etc.]. That was _my_ point.

Re: Design by Contract

[Mark Bennison]

Richie Bielak <richieb@XYZZYcalfp.com> wrote:
<snip>
>But you are making the assumption that a given module has only one interface.
>This is not true in Eiffel, as a class can show a different interfaces to
>different clients. Should all these interfaces be kept in separate files
>(like in Java)?
>
>In presence of extraction tools, keeping a single file is easier.
>

Keeping a single file may well be 'easier' but it provides a 
configuration control nightmare. If you have anything but a small  
development team ( and by this I mean > 2 engineers ) then access to this 
single file becomes uncontrollable and there'll be several different 
versions of the same file that may ( or may not ) be divergent. 

At least by keeping things in separate files you can have allocated 
packages of work for engineers that do not directly affect the packages 
that other engineers are working on, even if they are the different 
interfaces to the same class. You also get engineers thinking about what 
the knock-on effects of changing the other interfaces would be rather 
than just doing it to solve their particular problem ( I would hope :-).

Mark.
(posted from comp.lang.ada)
-- 
Mark Bennison,           +-----------------------------------+
Technical Consultant,    | All opinions expressed are my own |
EASAMS Software Systems. +-----------------------------------+
"Death is a fickle hen, and random are her eggs" - Armando Iannucci
Remove '.no.spam' to return e-mail

Separation of IF and Imp: process issue?

[Jeff Kotula]

Mark Bennison wrote:

> Keeping a single file may well be 'easier' but it provides a
> configuration control nightmare. If you have anything but a small
> development team ( and by this I mean > 2 engineers ) then access to
> this
> single file becomes uncontrollable and there'll be several different
> versions of the same file that may ( or may not ) be divergent.

I'm curious is about this configuration control nightmare issue. It
seems
to me that if the engineering teams treat their components/modules as
real products and have controlled releases which the other teams can
then
integrate as circumstances allow, the only remaining issue is
coordinating
the configuration within relatively small teams.

Is this more of a project management or process issue than a language
issue? (I know there is some overlap, but depending on the problem it
may
be easier and more appropriate to solve with one mechanism or
another...)

jeff

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <x7vd8myyrzx.fsf@pogner.demon.co.uk>,
Simon Wright  <simon@pogner.demon.co.uk> wrote:
>
>From an Ada user's perspective, I believe that the point being made is
>that the interface specification and the implementation of that
>interface need to be managed separately. They should be separate
>configuration items. The overall cost of an interface change is much
>larger than that of an implementation change, in general.

IMO, having separate interface and implementation files for the
same package simply reinforces the somewhat antiquated notion
that an implementation has only one interface.  In fact, by
Ada, they must have a one-to-one correspondence.

It has been pointed out that abstract (ie. deferred) classes can
do the same thing with greater flexibility.

>We tend to think that it'll be easier to manage this if the two things
>are in different files.

Certainly.  The solution I've seen proposed is to create an
abstract class for the interface, and freeze it; then work on
concrete implementation classes for that interface.  Seems
to me you can get the same results.

>Clearly it would be possible to include a check at handin that the
>extracted interface hadn't been changed without permission (for all I
>know Eiffel implementations do this already!) You could even imagine
>an environment where the interface specification parts of a
>normally-checked-out source unit were in fact read-only (I'm thinking
>of something like the Rational Delta environment here).
>
>If you use different files, the effect comes about with far less
>effort.

That's very true.  I guess what I'm trying to say is that languages
which combine all code for a class (package) in one file can still
do this with abstract classes.  This simplification of the language
and the development process comes at no cost in flexibility or
capability.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EFqyG7.67v@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> IMO, having separate interface and implementation files for the
> same package simply reinforces the somewhat antiquated notion
> that an implementation has only one interface.  In fact, by
> Ada, they must have a one-to-one correspondence.

Patrick,

If you are going to complain about something at least get the
complaint right before going off half cocked.  With child packages you
can give an implementation as many completely different interfaces as
you like.  IOW, your "in fact" is not.


package P is
...interface
private
...impl representation
end P;

package P.C1 is
...new interface for P's impl
end P.C1;

package P.C2 is
...yet another interface for P's impl
end P.C2;

etc.


> It has been pointed out that abstract (ie. deferred) classes can
> do the same thing with greater flexibility.

Again - get it right.  Abstract classes are analogous to abstract
types in Ada, NOT packages.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Aug31145336@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFqyG7.67v@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> IMO, having separate interface and implementation files for the
>> same package simply reinforces the somewhat antiquated notion
>> that an implementation has only one interface.  In fact, by
>> Ada, they must have a one-to-one correspondence.
>
>Patrick,
>
>If you are going to complain about something at least get the
>complaint right before going off half cocked.  With child packages you
>can give an implementation as many completely different interfaces as
>you like.  IOW, your "in fact" is not.

  I stand corrected.  Thankyou.

  However, generally having corresponding interface and implementation
files for the same class (or package, or whatever) does reinforce
the notion that an implementation has only one interface.  Clearly,
the Ada method is more flexible than I had imagined, but (for
example) the typical C++ methodology is a one-to-one correspondence
which does tend to reinforce this notion.

  One other thing: Does each Ada spec for a package have to be
in a separate file, or can they be together?  I ask because if
they need to be in separate files, then you pay for the extra
flexibility of multiple interfaces with extra files.

>> It has been pointed out that abstract (ie. deferred) classes can
>> do the same thing with greater flexibility.
>
>Again - get it right.  Abstract classes are analogous to abstract
>types in Ada, NOT packages.

  I've said this before: I'm not going for an analogy here.
My statement stands: deferred classes can do the same thing
as interface files, and are more powerful, and are simpler
because they unify nicely with existing OOP practices. 

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Patrick asks

<<  One other thing: Does each Ada spec for a package have to be
in a separate file, or can they be together?  I ask because if
they need to be in separate files, then you pay for the extra
flexibility of multiple interfaces with extra files.>>

The Ada standard has nothing to say about files at all. How compilation
units are represented is an implementation dependent issue. So these
questions, if they are meaningful at all, are only questions that
apply to a particular implementation.

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <dewar.873171671@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Patrick asks
>
><<  One other thing: Does each Ada spec for a package have to be
>in a separate file, or can they be together?  I ask because if
>they need to be in separate files, then you pay for the extra
>flexibility of multiple interfaces with extra files.>>
>
>The Ada standard has nothing to say about files at all. How compilation
>units are represented is an implementation dependent issue. So these
>questions, if they are meaningful at all, are only questions that
>apply to a particular implementation.

  Ok, does each spec have to be in a separate compilation unit?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EFwAxL.LHu@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >The Ada standard has nothing to say about files at all. How compilation
> >units are represented is an implementation dependent issue. So these
> >questions, if they are meaningful at all, are only questions that
> >apply to a particular implementation.
> 
>   Ok, does each spec have to be in a separate compilation unit?

?!? Each spec _is_ a separate compilation unit.  Further, it is
obvious that specs can be library level and so need not be in another
spec or body or subprogram or generic or other compilation unit.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Patrick Doyle says

<<  Ok, does each spec have to be in a separate compilation unit>>

nope, full nesting is allowed, so for example, a procedure can contain
nested package specs and package bodies, and this capability is frequently
used. Furthermore in this case, if you want, the body can be separately
compiled.

You could certainly imagine a trivial preprocessor for Ada that would
allow the spec and body to be (let's use our nice new word) conflated.
But I never heard of anyone building or expressing a desire for such
a tool, it would be completely useless, and indeed worse, definitely
negative in its utility.

Re: Separation of IF and Imp: process issue?

[W. Wesley Groleau x4923]

> You could certainly imagine a trivial preprocessor for Ada that would
> allow the spec and body to be (let's use our nice new word) conflated.
> But I never heard of anyone building or expressing a desire for such
> a tool, it would be completely useless, and indeed worse, definitely
> negative in its utility.

Why?  The whole point of this thread is whether the Eiffel approach
(similar to the above) is better than the Ada approach.  So an 
unsupported statement that a variation of the Eiffel approach would
be "useless, and ... worse" doesn't help.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Separation of IF and Imp: process issue?

[Erik Magnuson]

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

> You could certainly imagine a trivial preprocessor for Ada that would
> allow the spec and body to be (let's use our nice new word) conflated.

Would this mythical beast be called "pohctang"? ;-)

> But I never heard of anyone building or expressing a desire for such
> a tool, it would be completely useless, and indeed worse, definitely
> negative in its utility.

Ancient history: I recall one old Ada83 compiler that wanted generic specs
and bodies in the same file.

And a "denesting" tool (one that could inline an "is separate" body) was in
the old Rational Delta. Actually it provided both "make separate" and "make
inline". This was sometime used as an "optimization" when the target compiler
generated noticably worse code (extra instructions) for separate units.

-- 
Erik

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EFtF7M.12p@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

>   I stand corrected.  Thankyou.

You're welcome.


>   One other thing: Does each Ada spec for a package have to be
> in a separate file

No.


> , or can they be together?

Yes.


> >> It has been pointed out that abstract (ie. deferred) classes can
> >> do the same thing with greater flexibility.
> >
> >Again - get it right.  Abstract classes are analogous to abstract
> >types in Ada, NOT packages.
> 
>   I've said this before: I'm not going for an analogy here.
> My statement stands: deferred classes can do the same thing
> as interface files, and are more powerful, and are simpler
> because they unify nicely with existing OOP practices. 

The point is, abstract types in Ada can do the same as deferred
classes.  However, they are somewhat more "flexible" as you can
combine them in various ways within and across module boundaries.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Sep2174401@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>>
>> >Again - get it right.  Abstract classes are analogous to abstract
>> >types in Ada, NOT packages.
>> 
>>   I've said this before: I'm not going for an analogy here.
>> My statement stands: deferred classes can do the same thing
>> as interface files, and are more powerful, and are simpler
>> because they unify nicely with existing OOP practices. 
>
>The point is, abstract types in Ada can do the same as deferred
>classes.  However, they are somewhat more "flexible" as you can
>combine them in various ways within and across module boundaries.

  Great.  So what do you need these separate interface files for?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <x7vzppy250u.fsf@pogner.demon.co.uk>,
Simon Wright  <simon@pogner.demon.co.uk> wrote:
>doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> IMO, having separate interface and implementation files for the
>> same package simply reinforces the somewhat antiquated notion
>> that an implementation has only one interface.  In fact, by
>> Ada, they must have a one-to-one correspondence.
>
>[...]
>
>I don't quite know what you mean by "the somewhat antiquated notion
>that an implementation has only one interface". The Java notion,
>perhaps? I agree that this is a very interesting concept, not sure how
>it maps onto Ada.

  What I mean is that a package in Ada has a single spec file.  Thus,
the implementation has a single interface.  In Java or Eiffel, a
single class can fulfill many different interfaces.  In fact, Java's
method isn't truly a several-interfaces approach because even
though a class can implement several Java Interfaces, its overall
interface can be expressed as the union of the individual interfaces.
However, in Eiffel, a class can reveal different features to different
clients, and thus actually have different interfaces.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <mheaney-ya023680000209972131260001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In article <EFtEqy.qG@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
>Doyle) wrote:
>
>>  What I mean is that a package in Ada has a single spec file.  Thus,
>>the implementation has a single interface.  In Java or Eiffel, a
>>single class can fulfill many different interfaces.

  (This is an old quote of mine that I have since learned to be
incorrect.)

>But this is not quite the same thing as the relationship between a module
>specification and its body.  

  Ok, I'll boil my position down into one question: What does a separate
interface file do for a class that an abstract superclass can't do?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Matthew Heaney]

In article <EFxww3.2Fp@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>>But this is not quite the same thing as the relationship between a module
>>specification and its body.  
>
>  Ok, I'll boil my position down into one question: What does a separate
>interface file do for a class that an abstract superclass can't do?

True, an abstract superclass would specify the characteristics common to
every subclass in that derivation tree, but an interface file ("package
spec") describes the characteristics of a specific class.  For example,
given an abstract queue superclass:

generic
   type Queue_Item is private;
package Queues_G is

   type Root_Queue is abstract tagged private;

   procedure Add
     (Item : in Queue_Item;
      To : in out Root_Queue) is abstract;

end;

Now let's subclass, and create a balking queue:

generic
packages Queues_G.Balking_G is

   type Balking_Queue is 
      new Root_Queue with private;

   procedure Add 
     (Item : in Queue_Item;
      To      : in out Balking_Queue);

   procedure Remove_Item
      (From : in out Balking_Queue;
      At_The_Position : in Positive);

private

   type Balking_Queue is ...;

end;

The module interface is separate from its body, and can therefore be
configured separately.  Any changes to the spec have to be coordinated with
the clients of the package.

Suppose I wanted to change the position from Positive to Natural, because
for some strange reason I decide I'd rather count starting from 0.  This
change can't be made indiscriminately, because clients already depend on
certain behavior (count starting from 1).

A change to the body can of course be made painlessly, because no one can
depend on what's in the body.  But the spec is a contract that can't be
changed without notifying all parties involved.

If one only had a module body, without a separate spec, then it would look like

generic
packages Queues_G.Balking_G is

   type Balking_Queue is 
      new Root_Queue with private;

   procedure Add 
     (Item : in Queue_Item;
      To      : in out Balking_Queue) is
   begin
      To.Items := Item & To.Items;
      To.Length := To.Length + 1;
   end;

   procedure Remove_Item
      (From : in out Balking_Queue;
      At_The_Position : in Positive) is
      
      Node : Item_Node_Access := To.Items;
   begin
      for Index in Positive range 2 .. At_The_Position loop
         Node := Node.Next;
      end loop;

      <blah blah blah>
   end;

private

   type Balking_Queue is ...;

end;

But now it's not so obvious how to separate the changes made to the bodies
of the operations from the contract itself.  Just think how much simpler it
is using existing configuration management technology to freeze a
specification, if it's a different text file from the text file containing
the body.  By putting spec and body together, the configuration management
tool has to be smart enough to determine which part is the specification of
the routines and which is the body - much more sophistication than a CM
tool that need only treat everything as mere text.

The change affects only the Balking_Queue subclass - not the abstract
superclass.  That's why I'm not clear how freezing the spec of the root
type really solves anything. Yes, clients who manipulate classwide queue
objects, ie

procedure Op (Queue : in out Root_Queue'Class) is ...

would have a guarantee about the characteristics available for objects of
type Root_Queue'Class, if the abstract superclass were frozen, but I'm
talking about a client who depends on behavior specific to a balking queue:

   The_Queue : Balking_Queue;
   ...
   Remove_Item (From => The_Queue, At_The_Position => N);


It just seems simpler to have a different text file for the spec.  That way
changes to the body can be made with impunity, and the compiler will check
that you haven't changed the contract in any way (because the contract is
kept separate).

There are probably some Eiffel subtleties that I've missed, but I hope I've
been able to explicate the Ada philosophy with respect to separation of
spec and body.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <mheaney-ya023680000409972313230001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In article <EFxww3.2Fp@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
>Doyle) wrote:
>
>>>But this is not quite the same thing as the relationship between a module
>>>specification and its body.  
>>
>>  Ok, I'll boil my position down into one question: What does a separate
>>interface file do for a class that an abstract superclass can't do?
>
>True, an abstract superclass would specify the characteristics common to
>every subclass in that derivation tree, but an interface file ("package
>spec") describes the characteristics of a specific class.  

And this limitation is an advantage somehow?

>The module interface is separate from its body, and can therefore be
>configured separately.  Any changes to the spec have to be coordinated with
>the clients of the package.

If this separate configuration is important, an abstract superclass
could be used, couldn't it?


You nkow what?  I just thought of an argument against myself here.
Tell me what you think...

If abstract superclasses are used as interfaces to a class, then
they are optional.  Thus, the advantages of tracking spec changes
come only when the programmer *chooses* to track them.  Conversely,
*all* spec changes will necessitate alteration of clients, so
arguably *all* classes should have a spec that is somewhat harder
to change.  For Eiffel not to enforce this can cause maintenance
troubles down the road.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[John G. Volan]

Patrick Doyle wrote:
> 
> You nkow what?  I just thought of an argument against myself here.
> Tell me what you think...
> 
> If abstract superclasses are used as interfaces to a class, then
> they are optional.  Thus, the advantages of tracking spec changes
> come only when the programmer *chooses* to track them.  Conversely,
> *all* spec changes will necessitate alteration of clients, so
> arguably *all* classes should have a spec that is somewhat harder
> to change.  For Eiffel not to enforce this can cause maintenance
> troubles down the road.

Various Ada folks in this thread have been hinting at this all along,
but you've finally tumbled to it. It's not surprising that you'd be
conditioned against seeing this, given Eiffel's structure.  Nor is it
surprising that Ada programmers would fail to make a point of this, as
it is something they'd tend to take for granted as "obvious".

In Ada, every package must have a separate spec.  This is true
regardless of whether the class in question has a compelling reason to
be abstract ("deferred").  In fact, Ada treats the notions of "class
interfaces" (package specs) and "abstract classes" (abstract tagged
types) as being totally orthogonal.  Indeed, so does Eiffel, if you
accept that "package spec" is analogous to "short form" and "abstract
tagged type" is analogous to "deferred class."

Ada programmers are conditioned to think in terms of establishing the
"contract" of a package first, by writing its "interface" (spec), before
ever writing a single line of its "implementation" (body).  So Ada
conditions programmers to adhere to a certain engineering discipline. 
Ada programmers tend to understand the difference in engineering impact
between an interface change and an implementation change, because Ada
makes it so obvious.  

In contrast (in my experience) Eiffel programmers tend to have a harder
time even seeing the distinction, given that Eiffel treats the notion of
an "interface-only view of a class which describes its contract" as
something of an afterthought.  (A tad ironic in a language which holds
"Design By Contract" as one of its fundamental principles. :-))

Note that I'm not making a value judgment here, just highlighting the
difference in emphasis between the two languages, and how they condition
programmers to think. I'm sure that Eiffel programmers could point out
issues of central importance in Eiffel which tend to be "blind spots"
for Ada programmers (e.g., assertions).

-- 
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

Re: Separation of IF and Imp: process issue?

[Nick Leaton]

John G. Volan wrote:

> Ada programmers are conditioned to think in terms of establishing the
> "contract" of a package first, by writing its "interface" (spec), before
> ever writing a single line of its "implementation" (body).  So Ada
> conditions programmers to adhere to a certain engineering discipline.
> Ada programmers tend to understand the difference in engineering impact
> between an interface change and an implementation change, because Ada
> makes it so obvious.

And a good job too. I've never understood the aversion people have to
writting code as part of the design process. Writting the spec should be
a major part of the design, and why not write the interface file in the
process.

> In contrast (in my experience) Eiffel programmers tend to have a harder
> time even seeing the distinction, given that Eiffel treats the notion of
> an "interface-only view of a class which describes its contract" as
> something of an afterthought.  (A tad ironic in a language which holds
> "Design By Contract" as one of its fundamental principles. :-))

Not quite. Since in Eiffel you can allow access to different features to
different classes at the feature level, the interface-only view depends
on the which class you want to look at the view from.

For example, an interator would want a different view of a list than a
normal client of list. In each case the specification is different.

> Note that I'm not making a value judgment here, just highlighting the
> difference in emphasis between the two languages, and how they condition
> programmers to think. I'm sure that Eiffel programmers could point out
> issues of central importance in Eiffel which tend to be "blind spots"
> for Ada programmers (e.g., assertions).

The value judgement idea is very relavent. The separate spec with tools
(compiler to check) versus all in with tools (to separate) (and abstract
classes) are two ways of skinning the same cat. Its interesting to
evaluate the reasons behind the choices.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Separation of IF and Imp: process issue?

[Darren New]

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

>Suppose I wanted to change the position from Positive to Natural, because
>for some strange reason I decide I'd rather count starting from 0.  This
>change can't be made indiscriminately, because clients already depend on
>certain behavior (count starting from 1).

In Eiffel, this would be a change in the `requires' clause of the
Remove procedure.  This implies a change in the specification of the
class, just as it does in Ada.

I.e., Remove would change from
  require position > 0
to
  require position >= 0

(Hmmm... Nothing would actually tell the clients that they're invalid 
any more, automatically.  I suppose the same is true of Ada, tho. Do your
Ada tools warn you to go fix all your code that references packages
whose interface has changed since you last editted them? If so, why would
you think the same couldn't be done for Eiffel?)

>But now it's not so obvious how to separate the changes made to the bodies
>of the operations from the contract itself. 

Easy - did the short form change?

>  By putting spec and body together, the configuration management
>tool has to be smart enough to determine which part is the specification of
>the routines and which is the body - much more sophistication than a CM
>tool that need only treat everything as mere text.

I can easily imagine having triggers in CVS at commit time that would
generate the short form, compare it to a saved short form, and
disallow the checkin of the class if the short form
changed. Alternately, it's pretty easy to write a shell script that
takes the file you're trying to checkin and checks out the associated
"locked" short form, comparing the two appropriately.  It doesn't
*have* to be integrated into your CM tool if you have a command-line
CM tool.

Alternately, you *can* use deferred parent classes if your tools are
too primitive to handle derived files.

>The change affects only the Balking_Queue subclass - not the abstract
>superclass.  That's why I'm not clear how freezing the spec of the root
>type really solves anything.

The balking queue is another class, in Eiffel, with its own spec,
etc. I'm not sure I understand the question.  Freezing the spec of
Queue solves the problem of changing Queue, not the problem of changing
Balking_Queue.

>It just seems simpler to have a different text file for the spec.  That way
>changes to the body can be made with impunity, and the compiler will check
>that you haven't changed the contract in any way (because the contract is
>kept separate).

It's true that treating things as separate files is easier with
current tools, but I suspect that's because current tools grew up
around primitive compilers. Of course, it's simpler (in the same
sense) to have the programmer specify inter-file dependencies as well,
as in Makefiles. The fact that current CM tools are better geared
towards separate spec and body doesn't necessarily mean that's a good
way to go.  Obviously, any CM tool written with Eiffel in mind would
allow the kinds of things you use separate files for in Ada, just as
any CM tool written with Ada in mind allows you to extract the body
for a given interface, etc.

If you're working on a project large enough that you're actually
worried about accidentally changing the spec and not realizing it,
you're working on a project large enough to add a macro to generate
and CM your short-forms as well.  :-)  Otherwise, give me a language
where I can put all my punch cards in the same box.  ;-)

>There are probably some Eiffel subtleties that I've missed, but I hope I've
>been able to explicate the Ada philosophy with respect to separation of
>spec and body.

Eiffel's philosophy is to not make the programmer do the same thing
twice, and to put relevant information together. Hence, the programmer
puts the spec and implementation in the same place, and the tools pull
it apart as needed.  I can easily see Ada's style causing a problem if
(for example) the interface declares an offset to be a Natural with a
comment saying "when passed zero, this means the end of the
list". (Probably a stupid thing to do in Ada, but it's an example.) In
this case, a programmer working on the implementation might not see the
comment in the spec and may think the offset starts at zero, miscoding the
implementation in unobvious ways.

Re: Separation of IF and Imp: process issue?

[Matthew Heaney]

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



In article <5upe9k$7he@newshub.atmnet.net>, dnew@zloty.fv.com (Darren New)
wrote:


>(Hmmm... Nothing would actually tell the clients that they're invalid 
>any more, automatically.  I suppose the same is true of Ada, tho. Do your
>Ada tools warn you to go fix all your code that references packages
>whose interface has changed since you last editted them? If so, why would
>you think the same couldn't be done for Eiffel?)

I wasn't trying to disparage Eiffel (which I happen to like); I was trying
to explain to an Eiffel user the rationale for Ada's separation of
interface and implementation.

The point I was trying to make (actually, it was Tuck who explained it
better) concerns precisely the issue you alluded to: that changing the spec
can potentially break its clients.  The spec is a contract, and it can't be
just changed indiscriminantly.  The author of the spec has to go visit the
clients and ask if the change is OK; a negotiation must take place between
spec author and spec users.

The Ada model is that the specification is therefore a contract, to be kept
separate from the implementation.  The programmer of an implementation has
to assert that his body conforms to that contract.  The separation of
interface and implementation also allows the contract to be managed
independently of the implementation, using traditional configuration
management tools.

The Eiffel argument against this model is that it requires the programmer
to write the subprogram signitures twice; this is a fair enough criticism. 
However, if you ask an Ada programmer how he feels about this
"encumbrance," he'll tell you it isn't an encumbrance at all, and that he
actually likes the fact the interface and implemenation are in separate
files.

No one can argue with the philosophy that "a programmer shouldn't have to
write something twice, because if he does so he may make an error, so
there's inconsistancy."  But this is a weak argument against Ada's
separation of spec and body, as the compiler checks that that subprogram
signitures in the spec and body match.  

That this is "manual work better done automatically by a computer rather
than manually by a human programmer" is also a fair criticism, but again a
weak argument.  Many environments will generate the subprogram stubs
automatically, and besides, the signitures are small compared to the rest
of the body.  In any case, the writing of subprogram signitures consumes
only a tiny fraction of the programmer's time.  For example, when I'm
writing a unit, I'll write the spec, compile it, and then use a copy of the
spec as the starting point for the body.  (To be honest, though, I never
write an abstraction in strictly "spec then body" order.)

Eiffel programmers, here's some advice: choose your battles more carefully. 
If you argue against something that isn't that big an issue for the
programmers to whom the issue applies, then it tends to make all your other
(potentially good) arguments suspect.


>>The change affects only the Balking_Queue subclass - not the abstract
>>superclass.  That's why I'm not clear how freezing the spec of the root
>>type really solves anything.
>
>The balking queue is another class, in Eiffel, with its own spec,
>etc. I'm not sure I understand the question.  Freezing the spec of
>Queue solves the problem of changing Queue, not the problem of changing
>Balking_Queue.

I agree; that's the argument exactly.  How would freezing the spec of the
abstract superclass help you do change control on the subclass?  I don't
think that solves the problem of how to manage the specification of an
abstraction.

To get random signatures put text files into a folder called �Random
Signatures� into your Preferences folder.

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <mheaney-ya023680000609971422530001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In article <5upe9k$7he@newshub.atmnet.net>, dnew@zloty.fv.com (Darren New)
>wrote:
>
>
>>(Hmmm... Nothing would actually tell the clients that they're invalid 
>>any more, automatically.  I suppose the same is true of Ada, tho. Do your
>>Ada tools warn you to go fix all your code that references packages
>>whose interface has changed since you last editted them? If so, why would
>>you think the same couldn't be done for Eiffel?)
>
>I wasn't trying to disparage Eiffel (which I happen to like); I was trying
>to explain to an Eiffel user the rationale for Ada's separation of
>interface and implementation.

I understand the rationale. I just disagree with it. :-)

My point was that since changing the spec means you have to go talk to
everyone concerned anyway, I don't see the advantage of putting it in
a separate file.

>The point I was trying to make (actually, it was Tuck who explained it
>better) concerns precisely the issue you alluded to: that changing the spec
>can potentially break its clients.  The spec is a contract, and it can't be
>just changed indiscriminantly.  The author of the spec has to go visit the
>clients and ask if the change is OK; a negotiation must take place between
>spec author and spec users.

Agreed.  So?  Eiffel has specs also, and the specs are separate from
the implementation.  The only question is whether the spec is in the
same "compilation unit" as the implementation.

>The Ada model is that the specification is therefore a contract,

As in Eiffel. Hence the name "Design By Contract".  :-)

> to be kept
>separate from the implementation.

That's the Ada assumption that's a nonsequitar in Eiffel.


>  The programmer of an implementation has
>to assert that his body conforms to that contract. 

As does the programmer of Eiffel bodies, either with or without
abstract parent classes.

> The separation of
>interface and implementation also allows the contract to be managed
>independently of the implementation, using traditional configuration
>management tools.

There's the rub.  My point was, why do you think traditional
configuration management tools can't generate a short form from the
Eiffel class text and disallow checkins that have changed the spec in
incompatible ways? Also, why do you think that a configuration
management tool chosen by a group working in Eiffel wouldn't have that
capability? I then tried to make an analogy with a configuration
management tool (boxes for punch cards) that couldn't handle Ada CM
style, meaning that the failure of current tools to be sufficiently
flexible doesn't mean we should accept a worse solution in terms of
file organization; we should instead make better tools.  (Not to be
taken to mean that Ada is objectively worse. Its choice to separate
spec and body was only worse to those designing Eiffel.)

>The Eiffel argument against this model is that it requires the programmer
>to write the subprogram signitures twice; this is a fair enough criticism. 
>However, if you ask an Ada programmer how he feels about this
>"encumbrance," he'll tell you it isn't an encumbrance at all, and that he
>actually likes the fact the interface and implemenation are in separate
>files.

That's fair too.  I'm not saying Ada is wrong.  I'm just saying that
the expressed reasons for saying Eiffel is wrong are unfounded.  I think 
both methods have good points and bad points.

On the other hand, Eiffel specs are (I think) more expressive and
complete than Ada specs, including preconditions, postconditions,
invariants, and so on, and these things get inherited in sufficiently
complex ways that just looking at the spec on paper is unlikely to be
particularly informative anyway. Hence, typing all the assertions etc in
two separate files is going to be a nightmare.

Note that the Eiffel spec, while intermingled with the implementation,
is clearly separated.  It's unlikely that an Eiffel programmer will
change the spec and not realize it, any more than it's likely a C
programmer will accidentally change the return type of a function and
not realize it.

>No one can argue with the philosophy that "a programmer shouldn't have to
>write something twice, because if he does so he may make an error, so
>there's inconsistancy."  But this is a weak argument against Ada's
>separation of spec and body, as the compiler checks that that subprogram
>signitures in the spec and body match.  

But there's lots more delarations in Eiffel than Ada, I expect. I
thought the only things that go in the Ada header files are
essentially type declarations, not code for invariants, yes?  (No, I
don't know Ada. :-)  Admittedly, Ada's type declarations are much
more powerful, but not as powerful as Eiffel's assertions.

>of the body.  In any case, the writing of subprogram signitures consumes
>only a tiny fraction of the programmer's time. 

And I expect in Eiffel it consumes a fairly large amount of the time, since
the signatures (counting assertions) is a fairly large part of the design
of the program.

>Eiffel programmers, here's some advice: choose your battles more carefully. 
>If you argue against something that isn't that big an issue for the
>programmers to whom the issue applies, then it tends to make all your other
>(potentially good) arguments suspect.

And if you argue that Eiffel should be as easy as Ada in Ada's strong points,
while ignoring Eiffel's strong points, you wind up with odd misunderstandings.
  :-)

>I agree; that's the argument exactly.  How would freezing the spec of the
>abstract superclass help you do change control on the subclass?  I don't
>think that solves the problem of how to manage the specification of an
>abstraction.

This was addressed by someone else. Briefly, there's two abstract classes.
One for QUEUE and one for BALKING_QUEUE, and two implementations.

  --Darren

Re: Separation of IF and Imp: process issue?

[Darren New]

>> The separation of
>>interface and implementation also allows the contract to be managed
>>independently of the implementation, using traditional configuration
>>management tools.
>
>There's the rub.  My point was, why do you think traditional
>configuration management tools can't generate a short form from the
>Eiffel class text and disallow checkins that have changed the spec in
>incompatible ways? 

Actually (following up on my own post) how does a traditional CM tool
make sure the Ada body matches the interface file? Does it actually
run some external tool at checkin time to make sure the equivalence
hasn't been broken?  I mean, if I edit the return type of a function
in the body and not the spec in Ada, how does the CM tool know it won't
compile next time someone checks it out?

It seems to me that if you've solved this problem, you can use exactly
the same approach to solve the problem for Eiffel.

Re: Separation of IF and Imp: process issue?

[Matthew Heaney]

In article <5v1gua$fkk@newshub.atmnet.net>, dnew@zloty.fv.com (Darren New)
wrote:


>Actually (following up on my own post) how does a traditional CM tool
>make sure the Ada body matches the interface file? Does it actually
>run some external tool at checkin time to make sure the equivalence
>hasn't been broken?  I mean, if I edit the return type of a function
>in the body and not the spec in Ada, how does the CM tool know it won't
>compile next time someone checks it out?

The CM tool doesn't know anything about whether the body matches the spec;
it's the compiler that does.  When you compile the body, the compiler will
tell you if the body doesn't match the spec.  The CM tool is dumb (and
presumably simpler because of that), and only treats the spec as lines of
text.

In a sense, a package spec really has 2 clients: the user of the package,
and the package body itself.  Just as there is a runtime check to make sure
the user conforms to the specification, there's an analogous compile-time
check to make sure the body conforms to the spec too.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Separation of IF and Imp: process issue?

[John G. Volan]

Matthew Heaney wrote:
> Just as there is a runtime check to make sure
                     ^^^^^^^

Make that a compile-time check, too.

> the user conforms to the specification, there's an analogous compile-time
> check to make sure the body conforms to the spec too.
-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Separation of IF and Imp: process issue?

[Robert S. White]

In article <5v1gua$fkk@newshub.atmnet.net>, dnew@zloty.fv.com says...
>
>Actually (following up on my own post) how does a traditional CM tool
>make sure the Ada body matches the interface file? Does it actually
>run some external tool at checkin time to make sure the equivalence

  Before most people ever check a module back in they run the compiler
on the module.  If there is a mismatch between the spec and body then
the body won't compile without error.  Any CM tool that does a new
build (as in an overnight or integration build) will run the compiler
on the changed modules and any bodies that are non-compliant will fail 
(sometimes this can cause a $1 fine in some workgroups :-)  Such a 
discipline causes the programmers to take the simple quick step of 
running the compiler on any changed bodies or any bodies that might 
be affected by a changed spec - before the overnight build done from
the CM system.  All of this is for Ada or course.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <5v2k2n$1cfu$2@flood.weeg.uiowa.edu>,
Robert S. White <nospam@somewhere.ia.us> wrote:
>In article <5v1gua$fkk@newshub.atmnet.net>, dnew@zloty.fv.com says...
>>
>>Actually (following up on my own post) how does a traditional CM tool
>>make sure the Ada body matches the interface file? Does it actually
>>run some external tool at checkin time to make sure the equivalence
>
>  Before most people ever check a module back in they run the compiler
>on the module.

And it's trivial to write a script that takes the short form of an Eiffel
class and checks it against the CM'ed short form. If you forget to run
this, you can have a $1 fine. :-)

My point is that having the spec and implementation in the same file
is *not* any more of a handicap for Eiffel than having to run the
compiler to check the body against the spec is in Ada.

Of course, Eiffel then gives you the ability to use abstract classes as 
specs as well, but that's a different discussion.

  -- Darren

Re: Separation of IF and Imp: process issue?

[Nick Leaton]

Darren New wrote:

> >>
> >>Actually (following up on my own post) how does a traditional CM tool
> >>make sure the Ada body matches the interface file? Does it actually
> >>run some external tool at checkin time to make sure the equivalence
> >
> >  Before most people ever check a module back in they run the compiler
> >on the module.
> 
> And it's trivial to write a script that takes the short form of an Eiffel
> class and checks it against the CM'ed short form. If you forget to run
> this, you can have a $1 fine. :-)
> 
> My point is that having the spec and implementation in the same file
> is *not* any more of a handicap for Eiffel than having to run the
> compiler to check the body against the spec is in Ada.
> 
> Of course, Eiffel then gives you the ability to use abstract classes as
> specs as well, but that's a different discussion.

Another issue concerning the separation of spec and implementation
concerns how inheritance is handled.

If you use inheritance, then the specification of a class can be viewed
in different ways.

1) As the inherited class, with any additional specification 

2) As the union of all the classes features, with those of the class it
inherits 
   from. (Repeat as necessary)

Now, in either case Eiffel's one file, or with an Ada style, two file
system, you
are going to require machine help to produce 2.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <34158D84.299F6103@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> If you use inheritance, then the specification of a class can be viewed
> in different ways.
> 
> 1) As the inherited class, with any additional specification 
> 
> 2) As the union of all the classes features, with those of the class it
> inherits 
>    from. (Repeat as necessary)
> 
> Now, in either case Eiffel's one file, or with an Ada style, two
> file system, you are going to require machine help to produce 2.

Which is a kind of 'round about way of indicating that OOP can be a
maintenance nightmare if not used very carefully.  It basically
results in a kind of "structured spaghetti code" (borrowing one of
Paul Graham's descriptions of it).

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Jon said

<<Which is a kind of 'round about way of indicating that OOP can be a
maintenance nightmare if not used very carefully.  It basically
results in a kind of "structured spaghetti code" (borrowing one of
Paul Graham's descriptions of it).>>


It is interesting to consider the view of the anti-use fanatics in the
Ada world. The argument about always using dots is that it is essential
to clearly know at all times where the thing you are calling is located.

But of course in a sense the whole idea of dynamic dispatching (I do wish
people would use exact features in discussions, and not the vague meaningless
catchall term OOP), is to make sure that you do NOT know where the code
you are calling is!

This does not mean it is terrible to use DD (indeed, as you know, I don't
think it is so terrible to use USE clauses). But it is a reminder that just
as overuse and incorrect use of USE can cause mainteance problems, overuse
and incorrect use of dynamic dispatching can be even worse (at least in the
former case, a simple static tool can put the dots back in for you).

Re: Separation of IF and Imp: process issue?

[Samuel T. Harris]

Robert Dewar wrote:
> 
> Jon said
> 
> <<Which is a kind of 'round about way of indicating that OOP can be a
> maintenance nightmare if not used very carefully.  It basically
> results in a kind of "structured spaghetti code" (borrowing one of
> Paul Graham's descriptions of it).>>
> 
> It is interesting to consider the view of the anti-use fanatics in the
> Ada world. The argument about always using dots is that it is essential
> to clearly know at all times where the thing you are calling is located.
> 
> But of course in a sense the whole idea of dynamic dispatching (I do wish
> people would use exact features in discussions, and not the vague meaningless
> catchall term OOP), is to make sure that you do NOT know where the code
> you are calling is!
> 
> This does not mean it is terrible to use DD (indeed, as you know, I don't
> think it is so terrible to use USE clauses). But it is a reminder that just
> as overuse and incorrect use of USE can cause mainteance problems, overuse
> and incorrect use of dynamic dispatching can be even worse (at least in the
> former case, a simple static tool can put the dots back in for you).

This ties in two other responses I've just made to two other threads.
Conservative projects put strict controls on the use of "use".
While I don't agree with all the "justifications" concerning the
risks of "use", I also don't feel the limited use of "use" is
particularly
restrictive. Bottom line, I treat is as a issue of style and I try
not to lose any hair over it (those who know me know I've lost enough
hair already :)

As to the issue of "needed" explicit, fully described calls to
subprograms
and such, the proliferation of smart Ada browsers, editors, and
preparation tools such as Apex, Emacs with the Ada stuff, ada2html
for Web browsers make these arguments moot. Only code reviewers who
are limited (or limit themselves) to simply ASCII text or hard copy
need be of concern with such issues. Indeed, with Apex, I can take
code and do a "complete" operation on it and I get full dot notation
for subprogram calls AND named notation instead of positional
(I don't know is Emacs can do this) so I can easily accomodate
such folks when the need arises.

My point here is that with the sophistication of the tools available,
many of which are free, human readability issues in day-to-day work
are really non-issues. Of course, hard copy source also
appears in books so language design should always be concerned
with such things that satisfy the lower form of representation,
but with good tools the world I'm in and share with others is
free from such concerns.

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

Re: Separation of IF and Imp: process issue?

[Mark A Biggar]

In article <5v4095$h62@newshub.atmnet.net> dnew@zloty.fv.com (Darren New) writes:
>In article <5v2k2n$1cfu$2@flood.weeg.uiowa.edu>,
>Robert S. White <nospam@somewhere.ia.us> wrote:
>And it's trivial to write a script that takes the short form of an Eiffel
>class and checks it against the CM'ed short form. If you forget to run
>this, you can have a $1 fine. :-)

If you are going to do this (have the short form exist as an actual
separate configuration item) then all the supposed advantages of having 
only a single file just went up in smoke.  You might as well have sparate
spec and bodies.

--
Mark Biggar
mab@wdl.lmco.com

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <5v4g00$pjr@wdl1.wdl.lmco.com>,
Mark A Biggar <mab@dst1.wdl.loral.com> wrote:
>In article <5v4095$h62@newshub.atmnet.net> dnew@zloty.fv.com (Darren New) writes:
>>In article <5v2k2n$1cfu$2@flood.weeg.uiowa.edu>,
>>Robert S. White <nospam@somewhere.ia.us> wrote:
>>And it's trivial to write a script that takes the short form of an Eiffel
>>class and checks it against the CM'ed short form. If you forget to run
>>this, you can have a $1 fine. :-)
>
>If you are going to do this (have the short form exist as an actual
>separate configuration item) then all the supposed advantages of having 
>only a single file just went up in smoke.

Not at all. You still have the advantage that the specification is "in
your face" while you're editing the implementation, and hence less is
likely to get overlooked. You also have the advantage of not needing
to do that for small projects, or for helper modules that are private
to a single other module. You still have *all* the advantages. You
also have the advantage that your tools might be simpler to write, and
you have the advantage that your public postconditions and private
postconditions are in the same place when you're working on the thing
that's concerned with both.

You just get told when you change the spec by mistake.

What advantages of having only one file for both spec and body do you
think you lose with this approach?

>  You might as well have sparate
>spec and bodies.

I just told you how to kludge it given you have inadiquate CM tools,
kind of as an existance proof that you don't *lose* anything by having
spec and body in the same file. I certainly don't think this is a
preferred approach.  

Personally, I think the preferred approach would be an editor that
would recognise whether a class is "frozen" or not and simply not let
you edit the part that's frozen.  You can insert postconditions, but
not delete them, unless they're not public postconditions, for
example. The ISE tool already disallows saving of an editted class
file that's syntactically invalid, so it's not like it's particularly
difficult to conceptualize how to do it.

Re: Separation of IF and Imp: process issue?

[Joerg Rodemann]

Darren New (dnew@zloty.fv.com) wrote:
> Not at all. You still have the advantage that the specification is "in
> your face" while you're editing the implementation, and hence less is
> likely to get overlooked. You also have the advantage of not needing
> to do that for small projects, or for helper modules that are private
> to a single other module. You still have *all* the advantages. 

Well, you really must have huge screens...I myself prefer having to editor
windows: one for the spec and one for the body. Otherwise those things
that are currently interesting to me always happen to have just scrolled
out of view. And one thing with Java I do not like at all ist this: you
need to search the complete (and often long) file for getting an idea
what methods, variables the class contains. I'd hav to write an extraction
tool of my own and unfortunately I have no time for that right now.

So, I do believe that you Eiffel programmers use a similar approach: normal
view to the complete text and an overview by short-flat forms. (Strange
word... :-) ) Thus your argument does not hold at all.

Considering small projects, I'd like to cite Mr. G. Booch:
"A complex system that works is invariably found to have evolved from a 
simple system that worked."
(Object-Oriented Analysis and Design with Applications, 2nd ed., 1994,
p. 13)

How are you migrating a small project to a big one, when your team decides
the tool/class you wrote is suitable? Or if it simply keeps growing?

Just some thoughts

Yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <341787a6.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>
>Darren New (dnew@zloty.fv.com) wrote:
>> Not at all. You still have the advantage that the specification is "in
>> your face" while you're editing the implementation, and hence less is
>> likely to get overlooked. You also have the advantage of not needing
>> to do that for small projects, or for helper modules that are private
>> to a single other module. You still have *all* the advantages. 
>
>Well, you really must have huge screens...I myself prefer having to editor
>windows: one for the spec and one for the body.

But that's because *your* spec and body are separate, don't you see?
Having the spec and body intermingled so the bits of the spec relevant
to the bits of the body it's specifying are next to each other makes
it unnecessary to have "huge screens". If your average body is maybe
ten lines long, and your spec is maybe five lines long, and they're
always next to each other, why do you need a big screen?

> Otherwise those things
>that are currently interesting to me always happen to have just scrolled
>out of view.

Heck, emacs handles this on a VT100. 

> And one thing with Java I do not like at all ist this: you
>need to search the complete (and often long) file for getting an idea
>what methods, variables the class contains. I'd hav to write an extraction
>tool of my own and unfortunately I have no time for that right now.

Ummmm, surely you've heard of Javadoc?  It's free, ya know, and it
comes with Java.

>So, I do believe that you Eiffel programmers use a similar approach: normal
>view to the complete text and an overview by short-flat forms. (Strange
>word... :-) ) Thus your argument does not hold at all.

Right. But when you're viewing the complete text, you're viewing the
spec *and* the implementation, and when you're viewing the "overview"
you're viewing the spec by itself.  I'm confused about why you seem to
think this obviates my argument that when you're editing the body
it's easy to see the relevant parts of the spec.

>How are you migrating a small project to a big one, when your team decides
>the tool/class you wrote is suitable? Or if it simply keeps growing?

We hand it to the customer and say "Here, this is what you paid for." ;-)

Seriously, I don't know what you're asking.  --Darren

Re: Separation of IF and Imp: process issue?

[Joerg Rodemann]

Darren New (dnew@zloty.fv.com) wrote:
> In article <341787a6.0@news.uni-ulm.de>,
> Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
> >Well, you really must have huge screens...I myself prefer having to editor
                                                                    ^^ two
> >windows: one for the spec and one for the body.

> But that's because *your* spec and body are separate, don't you see?
> Having the spec and body intermingled so the bits of the spec relevant
> to the bits of the body it's specifying are next to each other makes
> it unnecessary to have "huge screens". If your average body is maybe
> ten lines long, and your spec is maybe five lines long, and they're
> always next to each other, why do you need a big screen?

Do you think this is realistic? Sure I have lots of short methods. But I also
have some really huge ones. Perhaps if I had to write them now, maybe I would
split them into smaller methods, but on the other hand maybe not. Since I
did not write the code I have no choice: there just are some very long
method bodys and I have the honor to change them... By the way: have you
already looked at lots of Java code? It is often already difficult to
FIND the specification visually. And den code often is not short at all.
No 5 line spec and 10 line method body. *shrug* Just my experience. Maybe
I am doing it all wrong? Give me some divine insights.

Concerning JavaDoc: sure I had a look at it, but I did not fit my expectations
as a tool to work with while developping. It's probably very good for end
documentation. Nicely formatted and such things. But for work its output is
IMHO too long.

> >How are you migrating a small project to a big one, when your team decides
> >the tool/class you wrote is suitable? Or if it simply keeps growing?

> We hand it to the customer and say "Here, this is what you paid for." ;-)

Say, the costumer comes up to you and tells you: "Well, pretty nice thing
you built. Lots of good. But now we want it do have feature x, y, z. Sure
you can do that, can't you? We saw something like that in product B so
of course this should not be to serious for you?" Do you then have the guts
to tell them that this approach is often very risky? 

What I meant with my comment was that if you think you can program in the
small you must be sure it will stay that way. You might get into serious
trouble if you use such code in a big project. I know it is sometimes
very easy to argue "Well, I will just build this little tool for me, so
I need not care about proper design and implementation. It just has to work."
This is something what I call a "quick hack". And these things cause lots
of problems...

Regards

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <3418f6db.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>
>Darren New (dnew@zloty.fv.com) wrote:
>> In article <341787a6.0@news.uni-ulm.de>,
>> Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>> >Well, you really must have huge screens...I myself prefer having to editor
>                                                                    ^^ two
>> >windows: one for the spec and one for the body.
>
>> But that's because *your* spec and body are separate, don't you see?
>> Having the spec and body intermingled so the bits of the spec relevant
>> to the bits of the body it's specifying are next to each other makes
>> it unnecessary to have "huge screens". If your average body is maybe
>> ten lines long, and your spec is maybe five lines long, and they're
>> always next to each other, why do you need a big screen?
>
>Do you think this is realistic? Sure I have lots of short methods. But I also
>have some really huge ones.

Well, me too, of course. But I find I tend to write lots of small
routines with OO programming, Lisp, and FORTH, and larger routines
with other types of programming.  But you conveniently axed out the part 
about Emacs.  Why do you take the three solutions I offer to a problem,
axe out two, then complain that the third doesn't solve every problem? :-)

>method bodys and I have the honor to change them... By the way: have you
>already looked at lots of Java code? It is often already difficult to
>FIND the specification visually. And den code often is not short at all.
>No 5 line spec and 10 line method body. *shrug* Just my experience. Maybe
>I am doing it all wrong? Give me some divine insights.

I find most of the Java code that's long is doing too much in one routine, 
for my tastes. Long routines wind up looking like C libraries instead of
OO classes. I break up Java code into fairly small chunks too. 

>Concerning JavaDoc: sure I had a look at it, but I did not fit my expectations
>as a tool to work with while developping. 

Fair enough.  I have seen any number of tools that will parse
Java/C++/etc and provide the kinds of things you might be looking
for. They just happen to cost a few hundred dollars.

>> >How are you migrating a small project to a big one, when your team decides
>> >the tool/class you wrote is suitable? Or if it simply keeps growing?
>
>> We hand it to the customer and say "Here, this is what you paid for." ;-)
>
>Say, the costumer comes up to you and tells you: "Well, pretty nice thing
>you built. Lots of good. But now we want it do have feature x, y, z. Sure
>you can do that, can't you? We saw something like that in product B so
>of course this should not be to serious for you?" Do you then have the guts
>to tell them that this approach is often very risky? 

It's usually not my decision. Fortunately, in the company I'm at now, YES, 
the engineering department says "how much do you want to expand it" and then
gives different estimates.

In earlier companies, that was always a problem, yes. We migrates small
programs to big one over many years and many changes in operating systems
and laws and business rules.

>What I meant with my comment was that if you think you can program in the
>small you must be sure it will stay that way. You might get into serious
>trouble if you use such code in a big project. I know it is sometimes
>very easy to argue "Well, I will just build this little tool for me, so
>I need not care about proper design and implementation. It just has to work."
>This is something what I call a "quick hack". And these things cause lots
>of problems...

It depends on how crutial the tool is for your work. The tools *I* use
to make my emacs programming easier don't need to be used by anyone
but me, no matter how large the project gets.  If it's generally used, 
then yes, of course it has to be done right.  What's your point?

And yes, I know the difference between an internal tool and a class that's 
likely to wind up in a production environment, and I code the two differently.
What's your point?

 --Darren

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <5v4g00$pjr@wdl1.wdl.lmco.com>,
Mark A Biggar <mab@dst1.wdl.loral.com> wrote:
>
>If you are going to do this (have the short form exist as an actual
>separate configuration item) then all the supposed advantages of having 
>only a single file just went up in smoke.  You might as well have sparate
>spec and bodies.

That's not true.  Proof by counterexample:

One advantage of having them in the same file is less typing for the
programmer.  This advantage still exists.

 -PD


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Peter Hermann]

Patrick Doyle (doylep@ecf.toronto.edu) wrote:
> One advantage of having them in the same file is less typing for the
> programmer.  This advantage still exists.
               This advantage
is of weight zero. At times of card punch it was slightly different.
As a matter of fact, the only repetitious action is to just copy the
name and signature of subprograms into the body, which I even consider a
helpful, language-driven_thus_compiler-checked confirmation of consistency.

BTW, the more I read this very long, very interesting thread,
I am pleasantly confirmed in my decade-long prefence for Ada.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Patrick says

<<One advantage of having them in the same file is less typing for the
programmer.  This advantage still exists.>>

In the Ada world, we do not pay much attention to such arguments, since
we favor readability over writability in an absolute manner. I realize this
is an unusual language design strategy, but it is appropriate for dealing
with maintainabvility in very large systems.

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

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

> Patrick says
> 
> <<One advantage of having them in the same file is less typing for the
> programmer.  This advantage still exists.>>
> 
> In the Ada world, we do not pay much attention to such arguments, since
> we favor readability over writability in an absolute manner. I realize this
> is an unusual language design strategy, but it is appropriate for dealing
> with maintainabvility in very large systems.

Not to mention it is just plain wrong.  You can put them in the same
file - how is there less typing?

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <5v4095$h62@newshub.atmnet.net> dnew@zloty.fv.com (Darren New) writes:

> >  Before most people ever check a module back in they run the compiler
> >on the module.
> 
> And it's trivial to write a script that takes the short form of an Eiffel
> class and checks it against the CM'ed short form. If you forget to run
> this, you can have a $1 fine. :-)
> 
> My point is that having the spec and implementation in the same file
> is *not* any more of a handicap for Eiffel than having to run the
> compiler to check the body against the spec is in Ada.

??? By your own description above, the handicap is having to hack the
scripts and glue them together in obvious non standard ways.  Shrug.


> Of course, Eiffel then gives you the ability to use abstract classes as 
> specs as well, but that's a different discussion.

No, that's just basically wrong.  Abstract classes are like abstract
types in Ada, not specs.  The short form is the analogue of the spec.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Matt Kennel (Remove 'NOSPAM' to reply)]

:
:> Of course, Eiffel then gives you the ability to use abstract classes as 
:> specs as well, but that's a different discussion.
:
:No, that's just basically wrong.  Abstract classes are like abstract
:types in Ada, not specs.

Why?  Aren't Eiffel classes like abstract types in Ada, *and* specs?  What
is the problem? 

The only distinction I see is that Ada requires a separate spec for
each concrete class, but Eiffel does not, though it permits abstract classes
which would work in the same way.

I can hardly see this as an important missing ability of Eiffel.

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Separation of IF and Imp: process issue?

[Brian Rogoff]

On 10 Sep 1997, Matt Kennel (Remove 'NOSPAM' to reply) wrote:
> :No, that's just basically wrong.  Abstract classes are like abstract
> :types in Ada, not specs.
> 
> Why?  Aren't Eiffel classes like abstract types in Ada, *and* specs?  What
> is the problem? 
> 
> The only distinction I see is that Ada requires a separate spec for
> each concrete class, 

False. I can stick as many concrete or abstract classes into a spec as I 
want. And if I desired, I could define classes inside a body and they 
would be invisible outside of it, and have no spec (I haven't desired that 
yet).  

Why is it that so many people feel compelled to guess about how Ada works,
when the Rationale, Reference Manual, Annotated Reference Manual and
numerous tutorials are all *freely* available? 

-- Brian

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <slrn61e8m1.iul.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:

> :No, that's just basically wrong.  Abstract classes are like abstract
> :types in Ada, not specs.
> 
> Why?  Aren't Eiffel classes like abstract types in Ada, *and* specs?  What
> is the problem? 

For all the reasons people have been giving over the last month.  Read
the Ada RM and you too will twig the difference.  Also, no one ever
said there was a "problem" - the things are just simply _different_.
Why you should think that a problem is beyond me.


> The only distinction I see is that Ada requires a separate spec for
> each concrete class

This is _clearly_ wrong.  Specs. (as many have pointed out) are not in
any sort of 1-1 relationship with "classes" or types.  You can put as
many concrete and/or abstract classes/types in a spec. as you want.

> I can hardly see this as an important missing ability of Eiffel.

I don't care if it is in Eiffel or not.  I don't care if anyone thinks
it is "important" or not.  Why should I care one RA about whether it
is in Eiffel??  Other people (apparently yourself included) are the
ones flipping out over how this might be a "problem" or missing in
Eiffel.  I'm merely pointing out that the things in question are
_different_ and that difference is _clearly_ objective.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Sep9185040@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <5v4095$h62@newshub.atmnet.net> dnew@zloty.fv.com (Darren New) writes:
>
>> And it's trivial to write a script that takes the short form of an Eiffel
>> class and checks it against the CM'ed short form. If you forget to run
>> this, you can have a $1 fine. :-)
>> 
>> My point is that having the spec and implementation in the same file
>> is *not* any more of a handicap for Eiffel than having to run the
>> compiler to check the body against the spec is in Ada.
>
>??? By your own description above, the handicap is having to hack the
>scripts and glue them together in obvious non standard ways.  Shrug.

These "scripts" could be tools which are included with the compiler.
You use a tool to make sure the interface is not altered.  We could
do the same.

>> Of course, Eiffel then gives you the ability to use abstract classes as 
>> specs as well, but that's a different discussion.
>
>No, that's just basically wrong.  Abstract classes are like abstract
>types in Ada, not specs.  The short form is the analogue of the spec.

Where have you been, Jon?  We've been going over this for at least a
week now, and I (among others, I hope :-) disagree, and you know that.
So to make this statement with no "I think" or "IMHO" in front of
it seems a bit careless to me.  Is your opinion (above) right because 
you think it is?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EGBFp4.C28@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >No, that's just basically wrong.  Abstract classes are like abstract
> >types in Ada, not specs.  The short form is the analogue of the spec.
> 
> Where have you been, Jon?  We've been going over this for at least a
> week now, and I (among others, I hope :-) disagree, and you know that.
> So to make this statement with no "I think" or "IMHO" in front of
> it seems a bit careless to me.  Is your opinion (above) right because 
> you think it is?

This particular point is not a matter of opinion.  Package specs. and
abstract/deferred classes are simply and objectively different things.

Read the Ada RM and then have another go at this.  You will see that
the things are clearly different.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Robert A Duff]

In article <JSA.97Sep11202712@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>This particular point is not a matter of opinion.  Package specs. and
>abstract/deferred classes are simply and objectively different things.

Actually, they seem pretty similar to me.  They both define interfaces.
Yes, there are various differences, but the unlerlying thing is that
abstract_types=deferred_classes are pretty similar to package specs,
in some interesting ways.  That's an opinion, like it or not.

>Read the Ada RM and then have another go at this.  You will see that
>the things are clearly different.

Yes, they are somewhat different.  (I had a hand in writing the Ada RM,
and I know quite well how they're different!)  But they still both have
the same goal of defining an interface.

I think Patrick's point is well taken: Why does Ada have both abstract
types (which define an interface) and package specs (which define an
interface)?  I think there are good answers to that question, but merely
saying, "well, abstract types are totally different from package specs
(look at these details)" doesn't do it.

- Bob

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EGEyry.6v6@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <JSA.97Sep11202712@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >This particular point is not a matter of opinion.  Package specs. and
> >abstract/deferred classes are simply and objectively different things.
> 
> Actually, they seem pretty similar to me.  They both define interfaces.

Similar is irrelevant.  That's not the point.  And they are not
particularly similar anyway.  You might as well say that the Rock of
Gibraltor is similar to my piece of chalk.  Under certain very special
circumstances that might actually tell you something useful.  Under
typical circumstances that just confuses things.  They are very
different in what they do and how they do it.


> Yes, there are various differences, but the unlerlying thing is that
> abstract_types=deferred_classes are pretty similar to package specs,
> in some interesting ways.  That's an opinion, like it or not.

I don't care if they can be seen as "similar" in some respects.  They
are far more different than alike.  You might as well say that since
Eiffel is similar to Ada in some respects, Eiffel _is_ Ada (or
vice-versa)


> >Read the Ada RM and then have another go at this.  You will see that
> >the things are clearly different.
> 
> Yes, they are somewhat different.  (I had a hand in writing the Ada RM,
> and I know quite well how they're different!)  But they still both have
> the same goal of defining an interface.

Actually package specs. don't define an interface - though they
certainly play a role in many (by providing the boundaries where
"primitive ops" and such are allowed when defining an interface).  I
can define a type and a set of operations on it in a package body or
subprogram => package spec. not necessary for interface.  I can define
an empty package spec => package spec. not sufficient for an
interface.  Sounds like a package spec. is neither necessary nor
sufficient for an interface.


> I think Patrick's point is well taken: Why does Ada have both abstract
> types (which define an interface) and package specs (which define an
> interface)?

Why it has both is a separate issue.  Whether having both is "good" or
not is a separate issue.


> saying, "well, abstract types are totally different from package specs
> (look at these details)" doesn't do it.

Tell you what - show me how you derive "concrete package specs" from
others, create instances for package specs., define methods on package
specs., dispatch over package specs. and I'll start thinking that
maybe you have a point.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[news_check.py]

In article <34158D84.299F6103@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> wrote:
> Darren New wrote:
> 
> > >>

Darren New wrote:

> >>
> >>Actually (following up on my own post) how does a traditional CM tool
> >>make sure the Ada body matches the interface file? Does it actually
> >>run some external tool at checkin time to make sure the equivalence
> >
> >  Before most people ever check a module back in they run the compiler
> >on the module.
> 
> And it's trivial to write a script that takes the short form of an Eiffel
> class and checks it against the CM'ed short form. If you forget to run
> this, you can have a $1 fine. :-)
> 
> My point is that having the spec and implementation in the same file
> is *not* any more of a handicap for Eiffel than having to run the
> compiler to check the body against the spec is in Ada.
> 
> Of course, Eiffel then gives you the ability to use abstract classes as
> specs as well, but that's a different discussion.

Another issue concerning the separation of spec and implementation
concerns how inheritance is handled.

If you use inheritance, then the specification of a class can be viewed
in different ways.

1) As the inherited class, with any additional specification 

2) As the union of all the classes features, with those of the class it
inherits 
   from. (Repeat as necessary)

Now, in either case Eiffel's one file, or with an Ada style, two file
system, you
are going to require machine help to produce 2.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Darren says

<<Robert S. White <nospam@somewhere.ia.us> wrote:
>In article <5v1gua$fkk@newshub.atmnet.net>, dnew@zloty.fv.com says...
>>
>>Actually (following up on my own post) how does a traditional CM tool
>>make sure the Ada body matches the interface file? Does it actually
>>run some external tool at checkin time to make sure the equivalence
>
>  Before most people ever check a module back in they run the compiler
>on the module.

And it's trivial to write a script that takes the short form of an Eiffel
class and checks it against the CM'ed short form. If you forget to run
this, you can have a $1 fine. :-)

My point is that having the spec and implementation in the same file
is *not* any more of a handicap for Eiffel than having to run the
compiler to check the body against the spec is in Ada.

Of course, Eiffel then gives you the ability to use abstract classes as
specs as well, but that's a different discussion.>>


Many of these posts make me think that the authors have not really worked
in a configuration managed environment. We keep getting responses like
"well the error will be found elsewhere". Configuration management is
not about preventing specific errors, like a body spec mismatch, it is
about enforcing high level procedures concering access and responsibility
and version integrity. These procedures are (one part) of a complete
software process regime designed to ensure high reliability at all levels.

CM per se is never about ensuring semantic consistency between files checked
into the CM. After all, semantic consistency, defined at the highest level
of abstraction, means that your application is correct, and we certainly do
not know how to design a CM system that will only accept completely correct
units!!!


So, let me repeat my question of before, who among you Eiffel programmers
HAS worked in a fully configuration managed environment (and I mean more
than simply using RCS to check in and check out files, though even here
the point about separate specs and bodies is relevant)? It would be
interesting to hear how you handle the issue of access rights for
modification of specifications (i.e. short forms)

Re: Separation of IF and Imp: process issue?

[Owen Fellows]

Robert Dewar wrote:

> So, let me repeat my question of before, who among you Eiffel programmers
> HAS worked in a fully configuration managed environment (and I mean more
> than simply using RCS to check in and check out files, though even here
> the point about separate specs and bodies is relevant)? It would be
> interesting to hear how you handle the issue of access rights for
> modification of specifications (i.e. short forms)

I've worked in both. 

In my current enviroment, if you change the spec, you have to make the 
changes so nothing is broken, and that includes updating the regression
tests.

In other words, your responsible.

Nick (From Owen's account)

Re: Separation of IF and Imp: process issue?

[Fergus Henderson]

dnew@zloty.fv.com (Darren New) writes:

>>There's the rub.  My point was, why do you think traditional
>>configuration management tools can't generate a short form from the
>>Eiffel class text and disallow checkins that have changed the spec in
>>incompatible ways? 

Often you don't want to actually _disallow_ such checkins.  It is just
important that they be given more visibility.  For example, there may
be a guideline such as "any change to the library interface should be
accompanied by a change to the NEWS file".  This is a guideline, not a
rule, and it should not be enforced by the configuration management
tool (at least not until configuration management tools get a lot
smarter! ;-).  But if it is not _immediately obvious_ to those
reviewing a change which parts of the change are interface changes,
then they may not realize the significance of those parts, and they may
easily

>Actually (following up on my own post) how does a traditional CM tool
>make sure the Ada body matches the interface file? Does it actually
>run some external tool at checkin time to make sure the equivalence
>hasn't been broken?  I mean, if I edit the return type of a function
>in the body and not the spec in Ada, how does the CM tool know it won't
>compile next time someone checks it out?

Sometimes such checks are run at checkin time; for example, Robert Dewar
has explained how ACT have a checkin server that receives checkins, builds
the software, and runs their test suite; only if these tests pass will
the checkin be accepted.  Another common mode of operation is to run
nightly tests via cron; with this scheme, violations might not be
caught at checking time, but they would be caught overnight.

>It seems to me that if you've solved this problem, you can use exactly
>the same approach to solve the problem for Eiffel.

I don't think it's as easy as that, because of the humans in the loop.

One approach that might work would be for the CM tool to require
the log message accompanying a change to specify which interfaces
had been modified, and for the tool to verify that only those
interfaces had changed.  But I'll bet most Eiffel developers
don't use a CM tool with that sort of support.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Separation of IF and Imp: process issue?

[Paul Johnson]

In article <5v4093$of7@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU says...

> But if it is not _immediately obvious_ to those
>reviewing a change which parts of the change are interface changes,
>then they may not realize the significance of those parts, and they may
>easily

I assume you were about to say "may easily miss it".

This is not a problem for Eiffel programmers.  The interface and
implementation are visually very distinct in the class text.  Roughly
speaking, implementation is anything in "do" or "once" clauses, and any
features clauses with restricted export.  Interface is everything else.


>One approach that might work would be for the CM tool to require
>the log message accompanying a change to specify which interfaces
>had been modified, and for the tool to verify that only those
>interfaces had changed.  But I'll bet most Eiffel developers
>don't use a CM tool with that sort of support.

As I said elsewhere, this is probably because Eiffel programmers don't
actually need this level of CM support.  Simple inspection and testing
seems to do perfectly well.  The point of this thread is that if you
program in Eiffel but still want this kind of CM support, you can have
it by writing a few lines of Perl.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Darren said

<<>>There's the rub.  My point was, why do you think traditional
>>configuration management tools can't generate a short form from the
>>Eiffel class text and disallow checkins that have changed the spec in
>>incompatible ways?>>

What "traditional configuration management tools" are you referring to,
and what makes you think they *can* do what you describe. I can imagine
a Continuus component that might be able to do this, but it is not
obvious to me how it would be integrated into the Continuus system,
and what I would be interested in is how this is done. if you have
successfully used a system that behaves as you describe above, can
you give more details?

Re: Separation of IF and Imp: process issue?

[W. Wesley Groleau x4923]

> And if you argue that Eiffel should be as easy as Ada in Ada's strong 
> points, while ignoring Eiffel's strong points, you wind up with odd 
> misunderstandings.

That's not what happened.  Ada folks claimed that separation of
spec and body was an advantage.  Eiffel folks responded, "No, it's 
not, because we can simulate it this way."  Ada folks said, "If
you have to do something kludgey to simulate it, then it is an
advantage of Ada."

That may be "ignoring Eiffel's strong points," but it is not
denying them...

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <341431A5.8E2@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>> And if you argue that Eiffel should be as easy as Ada in Ada's strong 
>> points, while ignoring Eiffel's strong points, you wind up with odd 
>> misunderstandings.
>
>That's not what happened.  Ada folks claimed that separation of
>spec and body was an advantage.  Eiffel folks responded, "No, it's 
>not, because we can simulate it this way."  

I think my response was more like "Yes, it is, and here's how we
can do it in Eiffel".

The Eiffel way of doing it takes not one more line of code and not
one more file.  It's very, very similar to the Ada method, except
that the implementation needs a different name from the interface.
Oh, and the Eiffel way is arguably more flexible because it has
all the capabilities of regular old abstract classes (such as
renaming, feature body freezing, etc.).

I don't see it as a kludge at all.  

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Joerg Rodemann]

Darren New (dnew@zloty.fv.com) wrote:

> On the other hand, Eiffel specs are (I think) more expressive and
> complete than Ada specs, including preconditions, postconditions,
> invariants, and so on, and these things get inherited in sufficiently
> complex ways that just looking at the spec on paper is unlikely to be
> particularly informative anyway. Hence, typing all the assertions etc in
> two separate files is going to be a nightmare.

What about having pre- and postconditions in the spec file? At least for
predconditions this should be possible. Postconditions may depend on internal
and thus private class information, so there might be a problem. Realize also
that not everything from the Ada spec is repeated ind the body: type or task
declarations for instance. 

> Note that the Eiffel spec, while intermingled with the implementation,
> is clearly separated.  It's unlikely that an Eiffel programmer will
> change the spec and not realize it, any more than it's likely a C
> programmer will accidentally change the return type of a function and
> not realize it.

<sarcasm>Oh, really?</sarcasm> I can garantuee you at list in C this is
very likely to happen: all you have to do is to (ooops) delete the return
type --- voila. Why not use an int return type instead? And thanks to 
implicit type cast you'll never know until you start wondering about those
very strange looking results your program produces. :-)
At least that's one of the advantages of C++ over C: it is not so likely this
will happen when you wrap everything in classes. 

> But there's lots more delarations in Eiffel than Ada, I expect. I
> thought the only things that go in the Ada header files are
> essentially type declarations, not code for invariants, yes?  (No, I
> don't know Ada. :-)  Admittedly, Ada's type declarations are much
> more powerful, but not as powerful as Eiffel's assertions.

I'd like to agree that --- if you fiddle around with large logical expressions
or something it may take some time until  it's correct in both places. Again
I wonder if it would be easy to have those pre- and postconditions in a
spec file. Or are they often too dependent on class internals? If so how
can they describe a contract between a client who certainly should not know
anything about the private parts of the class? Well, just an idea...

> >I agree; that's the argument exactly.  How would freezing the spec of the
> >abstract superclass help you do change control on the subclass?  I don't
> >think that solves the problem of how to manage the specification of an
> >abstraction.

> This was addressed by someone else. Briefly, there's two abstract classes.
> One for QUEUE and one for BALKING_QUEUE, and two implementations.

Hm, I believe the problem is: you may use the QUEUE class as an interface
but you might change you opinion later and use it just as a base class.
Then you need to write a new spec and the old one is obsolete as an interface.
This is not my idea of an interface clients can rely on. If there is a
possiblity of freezing the short-form(?) this is more what we are looking
for.

Yours

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Separation of IF and Imp: process issue?

[W. Wesley Groleau x4923]

> What about having pre- and postconditions in the spec file? At least 
> for preconditions this should be possible. Postconditions may depend 
> on internal and thus private class information, so there might be a 
> problem. Realize also that not everything from the Ada spec is 
> repeated ind the body: type or task declarations for instance.

I claimed before (perhaps wrongly) that adding assertions to Ada
seemed fairly trivial, but even if correct, there is one aspect
that would NOT be trivial.  Since an Eiffel-style assertion is
part of the contract, BUT it is executed when a routine is called,
how can it be put in an Ada spec in a form that is compilable AND
associated with a particular declaration?  One could make subprogram
declarations consistent with tasks, i.e., a begin..end to contain
the info the client needs.  Or something like

   pragma Require   ( <subprogram>, [Precondition  =>] <expression>);
   pragma Ensure    ( <subprogram>, [Postcondition =>] <expression>);
   pragma Invariant ( <subprogram>, [???????????   =>] <expression>);

A compiler could even use the presence of such a pragma (as with 
Inline) to affect optimization or checking in clients.  But what 
would that do to the "no semntic effect" guideline for pragmas in 
RM 2.8(11,16,etc.) ?

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Matthew Heaney]

In article <3416D889.4A6C@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923"
<wwgrol@pseserv3.fw.hac.com> wrote:


>I claimed before (perhaps wrongly) that adding assertions to Ada
>seemed fairly trivial, but even if correct, there is one aspect
>that would NOT be trivial.  Since an Eiffel-style assertion is
>part of the contract, BUT it is executed when a routine is called,
>how can it be put in an Ada spec in a form that is compilable AND
>associated with a particular declaration?

You'd probably have to change the syntax of subprogram declarations. 
Here's an example:

type Root_Stack is abstract tagged private;

function Empty (Stack : Root_Stack) return Boolean;

function Full (Stack : Root_Stack) return Boolean;

procedure Pop
  (Stack : in out Root_Stack)
precondition
   Not_Empty: not Empty (Stack);
end Pop;

function Top 
  (Stack : Root_Stack) return Stack_Item
precondition
   Not_Empty: not Empty (Stack);
end Top;

procedure Push
  (Item : in     Stack_Item;
   On     : in out Root_Stack)
precondition
   Not_Full: not Full (On);
end Push;



or consider a sequence abstraction:

type Root_Sequence is abstract tagged private;

function Length 
   (Sequence : Root_Sequence) return Natural;

procedure Remove_Item
  (Sequence : in out Root_Sequence; 
   Index        : in        Positive)
precondition
   Is_Present: Index <= Length (Sequence);
end;

You get the idea.  The subprogram precondition is a list of boolean
expressions that are functions of one or more of the subprogram arguments. 
The precondition (and postcondition too - I didn't show that) is part of
the signiture of the subprogram.

When the call happens, the actual parameters are calculated, and then the
preconditions are evaluated; a precondition violation (a boolean expression
whose value is False) would cause Constraint_Error to be raised (or
whatever), just as for actual parameters that don't satisify range
constraints of the formal parameters.

A simple example of a postcondition would be

function Length
  (Sequence : Root_Sequence) return Integer
postcondition
   Length >= 0;
end;

(though of course this example is possible using existing Ada mechanisms).

I still have to think about how to state a representation invariant.  Its
specification would somehow have to be attached to the full view of the
type, and would be evaluated at exit from a subprogram.

I also haven't thought of a convenient way to state a postcondition in
terms of a change in a value (ie the length before the call versus the
length after the call).

This is my first cut at an extended syntax for Ada 0X.  Any opinions?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Robert Dewar]

Wes said

>I claimed before (perhaps wrongly) that adding assertions to Ada
>seemed fairly trivial, but even if correct, there is one aspect
>that would NOT be trivial.  Since an Eiffel-style assertion is
>part of the contract, BUT it is executed when a routine is called,
>how can it be put in an Ada spec in a form that is compilable AND
>associated with a particular declaration?

It seems pretty easy to devise a pragma that would have the desired effect,
for example something like:

	procedure x (a : integer; b : integer);
        pragma Precondition (x, a = b + 17);

which would say that this precondition on the parameters should be
checked whenever the procedure is called.

I don't see a problem in either defining or implementing such a pragma
(this does not mean that it is zero work, or that we are about to rush
away and add this feature to GNAT, but there is no conceptual or significant
practical problem in implementing such a design.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[W. Wesley Groleau x4923]

Robert Dewar wrote:
> Wes said
> >I claimed before (perhaps wrongly) that adding assertions to Ada
> >seemed fairly trivial, but even if correct, there is one aspect
> >that would NOT be trivial.  Since an Eiffel-style assertion is
> >part of the contract, BUT it is executed when a routine is called,
> >how can it be put in an Ada spec in a form that is compilable AND
> >associated with a particular declaration?
> 
> It seems pretty easy to devise a pragma that would have the desired effect,
> for example something like:
> 
>         procedure x (a : integer; b : integer);
>         pragma Precondition (x, a = b + 17);

Which, if I remember right (that was a long time ago), was what I
suggested in the same post--only I bowed to the Eiffel jargon
and called the pragma Require.  It would be almost trivial (in spite
of my apparent comment otherwise) to implement a feature that the
above is identical in effect to putting 

         pragam Assert (a = b + 17);

at the beginning of the body.  However, as with pragma Inline,
it would have to apply to all overloadings of "X", and if it is
allowed (as above) to reference X's parameters, there could be
a significant ambiguity in (for example) the following case:

         procedure x (a : calendar.time; b : task_ID);
         procedure x (a : integer; b : integer);
         pragma Precondition (x, a = b + 17);

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Robert Dewar]

WWG said

<<at the beginning of the body.  However, as with pragma Inline,
it would have to apply to all overloadings of "X", and if it is
allowed (as above) to reference X's parameters, there could be
a significant ambiguity in (for example) the following case:

         procedure x (a : calendar.time; b : task_ID);
         procedure x (a : integer; b : integer);
         pragma Precondition (x, a = b + 17);>>


No big deal. The conventional Ada answer is to use renamings to disambiguate,
or you could follow the lead of the DEC pragmas (as implemented in Ada,
see for example Import_Procedure), and give the corresponding profile in
the pragma.

This is no a difficult issue to resolve.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Don Harrison]

Matt Heaney suggested a way of adding assertions to Ada. Part of the example..
 
:procedure Pop
:  (Stack : in out Root_Stack)
:precondition
:   Not_Empty: not Empty (Stack);
:end Pop;

[..]

:You get the idea.  The subprogram precondition is a list of boolean
:expressions that are functions of one or more of the subprogram arguments. 
:The precondition (and postcondition too - I didn't show that) is part of
:the signiture of the subprogram.

One issue to consider is whether to include preconditions and postconditions
in separate operation declarations - doing so would only worsen the 
redundancy problem but not doing so creates an inconsistency similar to Pascal
"forward" declarations. :(


:I still have to think about how to state a representation invariant.  Its
:specification would somehow have to be attached to the full view of the
:type, and would be evaluated at exit from a subprogram.

What is meant by "the full view of the type"? Do you mean including the 
operations in the package body? - this would be close to the Eiffel concept.

Unless I'm mistaken, you're faced with a dilemma in trying to implement
invariants:

1) On the one hand, you want to allow invariants to include all of the 
   type's operations declared in a package - exported and hidden, primitive 
   and class-wide - it implies declaring them in the package body somehow. 
   While such invariants could use the "full" view of the type, they 
   wouldn't be visible to public child packages. This would make it 
   impossible to extend an invariant in a descendant type in a public child.

2) OTOH, if you allow invariants to use only operations declared in the spec, 
   they are visible in public child packages but can't include operations from 
   the body - not as general as Eiffel invariants.

This seems to reveal a weakness of separate interface and implementation 
which doesn't arise in Eiffel's embedded model.

Assuming 2) was adopted, you could have (assuming Matt's declarations):

  private
    type Root_Stack is abstract tagged record
      ...
    invariant
      Full (Current) implies not Empty (Current);
      Empty (Current) implies not Full (Current);
    end record;
  end Pkg; 

(Current = Self = This - take your pick).

Sorry to have to point this out, but "Full" and "Empty" would have to be 
pre-declared - more redundancy. :(


:I also haven't thought of a convenient way to state a postcondition in
:terms of a change in a value (ie the length before the call versus the
:length after the call).

Do you mean like the following?..

procedure Remove_Item
  (Sequence : in out Root_Sequence; 
   Index    : in     Positive)
precondition
   Is_Present: Index <= Length (Sequence);
postcondition
   Shorter: Length (Sequence) < Length (Sequence'Old)
end;


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Joerg Rodemann]

Don Harrison (nospam@thanks.com.au) wrote:

>   private
>     type Root_Stack is abstract tagged record
>       ...
>     invariant
>       Full (Current) implies not Empty (Current);
>       Empty (Current) implies not Full (Current);
>     end record;
>   end Pkg; 

Well, this is a solution that seems possible to me. Of course anything the
invariant depends on has to be declared within the the spec although this
might be in the private part. This should not be a problem since it seems
quite convenient among Ada programmers to declare everything before use.
Thus invariants should be preceded by the declaration of any variable or
method used for its definition.

A short question on the side to our Eiffel friends: are the Eiffel invariants
visible to the client or are the just there to ensure object state consistency
so that it is able to recognize an error condition? I. e. I assume they may
rely on private member variables, don't they?

> :I also haven't thought of a convenient way to state a postcondition in
> :terms of a change in a value (ie the length before the call versus the
> :length after the call).

> Do you mean like the following?..

> procedure Remove_Item
>   (Sequence : in out Root_Sequence; 
>    Index    : in     Positive)
> precondition
>    Is_Present: Index <= Length (Sequence);
> postcondition
>    Shorter: Length (Sequence) < Length (Sequence'Old)
> end;

I agree that the concept to be most difficult to be introduced into Ada are
the postconditions due to the problem of value changes during execution of
a method. This example made it quite obvious to me although I mentioned this
problem already within another post earlier.

Regards

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Roger Browne]

rodemann@mathematik.uni-ulm.de (Joerg Rodemann) writes:

> A short question on the side to our Eiffel friends: are the Eiffel
> invariants visible to the client or are the just there to ensure object
> state consistency so that it is able to recognize an error condition?
> I. e. I assume they may rely on private member variables, don't they?

Yes, Eiffel invariants can refer to private attributes and functions.

The client doesn't need to examine the invariant directly, because the 
invariant must be satisfied any time the object is accessible to the client.

Eiffel invariants do often refer to their private attributes and functions.
For example, a STACK object may have an invariant clause to ensure that
"capacity >= count", where 'capacity' is the capacity of some implementation
storage (e.g. an array) and 'count' is the number of items currently on the
stack. Assuming we are not talking about a BOUNDED_STACK, 'capacity' should
be private.

Regards,
Roger
-- 
-- 
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Robert A Duff]

In article <184347314wnr@eiffel.demon.co.uk>,
Roger Browne  <roger@eiffel.demon.co.uk> wrote:
>The client doesn't need to examine the invariant directly, because the 
>invariant must be satisfied any time the object is accessible to the client.

My understanding is that the compiler generates run-time checks for
invariants at both entry to and exit from each feature.  Is that
correct?  If so, why?  How can the check-upon-entry ever fail, since the
invariant must be true initially, and must be true after every exit?

- Bob

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Joachim Durchholz]

Robert A Duff wrote:
> My understanding is that the compiler generates run-time checks for
> invariants at both entry to and exit from each feature.  Is that
> correct?  If so, why?  How can the check-upon-entry ever fail, since
> the
> invariant must be true initially, and must be true after every exit?

Let's try another answer:

The object in question may have an invariant that refers to attibutes of
another object. Nothing in the language prevents other code from
modifying these attributes while the current object isn't active, so the
class invariant may have been made invalid in the mean time.

Unfortunately, this is a problem domain issue and can't be avoided by
programming language rules. Imagine the following situation:
  I say I had to leave my employer because he went bankrupt.
  You say you just started a new project with a customer.
Nobody will note a discrepancy until he finds out that your customer is
actually my employer.
More formally, let's say
  class EMPLOYEE
  feature
    employer: COMPANY;
  invariant
    not employer.bankrupt
  end
  class COMPANY
  feature
    bankrupt: BOOLEAN;
    feature go_bankrupt is
    do
      bankrupt := true
    end
  end

(somewhere else)
  feature
    acme: COMPANY
  ...
  me.employer := acme -- let's say acme is healthy right now
  you.customer := acme
  -- not let's violate my invariant:
  you.customer.go_bankrupt -- now the invariant of 'me' is violated
  ... -- lots of code in-between
  me.employer.do_something -- now the run-time system touches 'me'
  -- for the first time after a long period; this is the first chance
  -- is gets to check my precondition and sees that it is violated,
  -- so it raises the exception on entry to do_something

I hope this alternative explanation helps somebody understand the
issue...

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Lee Webber]

On Tue, 16 Sep 1997 21:25:35 GMT, bobduff@world.std.com (Robert A
Duff) wrote:

>In article <184347314wnr@eiffel.demon.co.uk>,
>Roger Browne  <roger@eiffel.demon.co.uk> wrote:
>>The client doesn't need to examine the invariant directly, because the 
>>invariant must be satisfied any time the object is accessible to the client.
>
>My understanding is that the compiler generates run-time checks for
>invariants at both entry to and exit from each feature.  Is that
>correct?  If so, why?  How can the check-upon-entry ever fail, since the
>invariant must be true initially, and must be true after every exit?

What you say is true, I believe, if the object possesses what Bertrand
Meyer calls "referential integrity", which among other things means
that its state only changes as a result of the application of one of
its features.  (I am not famiiliar with this term in its mathematical
context, so I am treating it as if it were a newly defined concept.)  

While this is so highly desirable a property of an object that some
(including Meyer) would like to enforce it if they could, there are
circumstances in which it is inappropriate if not impossible.  The
standard case is that of an object encapsulating an external entity
(e.g., a communications port) which itself changes state arbitrarily.
In this case, you often can only maintain referential integrity by
discarding important state information (which, sadly, many
communications drivers do), or by declaring that the unanticipated
state change is nonetheless unexceptional.

Be that as it may, Eiffel doesn't enforce r.i. and therefore must
check the invariant on feature entry as well as exit.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Franck Arnaud]

Robert A Duff:

> My understanding is that the compiler generates run-time checks for
> invariants at both entry to and exit from each feature.

Correct.

>  If so, why?  How can the check-upon-entry ever fail, since the
> invariant must be true initially, and must be true after every exit?

If the invariant is other.some_condition, other's state may have changed
since last time.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Don Harrison]

Franck Arnaud wrote:

:Robert A Duff:
:
:> My understanding is that the compiler generates run-time checks for
:> invariants at both entry to and exit from each feature.
:
:Correct.
:
:>  If so, why?  How can the check-upon-entry ever fail, since the
:> invariant must be true initially, and must be true after every exit?
:
:If the invariant is other.some_condition, other's state may have changed
:since last time.

If I understand you correctly, you're saying that if our class has an 
invariant containing a condition "other.some_condition" where "other" is 
an attribute common to our class and another class, then updating the common 
object via the other class won't check the invariant in our class. Correct?

Hence, it must be re-checked before executing any operation.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Robert A Duff]

Franck Arnaud wrote:
:Robert A Duff:
:
:> My understanding is that the compiler generates run-time checks for
:> invariants at both entry to and exit from each feature.
:
:Correct.
:
:>  If so, why?  How can the check-upon-entry ever fail, since the
:> invariant must be true initially, and must be true after every exit?
:
:If the invariant is other.some_condition, other's state may have changed
:since last time.

It seems to me that such an invariant is not invariant.  I thought the
whole point of invariants was that you can count on the invariant
"always" being true (where "always" really means "always, except while
the object is in the process of being updated").  But if invariants are
allowed to referent other.some_condition, and "other" can be modified
willy-nilly by who-knows-what software, then such an invariant is not
invariant at all!

Note the conceptual difference between preconditions and invariants --
it's the responsibility of the client to make sure a precondition is
true before calling something, but it's *supposedly* the responsibility
of the class itself to maintain its own invariants.

- Bob

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Juergen Schlegelmilch]

On Thu, 18 Sep 1997 12:48:25 GMT, Robert A Duff <bobduff@world.std.com> wrote:
>Franck Arnaud wrote:
>:If the invariant is other.some_condition, other's state may have changed
>:since last time.
>
>It seems to me that such an invariant is not invariant.  I thought the
>whole point of invariants was that you can count on the invariant
>"always" being true (where "always" really means "always, except while
>the object is in the process of being updated").  But if invariants are
>allowed to referent other.some_condition, and "other" can be modified
>willy-nilly by who-knows-what software, then such an invariant is not
>invariant at all!
>
>Note the conceptual difference between preconditions and invariants --
>it's the responsibility of the client to make sure a precondition is
>true before calling something, but it's *supposedly* the responsibility
>of the class itself to maintain its own invariants.

If 'other' is not exported to any other class, and if there is no method 
that allows clients to obtain a reference to (the object bound to) 'other', 
and if 'other' is always bound to an object created locally (i.e. not to 
an object that came into scope as a routine argument, directly or via some 
intermediate object), then the only access path to that object is through 
the current object and the invariant is valid. 
There are quite a lot 'if' statements above. Other languages have a special 
type called 'unique ref' that guaranties that there is always only one object 
referencing the target. However, since all the 'if's are in the hands of the
programmer implementing the class with the invariant in question, I think we
don't need language support for this design pattern. 

So let them reference other objects in invariants; and if it breaks,
its their own fault for not obeying proper design rules :-)

Just my $0.02.

  Juergen
-- 
+-----------------------------------------------------------------------------+
 Dipl.-Inf. Juergen Schlegelmilch                 University of Rostock
 email: schlegel@Informatik.Uni-Rostock.de        Computer Science Department
 http://www.informatik.uni-rostock.de/~schlegel   Database Research Group 
 Tel: ++49 381 498 3402                           18051 Rostock 
 Fax: ++49 381 498 3426                           Germany
+-----------------------------------------------------------------------------+

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Jon S Anthony]

In article <EGpFKp.6BB@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Note the conceptual difference between preconditions and invariants --
> it's the responsibility of the client to make sure a precondition is
> true before calling something, but it's *supposedly* the responsibility
> of the class itself to maintain its own invariants.

Another very important point in connection with this is that there are
many cases where invariants are "system wide" (or even domain wide)
and cannot be the responsibility of "the class", which in fact can't
even check the invariant much less ensure whether it is true or not
(_really_ invariant).  In this case, the most that can be done at the
"component level" is to publish the "invariant" as a requirement (say
in a functional representation (FR) sense or more typically as simply
a comment) and then simply _assume_ it.

/Jon

-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Joachim Durchholz]

Robert A Duff wrote:
> It seems to me that such an invariant is not invariant.  I thought the
> whole point of invariants was that you can count on the invariant
> "always" being true (where "always" really means "always, except while
> the object is in the process of being updated").

Well, you can also count on a postcondition always to be fulfilled at
end-of-routine, still they may not and raise an exception.
The point is that you can count on Eiffel assertions to be valid
whenever they are relevant. An invariant is relevant as soon as a
routine accesses the object, not earlier.

> But if invariants
> are
> allowed to referent other.some_condition, and "other" can be modified
> willy-nilly by who-knows-what software, then such an invariant is not
> invariant at all!

Such invariant violations are programming errors. The error is at the
point that changes the object; for efficiency reasons, the detection of
this error is postponed until the object is actually used again.
It would be no big deal to allow for invariant checking whenever
appropriate. The run-time system would have to keep a record on which
object depends on which other objects for its invariant; whenever an
object changes, the appropriate invariants would be rechecked.
(I'd really like to see an Eiffel system that does this!)

If an invariant references an externally accessible object you better
make sure that these aliasing access paths aren't abused!
You can control this via two strategies:
1) Don't give away references to your private, invariant-relevant
objects.
2) If you can't stick to (1), give the references only to your friends
(i.e. classes that you write yourself, via selective export).
3) If you can't stick to (2), create a wrapper class around the
reference that you're giving away and check the routines in that wrapper
class so that they cannot violate the invariant.

So while the language doesn't prevent you from violating invariants, you
can keep the problem under control.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Joachim Durchholz]

Joerg Rodemann wrote:
> 
> A short question on the side to our Eiffel friends: are the Eiffel
> invariants
> visible to the client or are the just there to ensure object state
> consistency
> so that it is able to recognize an error condition? I. e. I assume
> they may
> rely on private member variables, don't they?

Class invariants can and do use private features. However, such class
invariants aren't listed by the short tool, i.e. in the Ada context they
should be listed in the private part of the interface (or even in the
implementation part).

In the same vein, a subroutine precondition must not use a private
feature of the class. The client calling the routine must be able to
check all preconditions, and it can't do that if it does not have access
to all properties that make up a precondition.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Owen Fellows]

Joerg Rodemann wrote:
> 
> Don Harrison (nospam@thanks.com.au) wrote:
> 
> >   private
> >     type Root_Stack is abstract tagged record
> >       ...
> >     invariant
> >       Full (Current) implies not Empty (Current);
> >       Empty (Current) implies not Full (Current);
> >     end record;
> >   end Pkg;
> 
> Well, this is a solution that seems possible to me. Of course anything the
> invariant depends on has to be declared within the the spec although this
> might be in the private part. This should not be a problem since it seems
> quite convenient among Ada programmers to declare everything before use.
> Thus invariants should be preceded by the declaration of any variable or
> method used for its definition.
> 
> A short question on the side to our Eiffel friends: are the Eiffel invariants
> visible to the client or are the just there to ensure object state consistency
> so that it is able to recognize an error condition? I. e. I assume they may
> rely on private member variables, don't they?

They may, but I don't think they should. In the same way with pre and
post conditions
you don't want to have implementation details exposed.

So for a stack 

   extend (item: T) is  
      require
         not empty
   ....


is better than
  
   extend (item: T) is  
      require
         array.count < array.capacity
   ....

If you find yourself exposing implementation in the way you mention, it
is
very likely you have missed a useful feature, in the above example,
empty: BOOLEAN


> > :I also haven't thought of a convenient way to state a postcondition in
> > :terms of a change in a value (ie the length before the call versus the
> > :length after the call).
> 
> > Do you mean like the following?..
> 
> > procedure Remove_Item
> >   (Sequence : in out Root_Sequence;
> >    Index    : in     Positive)
> > precondition
> >    Is_Present: Index <= Length (Sequence);
> > postcondition
> >    Shorter: Length (Sequence) < Length (Sequence'Old)
> > end;
> 
> I agree that the concept to be most difficult to be introduced into Ada are
> the postconditions due to the problem of value changes during execution of
> a method. This example made it quite obvious to me although I mentioned this
> problem already within another post earlier.
>

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Don Harrison]

Joerg Rodemann wrote:

:Don Harrison (nospam@thanks.com.au) wrote:
:
:>   private
:>     type Root_Stack is abstract tagged record
:>       ...
:>     invariant
:>       Full (Current) implies not Empty (Current);
:>       Empty (Current) implies not Full (Current);
:>     end record;
:>   end Pkg; 
:
:Well, this is a solution that seems possible to me. Of course anything the
:invariant depends on has to be declared within the the spec although this
:might be in the private part. This should not be a problem since it seems
:quite convenient among Ada programmers to declare everything before use.

Not a problem if you're inured to having to pre-declare things. :)

:Thus invariants should be preceded by the declaration of any variable or
:method used for its definition.

This is a classic example of the problems incurred by forced dependency
ordering. You can't define an invariant consisting of operations on a type 
without first declaring the operations. But you can't define the operations
until you've declared the type (containing the invariant)! You're forced to 
pre-declare and suffer the maintenance burden that goes with it. :(


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Paul Johnson]

In article <341eac5e.0@news.uni-ulm.de>, Joerg Rodemann
<rodemann@mathematik.uni-ulm.de> writes

>A short question on the side to our Eiffel friends: are the Eiffel invariants
>visible to the client or are the just there to ensure object state consistency
>so that it is able to recognize an error condition? I. e. I assume they may
>rely on private member variables, don't they?

Yes.  The only kind of Eiffel assertion that may not use private
variables is the precondition, because the client must be able to tell
if its about to break the contract.  No hidden clauses allowed.

Postconditions and invariants generally use public variables because
they form part of the interface specification.  But if the class author
wants to specify internal consistency constraints as part of a routine
then thats just fine.  It can even be necessary: if a descendant
redefines the routine it is still constrained by the postconditions and
invariants.

Paul.
--------------------------------+---------------------------------
Paul Johnson                    | You are lost in a maze of twisty
Email: Paul@treetop.demon.co.uk | little standards, all different.
       paul.johnson@gecm.com    |

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Matthew Heaney]

In article <EGLBMK.A5I@syd.csa.com.au>, nospam@thanks.com.au wrote:


>One issue to consider is whether to include preconditions and postconditions
>in separate operation declarations - doing so would only worsen the 
>redundancy problem but not doing so creates an inconsistency similar to Pascal
>"forward" declarations. :(
>
Yes, I would include preconditions and postconditions in separate operation
declarations.  But I'm not sure what you mean by a "redundancy problem."

o If you mean the overloaded subprograms each have to list potentially
identical pre and post-conditions, then I don't have any problem with that.

o If you mean list pre and postconditions again in the package body, I
would say you don't need to bother (but there may be issues about that that
I haven't considered).

>:I still have to think about how to state a representation invariant.  Its
>:specification would somehow have to be attached to the full view of the
>:type, and would be evaluated at exit from a subprogram.
>
>What is meant by "the full view of the type"? Do you mean including the 
>operations in the package body? - this would be close to the Eiffel concept.

The full view of a type is the type declaration that appears after the word
"private" in the spec, ie:

generic
   type Stack_Item;
   Max_Depth : Positive;
package Stacks_G is

   -- This is the "partial" view:
   type Bounded_Stack is tagged private;
...
private

   type Stack_Item_Array is 
      array (Positive range 1 .. Max_Depth) of Stack_Item;

   -- This is the "full" view:
   type Bounded_Stack is 
      tagged record
          Items : Stack_Item_Array;
          Depth : Natural := 0;
       end record;

end;

>Unless I'm mistaken, you're faced with a dilemma in trying to implement
>invariants:
>
>1) On the one hand, you want to allow invariants to include all of the 
>   type's operations declared in a package - exported and hidden, primitive 
>   and class-wide - it implies declaring them in the package body somehow. 
>   While such invariants could use the "full" view of the type, they 
>   wouldn't be visible to public child packages. This would make it 
>   impossible to extend an invariant in a descendant type in a public child.

Actually, I hadn't considered using operations in the invariant.  What I
had in mind is a relationship among the variables that are the
representation of an object.  As these variables are part of the
implementation, my thinking was that no public operations would apply.

For example, I have a queue implemented as a linked list, with a pointer to
the front of the list, and a pointer to the back.  I would like to state as
a representation invariant that the previous pointer of the front node is
null, and the next pointer of the back node is also null:

generic
   type Queue_Item is private;
package Queues_G is

   type Unbounded_Queue is tagged private;
...
private

   package Queue_Item_Lists is 
      new Lists_G (Queue_Item);
    use Queue_Item_Lists;

   type Unbounded_Queue is
      tagged record
         Front, Back : Unbounded_List;
         Length : Natural := 0;
      invariant
         Front_OK : Length /= 0 implies Front.Previous = null;
         Back_OK : Length /= 0 implies Back.Next = null;
         Length = 0 implies Front = null and Back = null;
         Length = 1 implies Front = Back;
         Length > 1 implies Front /= Back;
      end record;

        
So I'm not clear that operations are even needed to implement an invariant,
if one accepts the model that invariants are simply boolean expressions
comprising only record components.


>:I also haven't thought of a convenient way to state a postcondition in
>:terms of a change in a value (ie the length before the call versus the
>:length after the call).
>
>Do you mean like the following?..
>
>procedure Remove_Item
>  (Sequence : in out Root_Sequence; 
>   Index    : in     Positive)
>precondition
>   Is_Present: Index <= Length (Sequence);
>postcondition
>   Shorter: Length (Sequence) < Length (Sequence'Old)
>end;

I like this idea.


>Don.                     (Reverse to reply)
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Don Harrison             au.com.csa.syd@donh

Can you fix this so I don't have to do some much damn editing reply to you? 
How about

   donh*syd.csa.com.au
   syd.csa.com.au@donh

Thank you!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Don Harrison]

Matt Heaney wrote:

:In article <EGLBMK.A5I@syd.csa.com.au>, nospam@thanks.com.au wrote:
:
:
:>One issue to consider is whether to include preconditions and postconditions
:>in separate operation declarations - doing so would only worsen the 
:>redundancy problem but not doing so creates an inconsistency similar to Pascal
:>"forward" declarations. :(
:>
:Yes, I would include preconditions and postconditions in separate operation
:declarations.  But I'm not sure what you mean by a "redundancy problem."

I mean having to duplicate the information in the operation declaration and 
its body just as you have to do for its signature.

:o If you mean the overloaded subprograms each have to list potentially
:identical pre and post-conditions, then I don't have any problem with that.

Same here.

:o If you mean list pre and postconditions again in the package body, I
:would say you don't need to bother (but there may be issues about that that
:I haven't considered).

I would say you *do* need to if you have to duplicate the signature (as you do).

:>:I still have to think about how to state a representation invariant.  Its
:>:specification would somehow have to be attached to the full view of the
:>:type, and would be evaluated at exit from a subprogram.
:>
:>What is meant by "the full view of the type"? Do you mean including the 
:>operations in the package body? - this would be close to the Eiffel concept.
:
:The full view of a type is the type declaration that appears after the word
:"private" in the spec, ie:
:
:generic
:   type Stack_Item;
:   Max_Depth : Positive;
:package Stacks_G is
:
:   -- This is the "partial" view:
:   type Bounded_Stack is tagged private;
:....
:private
:
:   type Stack_Item_Array is 
:      array (Positive range 1 .. Max_Depth) of Stack_Item;
:
:   -- This is the "full" view:
:   type Bounded_Stack is 
:      tagged record
:          Items : Stack_Item_Array;
:          Depth : Natural := 0;
:       end record;
:
:end;

Okay, so you mean visibility to the attributes of the type.

Yes, it's true that access to just the attributes of a type is sufficient 
to declare an invariant. However, more flexible is the ability to also use
functions which encapsulate an aspect of that state. Such functions are 
generally declared in the same modules that directly *update* an object of 
that type. In Ada, that means, potentially, a collection of modules, 
specifically:

1) For tagged private types, the body or a child package body.
2) Additionally, for tagged (non-private) type, any client package body!

Hence, there is no single module responsible for updating the object. Further, 
there is no single module that has access both to the attributes of an object 
*plus* all the functions used to describe its state. Consequently, it's 
impossible to add an invariant mechanism to Ada which allows you to describe 
the state of an object using all the resources you may want to use. 

This problem doesn't arise in Eiffel because there is only one such module - 
the class that defines the type - which can update the object directly and 
hence contains the functions which describe its state. So, an Eiffel class 
invariant can include everything you may want to use.

:>Unless I'm mistaken, you're faced with a dilemma in trying to implement
:>invariants:
:>
:>1) On the one hand, you want to allow invariants to include all of the 
:>   type's operations declared in a package - exported and hidden, primitive 
:>   and class-wide - it implies declaring them in the package body somehow. 
:>   While such invariants could use the "full" view of the type, they 
:>   wouldn't be visible to public child packages. This would make it 
:>   impossible to extend an invariant in a descendant type in a public child.
:
:Actually, I hadn't considered using operations in the invariant.  What I
:had in mind is a relationship among the variables that are the
:representation of an object.  As these variables are part of the
:implementation, my thinking was that no public operations would apply.

I agree you could restrict invariants to use only *attributes* of a type
but this denies you the choice of also using abstraction to describe state,
so forcing you to duplicate code.


:For example, I have a queue implemented as a linked list, with a pointer to
:the front of the list, and a pointer to the back.  I would like to state as
:a representation invariant that the previous pointer of the front node is
:null, and the next pointer of the back node is also null:

[Matt's example]

:So I'm not clear that operations are even needed to implement an invariant,
:if one accepts the model that invariants are simply boolean expressions
:comprising only record components.

Yes, it's true they aren't necessary, though they are *helpful*. For example, 
if the condition defined by your invariant was useful elsewhere, you could
encapsulate it in a function and reuse it:

  function Internally_Consistent (Queue: Unbounded_Queue) return Boolean is
  begin
    ...     -- return a boolean reflecting Matt's invariant
  end;

  ...

  type Unbounded_Queue is
     tagged record
     ...
  invariant
    Internally_Consistent (Current);
  end record;

Somewhere:

  if Internally_Consistent (Q) then ..


:>postcondition
:>   Shorter: Length (Sequence) < Length (Sequence'Old)
:>end;
:
:I like this idea.

Thanks.


:>Don.                     (Reverse to reply)
:>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
:>Don Harrison             au.com.csa.syd@donh
:
:Can you fix this so I don't have to do some much damn editing reply to you? 

Grrrr! Now you know how I feel about the unneccessary editing inflicted on me
by maintaining redundant code in Ada! :)
 

:Thank you!

No problem! :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison          donh at syd.csa.com.au
                      ^^^^^^^^^^^^^^^^^^^^^^
Hopefully, this is an improvement and foils some spammers.

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Matthew Heaney]

In article <EH1q1p.K05@syd.csa.com.au>, Don Harrison wrote:


>:So I'm not clear that operations are even needed to implement an invariant,
>:if one accepts the model that invariants are simply boolean expressions
>:comprising only record components.
>
>Yes, it's true they aren't necessary, though they are *helpful*. For example, 
>if the condition defined by your invariant was useful elsewhere, you could
>encapsulate it in a function and reuse it:
>
>  function Internally_Consistent (Queue: Unbounded_Queue) return Boolean is
>  begin
>    ...     -- return a boolean reflecting Matt's invariant
>  end;

Once again, you're one step ahead of me.  I had exactly this idea after I
had made my post.


>  type Unbounded_Queue is
>     tagged record
>     ...
>  invariant
>    Internally_Consistent (Current);
>  end record;
>
>Somewhere:
>
>  if Internally_Consistent (Q) then ..

You could run with this idea and use something similar to controlled types,
or you could use an attribute idea.  Every type could be born with an
invariant function that is called just before executing the body of an
operation, and called just after executing the body.

private

function Internally_Consistent (Q : Unbounded_Queue) return Boolean;
  -- this would be analogous to overriding Initialize for a Controlled type

type Unbounded_Queue is new Root_Queue with
   record
      ...
   end record;

for Unbounded_Queue'Invariant use Internally_Consistent;
  -- an alternate technique that uses an attribute, not unlike stream I/O
subprograms

end;

Though I haven't quite figured out what happens when you derive from
Unbounded_Queue.  Can you override your parent's invariant?  Under what
circumstances would that make sense?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[Don Harrison]

Matt Heaney wrote:

:In article <EH1q1p.K05@syd.csa.com.au>, Don Harrison wrote:
:
:>  type Unbounded_Queue is
:>     tagged record
:>     ...
:>  invariant
:>    Internally_Consistent (Current);
:>  end record;
:>
:>Somewhere:
:>
:>  if Internally_Consistent (Q) then ..
:
:You could run with this idea and use something similar to controlled types,
:or you could use an attribute idea.  Every type could be born with an
:invariant function that is called just before executing the body of an
:operation, and called just after executing the body.

Interesting ideas. I'll need to remind myself of what controlled types are
to fully appreciate the possibilities.

:private
:
:function Internally_Consistent (Q : Unbounded_Queue) return Boolean;
:  -- this would be analogous to overriding Initialize for a Controlled type

Perhaps, you would want to explicitly associate this with Initialise.

:type Unbounded_Queue is new Root_Queue with
:   record
:      ...
:   end record;
:
:for Unbounded_Queue'Invariant use Internally_Consistent;
:  -- an alternate technique that uses an attribute, not unlike stream I/O
:subprograms
:
:end;
:
:Though I haven't quite figured out what happens when you derive from
:Unbounded_Queue.  

I agree, that's an issue.

:Can you override your parent's invariant?  

In Eiffel, you can by encapsulating it in a function, and, in the descendant,
overriding the function and omitting the invariant declaration. 

In the parent:

  some_boolean_function: BOOLEAN is ..
  ...
  invariant
    some_boolean_function
  end

In the descendant:

  redefine some_boolean_function
  ...
  some_boolean_function: BOOLEAN is ..      -- overridden
  ...
  end

The overriding should always *strengthen* the condition. It is naughty to 
weaken it.

In the case of a descendant that *does* contain an invariant, the condition
is and-ed with the parent's.

:Under what circumstances would that make sense?

When the descendant is a more restrictive variant of the parent.


P.S. I'm on leave for two weeks, so won't be able to respond till then.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison          donh at syd.csa.com.au

Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?)

[John G. Volan]

Don Harrison wrote:
> 
> Matt Heaney wrote:
> 
> :o If you mean list pre and postconditions again in the package body, I
> :would say you don't need to bother (but there may be issues about that that
> :I haven't considered).
> 
> I would say you *do* need to if you have to duplicate the signature (as you do).

I don't see why.  Pre- and post-conditions may be part of the
"interface" of a method, but I don't see them as part of its
"signature", so I don't think they'd need to be repeated in the method
body.

I define the "signature" of a method to be that portion of its
"interface" which is necessary to uniquely identify that method, and
distinguish it from all other methods.  In languages that don't allow
subprogram overloading, such as Smalltalk (and Pascal?), the name of the
method by itself is sufficient to identify it. But in a language that
does allow overloading, such as Ada95 or C++, the name alone is not
enough; you also need the parameter/result type profile.  Hence the need
to duplicate this profile in both the spec and the body of a subprogram;
that way, the compiler can correctly associate a given body with its
corresponding spec.

Although pre- and post-conditions are important aspects of the interface
of a method, and help to define its "contract", neverthelss they do not
serve to distinguish or identify the method in any way. In other words,
you don't have method "overloadings" that differ only in their
assertions (at least not in Eiffel).  So, in a hypothetical
Ada-with-assertions, I don't see any reason why you'd have to repeat the
assertions in the body of a subprogram.

(Hmm... suppose preconditions _could_ be used to distinguish different
method overloadings that otherwise have identical signatures.  This
suggests some interesting ideas for a kind of pattern-matching language,
where the particular overloading would be dynamically selected based
upon which precondition was true at run-time.)  

-- 
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

Re: Separation of IF and Imp: process issue?

[Joerg Rodemann]

W. Wesley Groleau x4923 (wwgrol@pseserv3.fw.hac.com) wrote:

> > What about having pre- and postconditions in the spec file? At least 
> > for preconditions this should be possible. Postconditions may depend 
> > on internal and thus private class information, so there might be a 
> > problem. Realize also that not everything from the Ada spec is 
> > repeated ind the body: type or task declarations for instance.

> I claimed before (perhaps wrongly) that adding assertions to Ada
> seemed fairly trivial, but even if correct, there is one aspect
> that would NOT be trivial.  Since an Eiffel-style assertion is
> part of the contract, BUT it is executed when a routine is called,
> how can it be put in an Ada spec in a form that is compilable AND
> associated with a particular declaration?  One could make subprogram

Agreed. This argument is quite reasonable to me. Indeed I did not have
assertions in Ada specs in mind but just thought about how it would be
possible to have Eiffel assertions if Eiffel had splitted spec and imple-
mentation files. Someone pointed out that assertions in Eiffel might be
quite complex so it might be difficult to keep them consistent if duplicated.

Sure, this was more of an academic question since nobody is going to drop
the actual Eiffel way right now as I occurs to me from the discussion.
At least, I try to keep to the Ada way although I am using C++. And we're
using ClearCase here, of course. :-)

Yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Separation of IF and Imp: process issue?

[Nick Leaton]

Joerg Rodemann wrote:
> 
> Darren New (dnew@zloty.fv.com) wrote:
> 
> > On the other hand, Eiffel specs are (I think) more expressive and
> > complete than Ada specs, including preconditions, postconditions,
> > invariants, and so on, and these things get inherited in sufficiently
> > complex ways that just looking at the spec on paper is unlikely to be
> > particularly informative anyway. Hence, typing all the assertions etc in
> > two separate files is going to be a nightmare.
> 
> What about having pre- and postconditions in the spec file? At least for
> predconditions this should be possible. Postconditions may depend on internal
> and thus private class information, so there might be a problem. Realize also
> that not everything from the Ada spec is repeated ind the body: type or task
> declarations for instance.

Reliance on the internal information in both pre and post conditions is
not a good idea.

For example, consider a stack implemented using an array.

extend (push) could have a precondition.
	
	data.count < data.capacity

This is not a good idea. It is much better to implement the assertions
using features available in the spec. In this case

	require
		not empty

Where empty is a boolean feature implemented as above. Advantages, its
more abstract and you can change the implementation without having to
change the pre
or post conditions. Using implementation details in pre/post condition
is an indication that your class is missing features.


...

> I'd like to agree that --- if you fiddle around with large logical expressions
> or something it may take some time until  it's correct in both places. Again
> I wonder if it would be easy to have those pre- and postconditions in a
> spec file. Or are they often too dependent on class internals? If so how
> can they describe a contract between a client who certainly should not know
> anything about the private parts of the class? Well, just an idea...

See above

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Separation of IF and Imp: process issue?

[W. Wesley Groleau x4923]

> Reliance on the internal information in both pre and post conditions 
> .... is not a good idea. It is much better to implement the assertions
> using features available in the spec. [good example snipped] 
> more abstract and you can change the implementation without having to
> change the pre
> or post conditions. Using implementation details in pre/post condition
> is an indication that your class is missing features.

I guess Ada gets a point this time.  If the implementation is compiled
separately and later than the spec, it's not possible to refer to most
implementation details in the spec.  (Except of course when someone
who doesn't understand information hiding uses the spec to declare
those details.)
-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Darren said

<<> Note that the Eiffel spec, while intermingled with the implementation,
> is clearly separated.  It's unlikely that an Eiffel programmer will
> change the spec and not realize it, any more than it's likely a C
> programmer will accidentally change the return type of a function and
> not realize it.
>>

Once again, the issue is not about accidental changes, the issue is one
of configuration control. If your analogy with C is really appropriate,
then it would indicate that your view of things is very different from
the Ada view.

I do not expect a C programmer to accidentally change the return type of
a function. However, I also do not expect a C programmer to realize that
there is a huge difference between changing the return type of a funct9ion,
and changing something in the body. 

If there is a bug in a program, then I would expect a typical C programmer
to make one or the other kind of modification as needed, without being
aware of the critical difference.

If you are really right that an Eiffel programmer makes no more distinction
between spec and body than typical C programmers, then that's a very
negative assessment. However, I would suspect it is probably *too*
pessimistic.

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Darren says

<<I understand the rationale. I just disagree with it. :-)

My point was that since changing the spec means you have to go talk to
everyone concerned anyway, I don't see the advantage of putting it in
a separate file.>>

That's a very informal view of things, corresponding to a few people working
together without any kind of formal CM. In such an environment, word of
mouth can substitute for many things.

But in a managed environment, such as might correspond to a shop operating
at CMM level 3 at least, things need to be much more formal, and in particular
a CM system and procedures are at the heart of the methodology.

A fundamental point is that changes to specs must be handled far
differently from changes to bodies. I doubt you would see anyone trying
to register an ISO9000 procedure that said "talk to everyone if you
change a spec"!

Instead, there must be a very clear notion of who can change a spec, under
what conditions, and following what procedures, and these rules must be
embodied into the CM system, and will be quite different for specs and
bodies.

Yes, one can always imagine a CM system that is highly knowledgable about
the particular language you are using, and does all kinds of amazing things,
but in my experience, such speculations tend to be more in the category of
wishful thinking than in real use.

By separating the spec into a a file of its own, a CM system that is file
based can provide many of the required procedures WITHOUT particularly 
being language knowledgeable. For example, even if you are using a very
simple minded revision control system such as RCS as the center piece of
your CM system, you can set access control lists differently for specs
and bodies. Yes, yes, I know that many would not even consider RCS to
qualify as a CM system, but the point is that even with a very simple
minded tool you can get most of the effect you want. If you use a more
sophisticated tool, such as Continuus, Clearcase, or CVS, then you will
find there is still a basic model that the file is the unit of control,
and the separation of specs and bodies into separate files makes it far
easier to integrate Ada effectively into such tools.

It is remarkable to me that *no one* has responded to my request for actual
experiences in using Eiffel in such CM systems. If I asked the same questin
of the Ada community, I would find scads of replies (I know many of our
customers who are using these tools, and we ourselves at ACT depend on the
file orientation for our control internally).

Darrien says he disagrees with the rationale, but is this based on
experience? Darrien, have you worked with large Ada systems organized
in this manner? My experience is that virtually all of those who have
find this to be one of the really important advantages of Ada.

I often find that people who have never used a language feature don't
understand its utility. I would not look to a C programmer to understand
the importance of fixed-point built into a language, I would not look to
a Fortran programmer to understand the importance of type abstraction or
recursion, I would not look to an Ada programmer using a non-GC versoin
of Adda to understand the importance of GC, etc.

If you are using a tool which you find entirely satisfactory for your
purposes, it is natural to assume that any features it lacks cannot be
important (sometimes this attitude approaches fanaticism, especially in
the operating system area).

If you are an Eiffel programmer, and you see no possible advantages in
Ada, it can only be because you are insuffiently aware of Ada.

But on the other hand, if you are an Ada programmer, and you see no
possible advantages in Eiffel, it can only be because you are insuffiently
aware of Eiffel.

Actually this statement pretty much applies to any pair of languages, foir
example

If you are an Ada or Eiffel programmer and you see no possible advantages
in COBOL, it can only be because you are insuffiently aware of COBOL.

The last is more shocking to some, because so many people in the PL field
assume COBOL is junk without knowing anything about it, and without knowing
its important advantages!

Re: Separation of IF and Imp: process issue?

[Darren New]

In article <dewar.873897013@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>My point was that since changing the spec means you have to go talk to
>everyone concerned anyway, I don't see the advantage of putting it in
>a separate file.>>
>
>That's a very informal view of things, corresponding to a few people working
>together without any kind of formal CM. In such an environment, word of
>mouth can substitute for many things.

"Talk to" was not meant to be interpreted literally.

>Instead, there must be a very clear notion of who can change a spec, under
>what conditions, and following what procedures, and these rules must be
>embodied into the CM system, and will be quite different for specs and
>bodies.

Agreed.

>Yes, one can always imagine a CM system that is highly knowledgable about
>the particular language you are using, and does all kinds of amazing things,
>but in my experience, such speculations tend to be more in the category of
>wishful thinking than in real use.

Perhaps it's because people using Eiffel don't want to give away their
secrets?  Anyway, as I've pointed out, it *is* fairly trivial to make
CVS do this. It's not worth my time to do it just to convince you it's
possible. :-)  No offense intended.

>By separating the spec into a a file of its own, a CM system that is file
>based can provide many of the required procedures WITHOUT particularly 
>being language knowledgeable.

And a file system based on punched cards cannot. That doesn't tell you
much about the language.

>It is remarkable to me that *no one* has responded to my request for actual
>experiences in using Eiffel in such CM systems. 

Well, ISE obviously uses RCS for their revision control. I would think ISE
would want to know when they're accidentally changing the specs of the
kernel library.

>Darrien says he disagrees with the rationale, but is this based on
>experience? Darrien, have you worked with large Ada systems organized
>in this manner? My experience is that virtually all of those who have
>find this to be one of the really important advantages of Ada.

No, I haven't. I've been on several fairly large projects, but
probably none you would consider large. In every case where we were using
a language that separated specs and bodies, the rule was that the spec
was automatically generated from the body.

>I often find that people who have never used a language feature don't
>understand its utility.

I understand the utility. Perhaps if I was trying to organize a
1000-person development effort with unenhanced CVS, I'd think the
benefits outweigh the problems. However, that hasn't been my experience.

*That* is what I meant by "I understand the rationale but disagree".


Nuff said. I see little I can add to this thread.

 --Darren

Re: Separation of IF and Imp: process issue?

[Walter Mallory]

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

<snip>

>I often find that people who have never used a language feature don't
>understand its utility. I would not look to a C programmer to understand
>the importance of fixed-point built into a language, 

Actually, if that C programmer has done significant amounts of 
programming in C using fixed point math he or she might very well 
appreciate how nice it would be to let the compiler handle some of the 
details for a change.  Probably not enough of a feature to switch 
languages for but still enough to look longingly at that particular 
feature... :-)

<snip>

--
Walter Mallory   walter.mallory@gecm.com
All opinions expressed are my own and not my employer's.
--

Re: Separation of IF and Imp: process issue?

[Samuel Mize]

Robert Dewar wrote:
> 
> <<(Hmmm... Nothing would actually tell the clients that they're invalid
> any more, automatically.  I suppose the same is true of Ada, tho.  Do
your
> Ada tools warn you to go fix all your code that references packages
> whose interface has changed since you last editted them? If so, why would
> you think the same couldn't be done for Eiffel?)>>
> 
> The Ada requirement is MUCH stronger. This is not a matter of warnings,
> this a matter of legality. A compiler that allowed you to assemble a
> program with obsolete components (changing a spec on which you depends
> definitely makes you obsolete) would be invalid, and the validation
> test suite contains many tests for such things.

I believe he's saying that most implementations of Ada don't
warn you which other library units your change has just
obsoleted.  You have to go compile or otherwise check each
module and see what's become obsolete.  This works with Eiffel
too, according to the Eiffel users.

In fact, some Ada toolsets DO provide this capability.  The
Rational environment maintains library units in different
states from "text" through "object code has been generated."
I believe it has a capability to tell you what other library
units depend on a given unit, so you can tell who you're
going to screw up if you edit something.

Certainly a simple "grep" for "with XXX" can tell you the first
wave of dependencies if you edit XXX (that is, it won't give you
the transitive dependencies, only the direct ones).

If there isn't a similar tool in GNAT, it could easily be built
based on the cross-referencer.

I suppose one could be built for Eiffel, too.

Sam Mize

Re: Separation of IF and Imp: process issue?

[W. Wesley Groleau x4923]

> I believe he's saying that most implementations of Ada don't
> warn you which other library units your change has just
> obsoleted.  You have to go compile or otherwise check each
> module and see what's become obsolete.  This works with Eiffel
> too, according to the Eiffel users.

Most _compilers_ don't tell you what has been made obsolete.
But every Ada compiler I ever used was _accompanied_ by a tool 
that would tell you the potential impact of a change.

DEC Ada/ACS, Verdix, Alsys, GNAT, Apex, ... well, can't remember 
whether Janus had such a tool.)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Separation of IF and Imp: process issue?

[Scott Ingram]

W. Wesley Groleau x4923 wrote:
<snip>
> 
> DEC Ada/ACS, Verdix, Alsys, GNAT, Apex, ... well, can't remember
> whether Janus had such a tool.)
> 

Janus/Ada used a compilation order tool called "corder".
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Scott said

<<Janus/Ada used a compilation order tool called "corder">>

I am not sure this is relevant, the issue was identifying obsoleted
units, not figuring out compilation order ...

Re: Separation of IF and Imp: process issue?

[Scott Ingram]

Robert Dewar wrote:
> 
> Scott said
> 
> <<Janus/Ada used a compilation order tool called "corder">>
> 
> I am not sure this is relevant, the issue was identifying obsoleted
> units, not figuring out compilation order ...

You are correct to point out that I didn't make the relevance
obvious.  It has been a long time since I used the early
DOS versions of JANUS/Ada, but CORDER.EXE also identified dependencies
and verified that units were up to date with its own time stamp
mechanism.  One of its options was to then print out the names of
the obsolescent units.  Looking back, it was a nice tool to have with
a very low end of the market (pricewise) compiler.
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Separation of IF and Imp: process issue?

[Robert Dewar]

Sam Mize says

<<I believe he's saying that most implementations of Ada don't
warn you which other library units your change has just
obsoleted.  You have to go compile or otherwise check each
module and see what's become obsolete.  This works with Eiffel
too, according to the Eiffel users.

In fact, some Ada toolsets DO provide this capability.  The
Rational environment maintains library units in different
states from "text" through "object code has been generated."
I believe it has a capability to tell you what other library
units depend on a given unit, so you can tell who you're
going to screw up if you edit something.>>


YOu certainly don't need anything fancy if that is all you want. With
GNAT, the gnatls utility will provide this information (it is quite trivial
to get, you just check alis of other files to see if any of them have a 
dependency reference to the file you just edited.

Certainly DEC Ada has tools that achieve this goal (which is after all
very easy to do!)

Re: Separation of IF and Imp: process issue?

[Matt Kennel (Remove 'NOSPAM' to reply)]

On Thu, 04 Sep 1997 23:13:23 -0800, Matthew Heaney <mheaney@ni.net> wrote:
:In article <EFxww3.2Fp@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
:Doyle) wrote:
:
:>>But this is not quite the same thing as the relationship between a module
:>>specification and its body.  
:>
:>  Ok, I'll boil my position down into one question: What does a separate
:>interface file do for a class that an abstract superclass can't do?
:
:True, an abstract superclass would specify the characteristics common to
:every subclass in that derivation tree, but an interface file ("package
:spec") describes the characteristics of a specific class.  For example,
:given an abstract queue superclass:

: < long example> 

:But now it's not so obvious how to separate the changes made to the bodies
:of the operations from the contract itself.  Just think how much simpler it
:is using existing configuration management technology to freeze a
:specification, if it's a different text file from the text file containing
:the body. 

I know.  And the abstract class may also be in a separate file.  In the
case that you described, there would be TWO abstract classes in Eiffel. 

One would write a QUEUE abstract class, a BALKING_QUEUE abstract class (the
'spec' of the concrete), and a concrete
BALKING_QUEUE_IMPLEMENTED_WITH_ARRAYS_BY_MBK class.  It may happen to be the
only subtype of BALKING_QUEUE.  

But so what?  What is the problem? 

:By putting spec and body together, the configuration management
:tool has to be smart enough to determine which part is the specification of
:the routines and which is the body - much more sophistication than a CM
:tool that need only treat everything as mere text.
:
:The change affects only the Balking_Queue subclass - not the abstract
:superclass.  That's why I'm not clear how freezing the spec of the root
:type really solves anything. Yes, clients who manipulate classwide queue
:objects, ie
:
:procedure Op (Queue : in out Root_Queue'Class) is ...
:
:would have a guarantee about the characteristics available for objects of
:type Root_Queue'Class, if the abstract superclass were frozen, but I'm
:talking about a client who depends on behavior specific to a balking queue:
:
:   The_Queue : Balking_Queue;
:   ...
:   Remove_Item (From => The_Queue, At_The_Position => N);
:
:
:It just seems simpler to have a different text file for the spec.  That way
:changes to the body can be made with impunity, and the compiler will check
:that you haven't changed the contract in any way (because the contract is
:kept separate).

I am not disagreeing one bit about that.   

I'm saying that it sure seems like an Eiffel/Sather abstract class can do
exactly that with the same clean mechanism used for subtype conformance
since the ideas are almost the same.

:There are probably some Eiffel subtleties that I've missed, but I hope I've
:been able to explicate the Ada philosophy with respect to separation of
:spec and body.

In other words, Eiffel can separate the spec from the body too: such a
point is fundamental in OOSC. 

Ada and Eiffel have the same underlying virtuous motives, but my personal
opinion is that the Eiffel solution is cleaner and less bureaucratic.

I'm wondering if there is some major issue that Ada addresses in this
regard that Eiffel does not.   It may be the case, but having spec and
body in separate files is not a distinction between the languages. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EFxww3.2Fp@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

>   Ok, I'll boil my position down into one question: What does a separate
> interface file do for a class that an abstract superclass can't do?

First, it is really a separate interface (not necessarily a 1-1 with
file).  Second, you seem caught in the thought mode that everything is
modeled via inheritance related classification.  A widespread though
unjustified belief.  An interface need not be involved in any
inheritance hierarchy.  If you use abstract base classes as the means
to interfaces, then you are basically publishing a "contract" that
things derived from them will have the characteristics (methods and
whatnot) described in the base abstraction.  If not, why even have it?

Different interfaces, OTOH, allows one to view a thing from completely
separate perspectives which may not be related in any way except
through an underlying implementation.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Samuel Mize]

Jon S Anthony wrote:
> 
> In article <EFxww3.2Fp@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
> 
> >   Ok, I'll boil my position down into one question: What does
a separate
> > interface file do for a class that an abstract superclass can't do?

The structure of the question shows an assumption.  Not all Ada
packages are classes -- nor should they be.  (I am assuming that
an Eiffel "class" is an object-oriented construct exporting a
data type that implements objects of that class.)

In Ada we're often working with different paradigms.  The classic
example is a utility package exporting a bunch of math routines.
This isn't a "class" unless you extend the concept of "class"
until it loses all object-oriented significance, and becomes in
essence an Ada package instead.  (In languages without a
packaging construct, this often happens.)

Where a class structure is appropriate, you may well be right.

However, it appears (from postings by another Eiffel user) that
you are extending the meaning of the superclass concept, in
essence creating a special-purpose idiom.  Nothing wrong with
that, they exist in every language.  Ada directly supports this
idiom because system partitioning and decomposition are
extremely important in its intended domain.

I would also point out, by the way, that it would be trivial to
create a perl script (probably just an awk script) to generate
an Ada spec from an Ada body in much the same way that Eiffel's
short-form tool works.  Subprogram declarations would be duplicated,
constants and variables would be migrated to the
spec and commented out of the body.  Comments prior to each
declaration would be copied, comments inside the subprograms
would not.  Comment flags would be used to mark things as being
local-usage only (not to be copied to the spec).

Nobody has done it, and nobody in the Ada community probably
cares to do it, because we use the spec as an important design
and communication tool.  This is NOT to deride its importance
or usefulness to the Eiffel community; it is only to say that
we work in different paradigms, and in different ways, and for
US the separate spec is very helpful.

Sam Mize

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <34106A26.4DC3@link.com>, Samuel Mize  <smize@link.com> wrote:
>
>Jon S Anthony wrote:
>> 
>> In article <EFxww3.2Fp@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>> 
>> >   Ok, I'll boil my position down into one question: What does
>a separate
>> > interface file do for a class that an abstract superclass can't do?
>
>The structure of the question shows an assumption.  Not all Ada
>packages are classes -- nor should they be.  (I am assuming that
>an Eiffel "class" is an object-oriented construct exporting a
>data type that implements objects of that class.)
>
>In Ada we're often working with different paradigms.  The classic
>example is a utility package exporting a bunch of math routines.
>This isn't a "class" unless you extend the concept of "class"
>until it loses all object-oriented significance, and becomes in
>essence an Ada package instead.  (In languages without a
>packaging construct, this often happens.)

This "math" example is a prime example of an approach called
"mixin" classes, whereby a set of functions is collected into
a class, and clients which want to use these functions inherit
from this class.  It's a fairly common object-oriented pattern
in environments supporting multiple inheritance.

For example the math functions could go into a class called
MATH_USER, so classes which inherit from this can use math
features because instances of the subclass are now also
instances of MATH_USER.

In other words, this "utility package" concept seems to have
lots of "object-oriented significance" to me.

>However, it appears (from postings by another Eiffel user) that
>you are extending the meaning of the superclass concept, in
>essence creating a special-purpose idiom.  Nothing wrong with
>that, they exist in every language.  Ada directly supports this
>idiom because system partitioning and decomposition are
>extremely important in its intended domain.

To tell the truth, I'm starting to think this is a Good Thing.
(Believe it or not, I started off thinking it was good, but
came into this debate playing devil's advocate.)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Matt Kennel (Remove 'NOSPAM' to reply)]

On 05 Sep 1997 16:38:30 GMT, Jon S Anthony <jsa@alexandria.organon.com> wrote:
:First, it is really a separate interface (not necessarily a 1-1 with
:file).  Second, you seem caught in the thought mode that everything is
:modeled via inheritance related classification.  A widespread though
:unjustified belief.  An interface need not be involved in any
:inheritance hierarchy.  If you use abstract base classes as the means
:to interfaces, then you are basically publishing a "contract" that
:things derived from them will have the characteristics (methods and
:whatnot) described in the base abstraction. 

Yes.  How does that differ in any important way from the relation between a
package interface and its body?



-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <slrn6119ad.mp.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:

> On 05 Sep 1997 16:38:30 GMT, Jon S Anthony <jsa@alexandria.organon.com> wrote:
> :First, it is really a separate interface (not necessarily a 1-1 with
> :file).  Second, you seem caught in the thought mode that everything is
> :modeled via inheritance related classification.  A widespread though
> :unjustified belief.  An interface need not be involved in any
> :inheritance hierarchy.  If you use abstract base classes as the means
> :to interfaces, then you are basically publishing a "contract" that
> :things derived from them will have the characteristics (methods and
> :whatnot) described in the base abstraction. 
> 
> Yes.  How does that differ in any important way from the relation between a
> package interface and its body?

The body isn't a client.  The body isn't a derivation.  Seems
completely different.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Sep5123830@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EFxww3.2Fp@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>>   Ok, I'll boil my position down into one question: What does a separate
>> interface file do for a class that an abstract superclass can't do?
>
>First, it is really a separate interface (not necessarily a 1-1 with
>file).  

An abstract superclass can do this.

>Second, you seem caught in the thought mode that everything is
>modeled via inheritance related classification.  A widespread though
>unjustified belief.  

Spare me the psychoanalysis.  I'm not interested in what mode of
thought I'm caught in, and I don't think others are either.  I'd
just like an answer to my question.

>An interface need not be involved in any
>inheritance hierarchy.  If you use abstract base classes as the means
>to interfaces, then you are basically publishing a "contract" that
>things derived from them will have the characteristics (methods and
>whatnot) described in the base abstraction.  If not, why even have it?

True.  The same is true of interface files, isn't it?

>Different interfaces, OTOH, allows one to view a thing from completely
>separate perspectives which may not be related in any way except
>through an underlying implementation.

Abstract base classes can accomplish this also, through multiple
inheritance.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EG2F2w.7Dr@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >Second, you seem caught in the thought mode that everything is
> >modeled via inheritance related classification.  A widespread though
> >unjustified belief.  
> 
> Spare me the psychoanalysis.  I'm not interested in what mode of
> thought I'm caught in, and I don't think others are either.  I'd
> just like an answer to my question.

Hey, that's not "psychoanalysis"! ;-)


> >An interface need not be involved in any
> >inheritance hierarchy.  If you use abstract base classes as the means
> >to interfaces, then you are basically publishing a "contract" that
> >things derived from them will have the characteristics (methods and
> >whatnot) described in the base abstraction.  If not, why even have it?
> 
> True.  The same is true of interface files, isn't it?

OK, maybe the problem is I really don't know what you mean by
"interface file".  For a spec. the answer is false.  You can't derive
from it (though you can extend it in "arbitrary" ways via children)
and there's no inheritance.

> >Different interfaces, OTOH, allows one to view a thing from completely
> >separate perspectives which may not be related in any way except
> >through an underlying implementation.
> 
> Abstract base classes can accomplish this also, through multiple
> inheritance.

The point is, the things are directly related via subclassing and
inheritance while this is not true for specs.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Sep6152002@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EG2F2w.7Dr@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Spare me the psychoanalysis.  I'm not interested in what mode of
>> thought I'm caught in, and I don't think others are either.  I'd
>> just like an answer to my question.
>
>Hey, that's not "psychoanalysis"! ;-)

Yes, I suppose my comment would have been more appropriate if you'd
told me that my arguments reveal serious childhood scarring and a
deep hatred of my father.  :-)

>> >An interface need not be involved in any
>> >inheritance hierarchy.  If you use abstract base classes as the means
>> >to interfaces, then you are basically publishing a "contract" that
>> >things derived from them will have the characteristics (methods and
>> >whatnot) described in the base abstraction.  If not, why even have it?
>> 
>> True.  The same is true of interface files, isn't it?
>
>OK, maybe the problem is I really don't know what you mean by
>"interface file".  For a spec. the answer is false.  You can't derive
>from it (though you can extend it in "arbitrary" ways via children)
>and there's no inheritance.

What's the difference between extending a spec with children, and
deriving a subclass from an abstract class?

>> >Different interfaces, OTOH, allows one to view a thing from completely
>> >separate perspectives which may not be related in any way except
>> >through an underlying implementation.
>> 
>> Abstract base classes can accomplish this also, through multiple
>> inheritance.
>
>The point is, the things are directly related via subclassing and
>inheritance while this is not true for specs.

As I see it, the body must have all the properties of the spec,
and perhaps more.  Ada does not use the term "inheritance" for this,
but I think it's valid for Eiffel to do so.  Don't you?  If not,
what is it about inheritance which fails to properly model the
spec-implementation relationship?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Jon S Anthony]

In article <EG4Mry.L2C@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >OK, maybe the problem is I really don't know what you mean by
> >"interface file".  For a spec. the answer is false.  You can't derive
> >from it (though you can extend it in "arbitrary" ways via children)
> >and there's no inheritance.
> 
> What's the difference between extending a spec with children, and
> deriving a subclass from an abstract class?

This is pretty interesting.  I'm a little startled that this isn't
just "obvious".

When you dervive a class C from a class P (abstract or otherwise), you
are setting up a semantic relationship between P and C, where C
inherits the properties of P.  What is more, you can (if C or P are
concrete) have instances of P and C.  Neither of these has any meaning
in the context of package P and child P.C.  P.C does not inherit
anything from P (it has _visibility_ into P, including private section
visibility in it's private section).  Neither P nor P.C define a
runtime entity and in no case can you create instances of P or P.C The
bodies of either are simply the implementations of the interface(s)
bundled in either (the impls of operations or the types and methods on
those types defined in them).  This strikes me as completely different
from the subclassing.  Maybe a good question to ask is, why do you
think they are similar?

> >> Abstract base classes can accomplish this also, through multiple
> >> inheritance.
> >
> >The point is, the things are directly related via subclassing and
> >inheritance while this is not true for specs.
> 
> As I see it, the body must have all the properties of the spec,
> and perhaps more.  Ada does not use the term "inheritance" for this,
> but I think it's valid for Eiffel to do so.  Don't you?  If not,
> what is it about inheritance which fails to properly model the
> spec-implementation relationship?

Why do you think the bodies have all the properties of the spec?  I'm
not even sure what this would mean.  What's more it should be clear
that they don't: for example, nothing has any visibility into bodies.

Ada does not use "inheritance" in either the context of spec<->body
relationship or parent_spec<->child_spec relationship because to do so
would be extremely misleading (at best) given the typical
understanding of that term in programming language design and software
construction.

Also, wrt the relationship between bodies and specs. Eiffel does not
use this term either (that's what the "short form" is about - not
inheritance).  The notion of "implementation" in the sense of concrete
class C derived from abstract/deferred class P "implementing P" is a
different thing altogether.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Separation of IF and Imp: process issue?

[Patrick Doyle]

In article <JSA.97Sep8150207@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EG4Mry.L2C@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> >OK, maybe the problem is I really don't know what you mean by
>> >"interface file".  For a spec. the answer is false.  You can't derive
>> >from it (though you can extend it in "arbitrary" ways via children)
>> >and there's no inheritance.
>> 
>> What's the difference between extending a spec with children, and
>> deriving a subclass from an abstract class?
>
>This is pretty interesting.  I'm a little startled that this isn't
>just "obvious".

I've never used Ada, so I'm not familiar with exactly what child
specs are.

>When you dervive a class C from a class P (abstract or otherwise), you
>are setting up a semantic relationship between P and C, where C
>inherits the properties of P.  What is more, you can (if C or P are
>concrete) have instances of P and C.  Neither of these has any meaning
>in the context of package P and child P.C.  P.C does not inherit
>anything from P (it has _visibility_ into P, including private section
>visibility in it's private section).  Neither P nor P.C define a
>runtime entity and in no case can you create instances of P or P.C The
>bodies of either are simply the implementations of the interface(s)
>bundled in either (the impls of operations or the types and methods on
>those types defined in them).  This strikes me as completely different
>from the subclassing.  Maybe a good question to ask is, why do you
>think they are similar?

Ignorance.  :-)

I should find out more about Ada 95 before I continue.

But let me ask you about one thing you said...

P.C does not inherit anything from P.  So what is the advantage of
creating a child spec versus a whole new spec?

>> >> Abstract base classes can accomplish this also, through multiple
>> >> inheritance.
>> >
>> >The point is, the things are directly related via subclassing and
>> >inheritance while this is not true for specs.
>> 
>> As I see it, the body must have all the properties of the spec,
>> and perhaps more.  Ada does not use the term "inheritance" for this,
>> but I think it's valid for Eiffel to do so.  Don't you?  If not,
>> what is it about inheritance which fails to properly model the
>> spec-implementation relationship?
>
>Why do you think the bodies have all the properties of the spec?  

I mean, for example, that if the spec defines some function, the
body must implement this function.  That's very similar to how
a deferred feature in Eiffel is defined in the subclass.

When I said "properties" I meant interface properties, like what
functions they implement and whatever other properties Ada allows
you to declare in a package spec.  Whatever interfacing properties
the spec declares, the body must posess.  To me, this smacks of
inheritance.

>Also, wrt the relationship between bodies and specs. Eiffel does not
>use this term either (that's what the "short form" is about - not
>inheritance).  

But if you take the short form and put in the word "deferred" in
a few places, it becomes a deferred class.  In fact, the Short
tool could do this for you; the fact that it doesn't reflects
the fact that short forms are meant for documentation, but they
could equally well be considered to create a class which defines
the specification of another class.

>The notion of "implementation" in the sense of concrete
>class C derived from abstract/deferred class P "implementing P" is a
>different thing altogether.

The way I see it, a deferred class sets forth some interface properties--
the same kinds of properties as a spec file, and more--which its
subclasses must posess.  To me, it's exactly the same situation
between spec files and implementation files.

This may, of course, just reflect my misunderstanding of Ada.  I
have presumed that spec files are similar to header files in C++.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Separation of IF and Imp: process issue?

[Matthew Heaney]

In article <EG7vLM.AG@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>This may, of course, just reflect my misunderstanding of Ada.  I
>have presumed that spec files are similar to header files in C++.

The Ada paradigm is that modules and types are orthogonal features.  The
Ada programmer naturally thinks along 2 different dimensions.  (This
orthogonally is deliberate, as a module can serve purposes other than being
just the interface of a type.)

The Eiffel paradigm is that the module and type are the same, and
furthermore, that the specification be automatically extracted from the
body.

Your best bet is to not try to compare Ada's modules specs to Eiffel's
abstract classes.  You are comparing apples and oranges.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Separation of IF and Imp: process issue?

[Samuel Mize]

Patrick Doyle wrote:
> 
> In article <JSA.97Sep8150207@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
...
> But let me ask you about one thing you said...
> 
> P.C does not inherit anything from P.  So what is the advantage of
> creating a child spec versus a whole new spec?

The child can see into the private part of the parent package.

This has to do with a package being a "module" (a collection of
things) rather than being a class definition.

A common example is an OS interface provided as a group of packages,
one for the file system, one for time utilities, etc.  They are all
children of a parent package that ONLY has private elements --
the items that the OS packages need to share.

The children can see and use these private variables, constants
and subprograms, but the client using one or more OS interface
packages cannot get at them.

The interface is broken up into many child packages so the user can
limit the amount of code "with"ed into the program.  If you only
need the current time, you don't have to bring in the entire OS
interface.


> When I said "properties" I meant interface properties, like what
> functions they implement and whatever other properties Ada allows
> you to declare in a package spec.  Whatever interfacing properties
> the spec declares, the body must posess.  To me, this smacks of
> inheritance.

If you only have a hammer, everything smacks of being a nail.

I realize that some people believe that the object-oriented view
subsumes all others, and no other paradigm SHOULD be used.  Ada was
not designed with this view.  For us, when doing non-object-oriented
coding, it's confusing to refer to "classes" and "deferred classes"
and "inheritance," especially if we ARE using object-oriented design
and coding methods elsewhere in our code.

We are doing something other than inheritance.  It can be modeled
with inheritance, just as everything done in Eiffel can be modeled
with straight functional assembly code (proof by existence: any
Eiffel compiler).  But non-object-oriented design methods use
other concepts than inheritance, and these are only confused by
being jammed into object-oriented terms.


> The way I see it, a deferred class sets forth some interface properties--
> the same kinds of properties as a spec file, and more--which its
> subclasses must posess.  To me, it's exactly the same situation
> between spec files and implementation files.

For packages that are classes, yes.

> Patrick Doyle
> doylep@ecf.utoronto.ca

Sam Mize

Re: Separation of IF and Imp: process issue?

[Michael Gacsaly]

I have been reading this thread for a while, but I don't see how an abstract
Eiffel class creates a CONTROLLED interface.  The implementation class users
would still need to reference the implementation class if they wanted
implementation behavior and the implementation class could have an interface
different from the abstract class, unless the specification of the
implementation class was, itself, controlled.

Re: A DBC experience (was Re: Design by Contract)

[Simon Wright]

Richie Bielak <richieb@XYZZYcalfp.com> writes:

>                if (not_found) Thread.sleep (1000);  /*  half a second sleep and
> then try again */

Interesting that the only comment in the program is in fact wrong ..

Also, the code to manage the loop looks fearsomely complex, can't you
'return i' from inside a try block?

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Divsion            FAX: +44(0)1705-701800

Re: A DBC experience (was Re: Design by Contract)

[Richie Bielak]

Peter Horan wrote:

> The problem is a side effect which must be present (by inference) in the
> original java code `ecs[i].ready()'.

No. "ready ()" is a query. There is no side-effect,just concurrency. The socket
can be checked and show as not ready,
but can become ready by the time the postcondition is evaluated.

This is not really relevent. As the contract states that the socket returned
should be ready for I/O, it doesn't care which socket it is. The contract also
allows result of -1, that is no ready sockets, when in fact a socket has become
ready after all were checked. In the context of our program this was what we
expected.

...richie

--
* richieb@XYZZYnetlabs.net       - at home |  Richie Bielak        *
* richieb@XYZZYcalfp.com         - at work |                       *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *
*        (Remove XYZZY  from my address before replying)           *

Re: A DBC experience (was Re: Design by Contract)

[Peter Horan]

Richie Bielak wrote:
> 
> Peter Horan wrote:
> 
> > The problem is a side effect which must be present (by inference) in the
> > original java code `ecs[i].ready()'.
> 
> No. "ready ()" is a query. There is no side-effect,just concurrency. The socket
> can be checked and show as not ready,
> but can become ready by the time the postcondition is evaluated.
> 
> This is not really relevent. As the contract states that the socket returned
> should be ready for I/O, it doesn't care which socket it is. The contract also
> allows result of -1, that is no ready sockets, when in fact a socket has become
> ready after all were checked. In the context of our program this was what we
> expected.
> 
Agreed. What I should have said was that the post-condition
        (Result /= -1) implies ecs.item(Result).ready
is satisfied if Result = -1. regardless of the value of
ecs.item(Result).ready

So the argument raised by holsti@ssf.fi fails: 
> ..UNLESS the socket happens to become ready AFTER it was tested inside the
> routine, but BEFORE the postcondition is checked. Granted that in this
> example this would be unlikely to occur during the test, but in other
> examples similar things might be likely.

Holsti also says:
> If I understand the Eiffel code
> correctly, the postcondition is not sufficient to show that there is no
> error in the routine, although it is sufficient to ensure that
> the program does not block on a non-ready socket.

I am not sure what this means. How is the post-condition insufficient?

-- 
Peter Horan                     School of Computing and Mathematics
peter@deakin.edu.au             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

Re: Design by Contract

[Nick Leaton]

Bengt Kleberg wrote:
> 
> In article <34023BC4.2781E494@eiffel.com>, Bertrand Meyer
> <Bertrand.Meyer@eiffel.com> wrote:
> 
> ...deleted
> >
> > All the rhetoric in the world fades away when assessed
> > against the potential for dramatic improvements in
> > software quality. That's what counts  -- not who shouts
> > louder.
> 
> I really wish this was true. Unfortunatly it does not seem to be correct.
> My attempts get a chance to use Eiffel, in any project at all, fail.
> Always with the counter argument that C++ is much more widely used/known
> so that is what we must have. Lately a little Java has sneaked in, but it
> is still mostly C++.
> 
> So it seems as if the myriad of voices screaming C++ drowns the dramatic
> improvements in software quality available elsewhere.

Sadly true, but that is their problem. Personally I don't mind having
the competitive advantage of using a clean, powerful language such as
Eiffel. If they want the problems of C++ ...

-- 

Nick

Re: Design by Contract

[Bertrand Meyer]

on S Anthony writes:
 
> Isn't this simply amazing?  I mean, really - what do these people
> think they are saying anyway?  To me this has long since pushed my
> "boggo-meter" off the scale and crossed into the mind-numbingly
> fatuous.
 
where "these people", if I understand properly, means advocates
of Design by Contract.

Insulting the other side is not a substitute for rational argument
(but tends to suggest fragility of one's case).

In a related message, W. Wesley Groleau writes

 >       I say again: If [Design by Contract]
 >       is defined as "Associating specifications 
 >       with software elements", then Eiffel indeed directly
 >       supports a SUBSET of DBC.  Ada directly supports another
 >       subset of DBC. C++ (shudder) directly supports yet
 >       another subset of DBC.  And  with a little extra work,
 >       the user of any of these languages can  handle a larger
 >       subset.  But none of them can completely support 
 >       the whole thing.  And the intersection of the subsets
 >       is not empty.

which the 3 or 4 Ada advocates in this thread now
repeat in all tunes to assert that, after all, Ada supports
Design by Contract just as much as Eiffel, only differently.

This is a sophism. Of course in any typed language you
can express some specification elements;
e.g. by declaring f (x: INTEGER) in
Pascal or the equivalent in Fortran, C, Ada etc. you are
placing some restrictions on what kind of argument f admits.
But this is a far cry from what you need to express useful
specifications:

        - Routine preconditions -- semantic conditions
          (not just type constraints).

        - Routine postconditions (how do you state that
          at the end of the procedure `withdraw' the balance
          must have been decreased by `sum'?).

        - Class invariants, expressing general integrity
          constraints.

        - The relationship with inheritance (precondition weakening
          and postcondition strengthening in redeclaration;
          invariant accumulation).

        - The relationship with documentation tools.

        - The relationship with exception handling.

Common languages support at most a minute subset of the 1st
and 3rd items. To use this observation to justify a Turing-tarpit
kind of argument -- "all languages support Design by Contract,
only in various ways" -- is a fallacy. So huge a "difference of
degree" becomes a difference of nature.

Just take any of the assertions of the classes of EiffelBase
and try to express them in C, Ada, C++ or Java. You will be
able to write almost nothing.

What *is* true is that in such languages without assertions
you can and should still apply Design by Contract purely as
a methodological discipline. Although you won't get the
language and tool support, you will still get some of the benefits.
But, no, declaring variables with interval types as in Pascal
or Ada is not Design by Contract.

The rear-guard battle waged by a few people against Design
by Contract on comp.lang.ada and comp.lang.eiffel --
oscillating between "it's useless", "it can all be done in Ada",
"it's nothing new", "it's irrelevant to the real problems",
"it's not enough", "it's snake oil" and other endless
if often contradictory variations -- is saddening.
Saddening because as soon as Design by Contract is applied
systematically (whether as pure methodology, or better
yet in a language like Eiffel that directly supports them)
the benefits in reliability are immediate and huge.
We constantly hear from our customers and our own work
of major potential bugs that are caught before they
have had time to strike, simply thanks to contracts.
And bug avoidance is only one of the applications.
The ability to do serious object-oriented analysis,
for example, is just as important.

All the rhetoric in the world fades away when assessed
against the potential for dramatic improvements in
software quality. That's what counts  -- not who shouts
louder. 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Design by Contract

[Patrick Doyle]

  Hey, Jon, take a deep breath, relax, and have a look at what you said...

In article <JSA.97Aug26151833@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <34023C68.794BDF32@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:
>
>> Insulting the other side is not a substitute for rational argument
>> (but tends to suggest fragility of one's case).
>
>This from someone who has offered not much beyond "because I say so"
>as "substance" in this "debate".  Go figure.
>
>> All the rhetoric in the world fades away when assessed against the
>> potential for dramatic improvements in software quality. That's what
>> counts -- not who shouts louder.
>
>With luck - so will yours.

  You're doing just what he's accusing you of doing.  And it's just
as pointless as he says it is.  Ok, maybe he's doing it too, but
if Bertrand Meyer jumped off a bridge...

  Why don't both you guys tell us once again exactly what your
central points are, and we can get back on track.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Design by Contract

[Bertrand Meyer]

on S Anthony writes:
 
> Isn't this simply amazing?  I mean, really - what do these people
> think they are saying anyway?  To me this has long since pushed my
> "boggo-meter" off the scale and crossed into the mind-numbingly
> fatuous.
 
where "these people", if I understand properly, means advocates
of Design by Contract.

Insulting the other side is not a substitute for rational argument
(but tends to suggest fragility of one's case).

In a related message, W. Wesley Groleau writes

 >       I say again: If [Design by Contract]
 >       is defined as "Associating specifications 
 >       with software elements", then Eiffel indeed directly
 >       supports a SUBSET of DBC.  Ada directly supports another
 >       subset of DBC. C++ (shudder) directly supports yet
 >       another subset of DBC.  And  with a little extra work,
 >       the user of any of these languages can  handle a larger
 >       subset.  But none of them can completely support 
 >       the whole thing.  And the intersection of the subsets
 >       is not empty.

which the 3 or 4 strident Ada advocates in this thread now
repeat in all tunes to assert that, after all, Ada supports
Design by Contract just as much as Eiffel, only differently.

This is a sophism. Of course in any typed language you can
express some specification elements;
e.g. by declaring f (x: INTEGER) in
Pascal or the equivalent in Fortran, C, Ada etc. you are
placing some restrictions on what kind of argument f admits.
But this is a far cry from what you need to express useful
specifications:

        - Routine preconditions -- semantic conditions
          (not just type constraints).

        - Routine postconditions (how do you state that
          at the end of the procedure `withdraw' the balance
          must have been decreased by `sum'?).

        - Class invariants, expressing general integrity
          constraints.

        - The relationship with inheritance (precondition weakening
          and postcondition strengthening in redeclaration;
          invariant accumulation).

        - The relationship with documentation tools.

        - The relationship with exception handling.

Common languages support at most a minute subset of the 1st
and 3rd items. To use this observation to justify a Turing-tarpit
kind of argument -- "all languages support Design by Contract,
only in various ways" -- is a fallacy. So huge a "difference of
degree" becomes a difference of nature. Just take any of the
assertions of the classes of EiffelBase and try to express
them in C, Ada, C++ or Java. You will be able to write almost
nothing.

What *is* true is that in such languages without assertions
you can and should still apply Design by Contract purely as
a methodological discipline. Although you won't get the
language and tool support, you will still get some of the benefits.
But, no, declaring variables with interval types as in Pascal
or Ada is not Design by Contract.

The rear-guard battle waged by a few people against Design
by Contract on comp.lang.ada and comp.lang.eiffel --
oscillating between "it's useless", "it can all be done in Ada",
"it's nothing new", "it's irrelevant to the real problems",
"it's not enough", "it's snake oil" and other endless
if often contradictory variations -- is saddening.
Saddening because as soon as Design by Contract is applied
systematically (whether as pure methodology, or better
yet in a language like Eiffel that directly supports them)
the benefits in reliability are immediate and huge.
We constantly hear from our customers and our own work
of major potential bugs that are caught before they
have had time to strike, simply thanks to contracts.
And bug avoidance is only one of the applications.
The ability to do serious object-oriented analysis,
for example, is just as important.

All the rhetoric in the world fades away when assessed
against the potential for dramatic improvements in
software quality. That's what counts  -- not who shouts
louder. 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: Design by Contract

[Steve Stringfellow]

Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

>All the rhetoric in the world fades away when assessed
>against the potential for dramatic improvements in
>software quality. That's what counts  -- not who shouts
>louder. 

As someone who likes Eiffel but is still learning OOP,
I have two questions for Dr. Meyer:

1. There have been many assertions about the quality of
programs turned out by DBC and Eiffel, where are the 
killer apps written in either Eiffel or Ada?  It would 
seem that there would be at least some programs that 
just glow with how well they were done in Eiffel.  And
how they couldn't have been done in any other language.
The language Forth in the realtime, small computer
field is noted for stories of how it did things no other 
language could do.  But the only language in OOP that
seems like that is Smalltalk.  Why?

2. Why not make Eiffel a framework that you can use for
designing programs that are ultimately written in C,
C++, or Java?  By this I mean turning out readable
rather than just executable code in these languages
and keeping the snide comments about C programmers and
language to a minimum.  If Eiffel could turn out good
code in C, C++, or Java the opportunities would be
huge.  If it were seen that these languages were the
assembly languages of Eiffel and that you sometimes 
write routines in assembler then Eiffel would be the
ultimate framework.  The possibilities are enormous.

Until there is a breakthrough in either area I am 
afraid that Eiffel is on the way to becoming either
the Forth or the Pascal of the OOP world.  And given
the neat qualities of Eiffel I would hate to see it
suffer either fate.

Steve Stringfellow  steves@mcs.com


>-- 
>Bertrand Meyer, President, ISE Inc.
>ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
>805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
>http://www.eiffel.com, with instructions for download

Re: Design by Contract

[Don Harrison]

Bertrand Meyer wrote:

:... Ada supports
:Design by Contract just as much as Eiffel, only differently.
:
:This is a sophism. Of course in any typed language you can
:express some specification elements;
:e.g. by declaring f (x: INTEGER) in
:Pascal or the equivalent in Fortran, C, Ada etc. you are
:placing some restrictions on what kind of argument f admits.
:But this is a far cry from what you need to express useful
:specifications:
:
:        - Routine preconditions -- semantic conditions
:          (not just type constraints).
:
:        - Routine postconditions (how do you state that
:          at the end of the procedure `withdraw' the balance
:          must have been decreased by `sum'?).
:
:        - Class invariants, expressing general integrity
:          constraints.
:
:        - The relationship with inheritance (precondition weakening
:          and postcondition strengthening in redeclaration;
:          invariant accumulation).
:
:        - The relationship with documentation tools.
:
:        - The relationship with exception handling.
:
:Common languages support at most a minute subset of the 1st
:and 3rd items. To use this observation to justify a Turing-tarpit
:kind of argument -- "all languages support Design by Contract,
:only in various ways" -- is a fallacy. So huge a "difference of
:degree" becomes a difference of nature. Just take any of the
:assertions of the classes of EiffelBase and try to express
:them in C, Ada, C++ or Java. You will be able to write almost
:nothing.
:
:What *is* true is that in such languages without assertions
:you can and should still apply Design by Contract purely as
:a methodological discipline. Although you won't get the
:language and tool support, you will still get some of the benefits.
:But, no, declaring variables with interval types as in Pascal
:or Ada is not Design by Contract.
:
:The rear-guard battle waged by a few people against Design
:by Contract on comp.lang.ada and comp.lang.eiffel --
:oscillating between "it's useless", "it can all be done in Ada",
:"it's nothing new", "it's irrelevant to the real problems",
:"it's not enough", "it's snake oil" and other endless
:if often contradictory variations -- is saddening.
:Saddening because as soon as Design by Contract is applied
:systematically (whether as pure methodology, or better
:yet in a language like Eiffel that directly supports them)
:the benefits in reliability are immediate and huge.
:We constantly hear from our customers and our own work
:of major potential bugs that are caught before they
:have had time to strike, simply thanks to contracts.
:And bug avoidance is only one of the applications.
:The ability to do serious object-oriented analysis,
:for example, is just as important.
:
:All the rhetoric in the world fades away when assessed
:against the potential for dramatic improvements in
:software quality. That's what counts  -- not who shouts
:louder. 

Well said.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison     nospam@thankyou.maam.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote (with deletions):
> 
> :Don Harrison wrote:
> 
> [...]
> 
> :> No. If an error doesn't exist, it can't be ported.
> :
> :Consider the Ariane case. The error didn't exist in the original
> :environment
> :(Ariane IV). The error only occured during execution in the Ariane 5
> :environment (a little too late to fix, unfortunately). Basing your
> :argument
> :on execution means that any latent error in the system, which might be
> :caught in other methodologies through the use of analysis and reviews,
> :will
> :be missed using DBC/Eiffel.
> 
> I disagree. I'll explain below..
> 
> [...]
> 
> :> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
> :> :> "Accessing separate objects", Page 982 ff.)
> :> :>
> :> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
> :> :> To overcome this deficiency, you have to either roll-your-own object protection
> :> :> (using semaphores, for example) or use protected objects. Using Ada protected
> :> :> objects is fine, but they lack the flexibility of Eiffel separate objects.
> :> :
> :> :Just the opposite!
> :>
> :> Incorrect.
> :
> :Eiffel separate objects always lock the object. Ada protected records
> :can lock the
> :object for a given operation or not (at the designer's preference),
> 
> IMO, this is something the designer is better off leaving to the compiler as
> it can be expected to do a better job of it. If Ada protected types allow
> the designer to explicitly leave objects unlocked (which doesn't appear to
> be supported by the Ada95 Rationale), then they are more permissive but
> in a detrimental way, IMO.

Since such decisions are fundamental to the design of real-time systems,
isn't this statement equivalent to "it's better to have tool X design
my software autonomously than for a human to do it?"

I think when you actually start building complex real-time systems,
you will see that more locking is not equivalent to better design.

> 
> :can requeue requests,
> 
> IMO, the situations in which you would use "requeue" are better handled by
> designing differently - perhaps by using an additional class. If anything,
> "requeue" probably encourages poor design.
> 
> :etc.
> 
> What are these?
> 
> More choices for the designer usually means additional
> :flexibility, I would think.
> 
> Drawing some inspiration from Robert Dewar, "flexibility" and "permissiveness"
> have at their root the same meaning but differ wrt the user perceives a benefit
> or detriment respectively.

Very true. In Ada, the "permissiveness" is defined as allowing the
programmer
to do that which is historically error-prone (e.g. the copy principal).
Do you
have evidence that enforced blocking on _all_ objects solves a common
problem in the design of real-time systems, particularly when excessive
blocking often leads to deadlock?

> 
> [...]
> 
> :> :Someone needs to decide if DBC is a coding guideline or a software
> :> :development
> :> :methodology. My concern is that it is touted as the former, but used as
> :> :the latter.
> :>
> :> I don't see any problem with using it as both.
> :
> :However, there is a serious problem when practitioners use it (and
> :discuss it) in terms of the former. Note the number of times in this
> :post, for example, that DBC has been described in terms of concrete
> :capabilities when the subject is code execution, but only vaguely
> :(if at all) when described as a methodology..
> 
> Your basic worry seems to be that DBC doesn't appear to be an all-embracing,
> formal software engineering methodology.

Absolutely. In fact, based on some of the discussions, it seems to be
reduced almost to a coding standard in some practitioner's mind. (This
isn't entirely fair to DBC, of course, but it highlights the problem
with calling DBC a "methodology" vs. a "tool" or "technique".)

> At this stage, I think you're right. I think the reason why is that DBC
> probably hasn't been used in the context of *formal* software engineering.
> If it had, then it would have been integrated with other complementary
> reliability-enhancing techniques.
> 
> IMO, a methodology centred on DBC, would also include stuff about systematic
> testing of components. In the Ariane case, this might involve bolting an IRS
> onto some test bench and stimulating it with Ariane 5 data. This may require
> simulating the surrounding environment. Then, any assertions assuming Ariane 4
> inputs would be violated (as would the Ada constraint_error). In general,
> the extra checking afforded by DBC would mean more bugs would be identified
> than if it wasn't used. (Yes, I know there is no difference wrt the one that
> caused the failure.)
> 
> [...]
> 
> :> :So, I'm still at a loss to
> :> :see what DBC brings to the table here. It doesn't address my main
> :> :problem (requirements/design faults),
> :>
> :> Not entirely true. DBC can highlight specification/design inconsistencies.
> :> (See my previous posts). Otherwise, I agree.
> :
> :I saw your previous posts. I quote from the line above:
> :
> :  "WRT documentation-related problems, these are outside the scope of
> :  any runtime error checking mechanism. DBC is *almost* a silver bullet
> :  but not quite."
> 
> Right person, wrong quote and wrong context. If it's any help to you, the
> comments I'm referring to were about mutually validating requirements. I
> acknowledged not all documentation errors were covered.

But all of my requirements are in the documentation! By definition, my
code
is an _implementation_ of those requirements, not the _definition_ of
them.

> 
> [...]
> 
> :> :it's not clear that it scales well,
> :>
> :> Not true.
> :
> :Can you provide evidence to the contrary?
> 
> I've already covered this. Nick's experience also endorses it.

I must have missed it. Could you list the projects again? I saw some
hypothetical discussion of why it might scale, but I think Mr. Jezequel
is correct: There isn't sufficient _evidence_ to say that it _will_
scale.

> 
> [...]
> 
> :> :and not much on what to do after the error is detected, for example).
> :>
> :> Again, this is usually blindingly obvious.
> :>
> :Any time someone says something is obvious, without any evidence or
> :argument to support it, I pretty much assume that the point is ceded.
> 
> No, it just means I'm just getting impatient. :(

Unfortunate. Having the patience to reconsider the "blindingly obvious"
has usually led me to my best work.

I find that if I can't put together a logical argument, preferably
backed
by observable evidence, then I'm probably working on emotion rather
than insight. A long time ago, I thought it was "blindingly obvious"
that
OO approaches wouldn't work in real-time systems. After I started
considering the issue further, and doing demonstration projects using
OO techniques, I found I was dead wrong.

> 
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[W. Wesley Groleau x4923]

> :Any time someone says something is obvious, without any evidence or
> :argument to support it, I pretty much assume that the point is ceded.

If someone says X is obvious, when many people do not see X, then
someone doesn't define obvious the same way I do.....

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Wes says

<<If someone says X is obvious, when many people do not see X, then
someone doesn't define obvious the same way I do.....>>


That's not quite so simple an issue. The word obvious has to be defined
for a particular subset of people. What is obvious to nuclear engineers,
or for that matter to experts in automobile tire repair, may not be
obvious to me, but that does not mean the word is being used in a strange
way.

I think we all from time to time make the mistake of not defining clearly
what the domain is for the use of the word obvious. FOr example, there
are things about the definition of Ada at the RM level that are indeed
obvious to the ARG members, and others with this kind of exposure to the
RM, but not generally obvious, even to skilled programmers.

Consequently, the word obvious is probably better avoided, unless you are
very careful to say what the claimed domain is (I have been trying to
avoid using the O-word, even when things are quite O to me :-)

Re: Safety-critical development in Ada and Eiffel

[Warwick Pulley]

Don Harrison wrote:
> Ken Garlington wrote:
> 
> :But I can do this in Ada, as well, so I don't see the benefit.
> 
> I'm not saying there is any extra benefit - merely that you don't have to 
> wear the overhead of dynamic binding if you're desperate to maximise efficiency.
> Tucker mentioned that overhead. I'm saying it isn't an issue.
> 
> BTW, how do call a procedure under different names in Ada?

By declaring a procedure that "renames" the old one, eg.

procedure ADD_ONE(X: in out INTEGER);
procedure INCREMENT(X: in out INTEGER) renames ADD_ONE;

<large section snipped>

> :There is a school of thought that says to add in assertions, test the
> :system, and
> :then remove/suppress the exceptions. I have seen too many cases of code
> :that works
> :with the assertions active, and then breaks (due to timing differences,
> 
> Yes, timing *is* something to be concerned about when applied to realtime 
> systems. That's why I suggested not using assertions in the hard realtime
> threads of a process. BTW, software designed using DBC may actually run *faster*
> than code without it because you get to strip out all the defensive validity
> checks. You have already ascertained during development that operations are
> called in valid contexts so you don't have to check the context.

In Eiffel that may be true provided that removal of assertion checks doesn't
significantly affect the performance of the code in any way.  The issue of timing,
mentioned by Ken above, is a good example).

I imagine that one needs to take special care when using assertions in
languages that don't fully support them.  From my (sorely lacking!!) knowledge
of Eiffel, clauses that define the precondition and postcondition of an
operation contain exactly one boolean statement which automatically restricts
the coder from including procedural code within these sections.

While this argument favours Eiffel in terms of assertions, it doesn't
mean that porting this functionality to Ada will not introduce other faults.
With Don's demonstration of assertions last Friday (Jul 11 18:05:13 EST) the
postcondition was implemented in the form:

if <assertions on> and then <bool_postcondition>
  raise <postcondition exception>
end if;

The implementation of the assertion is done with multiple statements, so
there is the possibility of important sections of code being inadvertently
added within the "if" statement which would then be removed when assertions
are disabled.

I have seen this happen at least once, where an executable was released to
the test group which AFAIK was only tested with assertions enabled, and then
it was discovered that a crucial line of code was removed because it was
within an assertion block and once this error was encountered the executable
didn't crash but its functionality was imparired severely enough so that
it had to be run again.

Even one error, however minor, is enough to warrant another round of
testing after assertions are removed: at least for languages that don't
fully support assertions.  Even if no errors are discovered in the process
I would consider it a worthwhile exercise, if only to convince myself that
the software functions how I intended.

A suggestion: to avoid some of these problems one could have written two
procedures, say 'precondition' and 'postcondition', each having an 'in'
boolean parameter.  Each procedure should do nothing if assertions are
disabled, but if they are enabled then they would raise the appropriate
exception if the 'in' parameter was false.

Then rather than the above block, one could evaluate a postcondition
by the call:

postcondition(<bool_postcondition>);

and similiarly for preconditions.  A sample implementation of 'postcondition'
(in pseudo-Ada) is:

--------------------------------------------------------------------------------

procedure postcondition(requirement: in boolean) is
begin

# if <assertions on> then

  -- check condition and raise exception if violated
  if not requirement then
    raise <postcondition exception;>
  end if;

# else

  null;

# end if;

end postcondition;
pragma INLINE(postcondition);
--------------------------------------------------------------------------------

So when exceptions are disabled (via a compiler directive), 'postcondition'
would have a null body, and since it's inline there would be no unwanted
procedure call.  It also means that you can conditionally compile
assertions without having to surround each assertion with conditional
compilation directives.

Naturally, my suggestion above still fails to prevent the addition of code
before a precondition check, or after a postcondition check, etc.

> :or more
> :likely code generation errors) to have much confidence in this approach.
> 
> If that's a problem, you need to get your vendor to clean their act up.

Yes, if you know the compiler has a bug in the first place.  The trouble is
that you don't know it's a problem until it occurs, and a compiler could
have a subtle bug that only occurs in very particular circumstances.

Although any respectable compiler has minimal bugs if any, if we don't test
our products after assertions are suppressed then we unnecessarily transform
our confidence in, into dependence on, the vendor's compiler to function
correctly.

It would be irresponsible to deliver software that has only been tested with
assertions enabled, knowing that if an error occurs in the released version
then it's "not my fault".  So for this reason, and for peace of mind, I would
certainly test the version of the software to be delivered to the customer.
Since we expect not to find more errors, this last phase would run smoothly
and quickly.

> :Another consequence of using assertions is that you have to develop and
> :test the
> :assertions. 
> 
> Correct. My initial reaction when I started using them was "Gee, I've got to
> do this extra work on top of writing the "real" code! However, I found I was 
> spending about a third of the time integrating compared with my colleagues
> which meant I was saving time overall and producing more reliable code to boot.

Why should a short integration period automatically imply code reliability?

> :As a result, you need confidence that the benefits of the assertions
> :outweigh the dilution of your test effort.
> 
> IME, they do.

I agree that some type of error checking is in order during development.  I
suppose that whether the results of a failed check is done in the form of a
text message, raising an exception or by other means is a matter for another
thread.

BTW, how do you verify the correctness of your assertions, and that there are
no errors that the assertions didn't find?  Do you prefer code inspection,
or if you do your verification by executing the program itself, how do you
ensure that each section of code is exercised?  Either way, a documentation
of your method would provide a good test which can then be reproduced should
the software be modified.

Happy coding,

Warwick.

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Warwick Pulley wrote:

> I have seen this happen at least once, where an executable was released to
> the test group which AFAIK was only tested with assertions enabled, and then
> it was discovered that a crucial line of code was removed because it was
> within an assertion block and once this error was encountered the executable
> didn't crash but its functionality was imparired severely enough so that
> it had to be run again.

Can you explain this a bit more. In Eiffel an assertion has to be 
a boolean expression, and I presume that you are not writing a 
boolean expression that has a side effect?

-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

<<Can you explain this a bit more. In Eiffel an assertion has to be
a boolean expression, and I presume that you are not writing a
boolean expression that has a side effect?
>>


The evaluation of any boolean expressoin has side effects at the level
we are talking about, at the very least it takes time and can affect
timing relationships, which of course in this kind of code can be
critical.

The idea that REMOVING the evaluation of boolean expressions completely
is semantically neutral is also completely bogus. Such removal can affect
Icache locality of the code that is left, again affecting timing, and can
also result in code being at different locations, resulting in differences
of behavior with unbounded consequences.

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Robert Dewar wrote:
> The idea that REMOVING the evaluation of boolean expressions
> completely
> is semantically neutral is also completely bogus.

That's a bit strong.

> Such removal can
> affect
> Icache locality of the code that is left, again affecting timing,

OK. Is an issue for real-time software where code timing is important.
I'm somewhat astonished that such code is still written (the last time I
saw this done was on a C64), but then I'm not in the hard RT field.

> and
> can
> also result in code being at different locations, resulting in
> differences
> of behavior with unbounded consequences.

Now *that* sounds bogus to me. The code should execute in exactly the
same way, wether assertions are turned on or off. If you don't have
enough confidence in the compiler to generate code that runs correctly,
why do you use a compiler at all? 
Yes I know compilers are buggy. Assertions within the compiler's source
code should help, but I also know this still cannot *guarantee*
correctness. But claiming "differences of behaviour with unbounded
consequences" overdoes it.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Paul M Gover]

Joachim Durchholz wrote:
> ...
> Now *that* sounds bogus to me. The code should execute in exactly the
> same way, wether assertions are turned on or off. If you don't have
> enough confidence in the compiler to generate code that runs correctly,
> why do you use a compiler at all?
> ...

(Sorry if I''m about to repeat an earlier part of this discussion - I've
not followed this thread in detail,)

By definition, the code executes differently depending on whether
asserions
are turned on or off - because the assertion checking _is_ code!
In particular, there's likely to be some memory management going on in
an
OO system.  Two possibilities: we could run out of memory in the
assertion,
or the memory management might take too long for some critical signal.

(And to direct a slight breeze towards some other embers, it doesn't
make
a difference if the OO system uses garbage collection or not; as Chamond
Liu
pointed out (see http://www.browsebooks.com/Liu/Chapter16.html),
garbage collectors tend to have predictable allocation times and 
unpredictable free (ie, collection) times, whereas heap allocation tends
to have unpredictable allocation times and predictable free times;
garbage collection systems have to search storage at collection time,
and heaps search at allocation time.)

I currently support a program where switching the diagnostic trace on
breaks part of the user interface (since the program's correct,
I don't need to trace, so I don't need to fix the bug!?!).
This one is definitely an application fault, nothing to do with the
compiler.
-- 
Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Paul M Gover wrote:
> 
> Joachim Durchholz wrote:
> > Now *that* sounds bogus to me. The code should execute in exactly
> > the
> > same way, wether assertions are turned on or off. If you don't have
> > enough confidence in the compiler to generate code that runs
> > correctly,
> > why do you use a compiler at all?
> By definition, the code executes differently depending on whether
> asserions
> are turned on or off - because the assertion checking _is_ code!

That's not what assertions are supposed to do. Of course assertions may
themselves be buggy, but the only possibility here should be that an
assertion signals an error where there is none.

> In particular, there's likely to be some memory management going on in
> an
> OO system.  Two possibilities: we could run out of memory in the
> assertion,
> or the memory management might take too long for some critical signal.

Plus the assertion themselves will take time to check, which influences
timing.
I'm not in the hard real-time business (and have never been), so I might
be grossly off the mark. What I currently think is that no harm should
result if the code runs faster after disabling assertion checking. (Some
informed people in this group have claimed otherwise, but I haven't seen
convincing arguments why this should be the case.)

Checking assertions (in the Eiffel sense) must not have observable
effects, except that the program may run slower (or similar irrelevant
differences). There are some style guidelines and hard rules that
enforce this.
Of course the mechanism for reporting exceptions may interfere with the
normal functioning of the user interface. (You can take the "exceptions
don't affect execution" only so far.)

> I currently support a program where switching the diagnostic trace on
> breaks part of the user interface (since the program's correct,
> I don't need to trace, so I don't need to fix the bug!?!).

This depends. Is the diagnostic a debugging aid? Then you don't really
have to fix it (at least if you are confident that everything will work
in the absence of diagnostics).
If the diagnostics are part of the finished product, you'll have to fix
it, of course. But then this is not what assertions are intended for (in
Eiffel). The possibility to switch off assertion checking without
affecting the program's semantics is an *axiom* in Eiffel; the language
and the guidelines go to great lengths to achieve this.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Robert S. White]

In article <33D9B8F9.4693018C@munich.netsurf.de>, 
joachim.durchholz@munich.netsurf.de says...

>Plus the assertion themselves will take time to check, which influences
>timing.
>I'm not in the hard real-time business (and have never been), so I might
>be grossly off the mark. What I currently think is that no harm should
>result if the code runs faster after disabling assertion checking. (Some
>informed people in this group have claimed otherwise, but I haven't seen
>convincing arguments why this should be the case.)

  I hope you never have to do safety-critical hard real-time programming
with more than a very few tasks running.  You have never hear of a 
deadlock?  Race condition?  Sure you try to design to avoid such things,
but you can never be sure that you have really successsfully avoided
all timing sensitivities until you _test_ for them!  The cold HARD rule
is that if the machine code changes, then regression tests _must_ be 
done.

>
>Checking assertions (in the Eiffel sense) must not have observable
>effects, except that the program may run slower (or similar irrelevant
>differences). There are some style guidelines and hard rules that
>enforce this.

  Not a suitable guard for hard real-time!  Just what is the protection
mechanism for this "must not"?  Who validates Eiffel compiler object 
code to not have any "observable effect" when release code turns off
assertion checks?

>The possibility to switch off assertion checking without
>affecting the program's semantics is an *axiom* in Eiffel; the language
>and the guidelines go to great lengths to achieve this.

  But it has not convinced me that it (assertions one during 
development, off later for the released version) are suitable for 
hard real-time without doing a set of regression tests that would expose
timing sensistivity problems.  The FAA with DO-178B would be very unhappy
that all of the object code paths are not thoroughly tested in the final
released code version.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Safety-critical development in Ada and Eiffel

[Marinos J. Yannikos]

In article <5rh12t$jl0$1@flood.weeg.uiowa.edu>, Robert S. White wrote:
>  I hope you never have to do safety-critical hard real-time programming
>with more than a very few tasks running.  You have never hear of a 
>deadlock?  Race condition?  Sure you try to design to avoid such things,
>but you can never be sure that you have really successsfully avoided
>all timing sensitivities until you _test_ for them!  The cold HARD rule
>is that if the machine code changes, then regression tests _must_ be 
>done.

(straying off-topic, but second opinions might be interesting sometimes)

There is a school of thought which insists that verifying hard real-time
systems by testing them is pointless, since you can hardly simulate all
possible events, how they interact, occur at the same time ("avalanches")
etc. Some other approaches might be taken, a good one is (IMHO) static
scheduling and checking of time constraints, which is possible if you
reduce the scope of the language the code is written in (e.g. no infinite
loops allowed). Have a look at the MARS project if you're interested:

http://www.vmars.tuwien.ac.at (not much there, unfortunately)
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-01-89.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-01-91.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-02-91.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-11-91.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-12-91.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-02-92.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-11-92.ps.Z
ftp://ftp.vmars.tuwien.ac.at/pub/papers/rr-04-93.ps.Z

(Lots of research reports about timing and Modula-r...)

A funny coincidence is that during a seminar in '93 or so at that department
I had to compare Eiffel to Modula-r regarding suitability for hard real-time
systems (the former I knew nothing about and have not read much about since
then), the latter I had the luck to have worked on for a student project.

Note that I'm slightly biased, and not being enough of a real-time
person I may easily have missed some limitations/disadvantages of the MARS
and Modula-r approach.

-nino
-- 
Please change the last part of my address to "at" if you're replying by mail.

Re: Safety-critical development in Ada and Eiffel

[Robert S. White]

In article <slrn5upcrm.jue.someone_else@a0.complang.tuwien.ac.at>, 
nino@complang.tuwien.ac.look-in-sig says...

>There is a school of thought which insists that verifying hard real-time
>systems by testing them is pointless, since you can hardly simulate all
>possible events, how they interact, occur at the same time ("avalanches")
>etc. 

  I'll grant that regression Formal Qualification Tests do not verify
all possible timing combinations, but the point is to run the embedded
system through some normal usage scenarios to _try_ to find defects
that have escaped the net of design reviews, code inspections, and
low level tests.  The level and degree (usage extremes) of the 
regression tests depend on what the safety requirements, warrenty 
requirements, customer, software quality assurance, etc. demand versus
time, equipment and money resources.  Yes it is a level of gray, not
black and white.

> Some other approaches might be taken, a good one is (IMHO) static
>scheduling and checking of time constraints, which is possible if you
>reduce the scope of the language the code is written in (e.g. no infinite
>loops allowed).

  It would be a difficult paradigm shift for my co-workers and I to 
give up using tasks with infinite loops that wait for events to be
signaled or for certain amounts of time to elapse.  Of course this
also requires the ability to detect task "cycle slips".  I've been
doing this for the last 12 years using both Jovial and Ada83 and
have been able to deploy reliable hard real time systems.  This is
not just a language issue as RTE's and RTOS's can be used by a lot
of different languages. I'm trying to visualize just what this
approach you are talking about would involve that does not use
any loops.  Guess I have to copy down one of the papers you cite.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Safety-critical development in Ada and Eiffel

[Peter Hamer]

Marinos J. Yannikos wrote:
> 
> There is a school of thought which insists that verifying hard real-time
> systems by testing them is pointless, since you can hardly simulate all
> possible events, how they interact, occur at the same time ("avalanches")
> etc. <snip>

Insufficient, certainly.

Pointless? Ask the Hubble space telescope people if they have
reconsidered the wisdom of not testing for gross errors [they
needed a space-walk to fix things]. Of course, they were absolutely
right: the available tests would not have detected errors of the size
they were designing for; just the one they had! 
  
Years ago somebody invented the analogy of the robot dentist. You
were to be the first lucky customer. What validation would you like
to have been carried out first? Would you be happy if validation was
restricted to method X; and no testing had been carried out?

Peter

Re: Safety-critical development in Ada and Eiffel

["Paul E. Bennett"]

In article <33EF06BE.730F@nortel.co.uk> pgh@nortel.co.uk "Peter Hamer" writes:

> Years ago somebody invented the analogy of the robot dentist. You
> were to be the first lucky customer. What validation would you like
> to have been carried out first? Would you be happy if validation was
> restricted to method X; and no testing had been carried out?

I have heard of one robot doing Prostate surgery. I know I wouldn't have 
volunteered to be the first on that one unless I had performed a full audit 
of the design, manufacturing and maintenance organisations. Even then I might 
have still been wary. Things I know I would have been on the look-out for
in those areas would be more with the design, manufacture and maintenance
processes and procedures employed by the organisations, proof that these
were followed and that a "Safety Culture" existed in the organisations 
concerned. Language and tools are hardly an issue.

-- 
Paul E. Bennett ................... <peb@transcontech.co.uk>
Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861                  <enquiry@transcontech.co.uk>
Going Forth Safely

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Joachim Durchholz wrote:

:Paul M Gover wrote:
:> 
:> Joachim Durchholz wrote:
:> > Now *that* sounds bogus to me. The code should execute in exactly
:> > the
:> > same way, wether assertions are turned on or off. If you don't have
:> > enough confidence in the compiler to generate code that runs
:> > correctly,
:> > why do you use a compiler at all?
:> By definition, the code executes differently depending on whether
:> asserions
:> are turned on or off - because the assertion checking _is_ code!
:
:That's not what assertions are supposed to do. Of course assertions may
:themselves be buggy, but the only possibility here should be that an
:assertion signals an error where there is none.

Since any software (sequential or concurrent) can contain timing-triggered 
branches, it's not only possible but probable that it will behave differently 
depending on whether assertions are turned on or off. Concurrent software 
typically contains such branches which may affect behaviour when extra 
processing overheads (for example, GC, assertions) are applied. Additionally, 
the non-determinism of these overheads may worsen this effect. 

This different behaviour does not indicate an error. However, another 
consequence of that overhead, which *is* erroneous, is that the software may 
fail to meet its specified timing constraints. This is the fundamental problem 
of using GC and assertions in timing critical contexts with current technology. 

Perhaps these barriers can be overcome by using more sophisticated technology..


:> In particular, there's likely to be some memory management going on in
:> an
:> OO system.  Two possibilities: we could run out of memory in the
:> assertion,
:> or the memory management might take too long for some critical signal.
:
:Plus the assertion themselves will take time to check, which influences
:timing.
:I'm not in the hard real-time business (and have never been), so I might
:be grossly off the mark. What I currently think is that no harm should
:result if the code runs faster after disabling assertion checking. (Some
:informed people in this group have claimed otherwise, but I haven't seen
:convincing arguments why this should be the case.)

As you say, the different behaviour is not a problem. However, the failure 
to meet timing constraints is.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Joe Buck]

Robert Dewar wrote:
>> The idea that REMOVING the evaluation of boolean expressions
>> completely
>> is semantically neutral is also completely bogus.

Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:
>That's a bit strong.

In real-time systems, it isn't strong; it has to be taken into account.

>> Such removal can affect
>> Icache locality of the code that is left, again affecting timing,
>
>OK. Is an issue for real-time software where code timing is important.
>I'm somewhat astonished that such code is still written (the last time I
>saw this done was on a C64), but then I'm not in the hard RT field.

This statement suggests that your perspective is too narrow.  You
encounter hard real-time systems every day.  Far more processors in the
world are running embedded real-time code than are running your favorite
PC program.  It is exactly these systems that it is most critical to get
right; people could die if they fail (anti-lock braking systems,
fly-by-wire systems in AirBus planes, industrial robots).  No one much
cares if your Unix app core dumps.  Timing constraints are often quite
tight; a telephone-bandwidth speech compression system has to produce one
sample every 125 microseconds, all the time, or the user hears a pop.
Caches are often of no use, since it is the worst case timing (the cache
miss) that counts.  If your system has to meet timing even if you take a
cache miss, why spend money on the cache?  (Instruction caches can still
pay because you may be guaranteed that your loop fits in the cache).

In practice, these problems are manageable; what matters is the timing of
critical paths, not of all paths.  But in many cases adding assertion
checks will result in a program that does not meet its deadlines, so you
need some other means (like a second processor or emulation testbench that
observes the processor under test, with assertion checks running on this
other processor).

>> and can also result in code being at different locations, resulting in
>> differences of behavior with unbounded consequences.

>Now *that* sounds bogus to me. The code should execute in exactly the
>same way, wether assertions are turned on or off. If you don't have
>enough confidence in the compiler to generate code that runs correctly,
>why do you use a compiler at all? 

All compilers have bugs, and all responsible software engineers test the
object code they are going to ship, not just different object code that has
debug code and assertions stuck in.  There's a term "Heisenbug", a bug
that disappears when you enable debugging because the compiler generates
different code when debugging is enabled.
-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://spam.abuse.net/spam/

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert Dewar wrote:

:The evaluation of any boolean expressoin has side effects at the level
:we are talking about, at the very least it takes time and can affect
:timing relationships, which of course in this kind of code can be
:critical.

Given that assertions are executed sequentially, there wouldn't appear to be 
any easy solution to this problem. The only options seem to be:

  a) Not using them at all, or
  b) Leaving them turned on in the production system. Obviously, this would
     mean efficiency problems.


:The idea that REMOVING the evaluation of boolean expressions completely
:is semantically neutral is also completely bogus. Such removal can affect
:Icache locality of the code that is left, again affecting timing, and can
:also result in code being at different locations, resulting in differences
:of behavior with unbounded consequences.

This issue would be avoided by b) above but the loss of efficiency would 
usually be unacceptable for hard realtime.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Warwick Pulley]

In article <33CD1722.2D24@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> writes:
> Warwick Pulley wrote:
> 
> > I have seen this happen at least once, where an executable was released to
> > the test group which AFAIK was only tested with assertions enabled, and then
> > it was discovered that a crucial line of code was removed because it was
> > within an assertion block and once this error was encountered the executable
> > didn't crash but its functionality was imparired severely enough so that
> > it had to be run again.
> 
> Can you explain this a bit more. In Eiffel an assertion has to be 
> a boolean expression, and I presume that you are not writing a 
> boolean expression that has a side effect?

Personally I haven't used assertions to their full extent although I like
to have error checking in place.  It turned out that the problem lay not in
the boolean expression itself, but how it was used.  The example I was
referring to above, which was also modelled in Ada, was not of the
form:

    -- example 1
    if <assertions on> and then not <check> then
      raise <postcondition error>
    end if;

    return <value>

but looked like:

    -- example 2
    if <assertions on> and then <check> then
      return <value>
    end if;
    raise <postcondition error>;

This of course worked fine when assertions were on because when the check was
satisfied a value was returned and the assertion was avoided.  When assertions
were switched off and the procedure got called, an exception was raised
unconditionally and broke the software during testing.

I my last post I mentioned a method of using assertions in Ada to address this
problem, namely by using *one-line* calls to inline precondition and
postcondition checking procedures.  They also had the advantage that the
assertions could be included only when a compiler directive was set to TRUE,
rather than using a boolean statement.  When assertions were off, the body of
the procedure would be a "null;" statement which would get optimised out.  I
hope.  :)

Example 2 above is an example how the assertions can be "mis-implemented" in
Ada, because the logic is wrong and necessary code was included in the "if"
statement.  As you have said, all you need in Eiffel is the boolean
expression itself, and since Eiffel has a special clauses for these
assertions it's not possible to include vital procedural code within these
clauses.

Although I made the point about Ada specifically, I then made it
unnecessary by making the broader statement that I would be uneasy about
releasing software that was untested with assertions removed.  This would
be whether the language I program in supports assertions or not, and I
guess the same goes for any software that's released in a different form
to which it is tested.

> -- 
> 
> Nick

Regards,

Warwick.

Re: Safety-critical development in Ada and Eiffel

[Warwick Pulley]

Apologies to those who have read this twice: I think I failed to set the
distribution properly last time.

Warwick.
--------------------------------



In article <33CD1722.2D24@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> writes:
> Warwick Pulley wrote:
> 
> > I have seen this happen at least once, where an executable was released to
> > the test group which AFAIK was only tested with assertions enabled, and then
> > it was discovered that a crucial line of code was removed because it was
> > within an assertion block and once this error was encountered the executable
> > didn't crash but its functionality was imparired severely enough so that
> > it had to be run again.
> 
> Can you explain this a bit more. In Eiffel an assertion has to be 
> a boolean expression, and I presume that you are not writing a 
> boolean expression that has a side effect?

Personally I haven't used assertions to their full extent although I like
to have error checking in place.  It turned out that the problem lay not in
the boolean expression itself, but how it was used.  The example I was
referring to above, which was also modelled in Ada, was not of the
form:

    -- example 1
    if <assertions on> and then not <check> then
      raise <postcondition error>
    end if;

    return <value>

but looked like:

    -- example 2
    if <assertions on> and then <check> then
      return <value>
    end if;
    raise <postcondition error>;

This of course worked fine when assertions were on because when the check was
satisfied a value was returned and the assertion was avoided.  When assertions
were switched off and the procedure got called, an exception was raised
unconditionally and broke the software during testing.

I my last post I mentioned a method of using assertions in Ada to address this
problem, namely by using *one-line* calls to inline precondition and
postcondition checking procedures.  They also had the advantage that the
assertions could be included only when a compiler directive was set to TRUE,
rather than using a boolean statement.  When assertions were off, the body of
the procedure would be a "null;" statement which would get optimised out.  I
hope.  :)

Example 2 above is an example how the assertions can be "mis-implemented" in
Ada, because the logic is wrong and necessary code was included in the "if"
statement.  As you have said, all you need in Eiffel is the boolean
expression itself, and since Eiffel has a special clauses for these
assertions it's not possible to include vital procedural code within these
clauses.

Although I made the point about Ada specifically, I then made it
unnecessary by making the broader statement that I would be uneasy about
releasing software that was untested with assertions removed.  This would
be whether the language I program in supports assertions or not, and I
guess the same goes for any software that's released in a different form
to which it is tested.

> -- 
> 
> Nick

Regards,

Warwick.

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Warwick Pulley wrote:

stuff on implementing assertions in Ada deleted


> Example 2 above is an example how the assertions can be "mis-implemented" in
> Ada, because the logic is wrong and necessary code was included in the "if"
> statement.  As you have said, all you need in Eiffel is the boolean
> expression itself, and since Eiffel has a special clauses for these
> assertions it's not possible to include vital procedural code within these
> clauses.

Why would you want to place procedural code in an assertion? It is the
same as saying you want to have a side effect of a function. If it is
vital code, then presuably you always want it executed. Or it may
be debugging/tracing information, in which case it isn't an assertion,
but it should be placed in some form of conditional compilation or
execution block.

Separate point. One of the valid objections that has been raised with
assertions is question of execution time being different with them on
from when they are off.

From other posters, it seems that with life critical systems (avionics)
that this is an important consideration. Am I the only one who finds
this worrying, that systems you have to trust depend on some calculation
as to how the program is going to run? What happens if a new compiler
comes out that has a different optimisation technique?



-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Nick Leaton wrote:
> 
> From other posters, it seems that with life critical systems (avionics)
> that this is an important consideration. Am I the only one who finds
> this worrying, that systems you have to trust depend on some calculation
> as to how the program is going to run? What happens if a new compiler
> comes out that has a different optimisation technique?

Our rule of thumb is that any significant change to the code generation
toolset requires a complete re-execution of the tests/analyses
associated
with the software. We prefer to "freeze" toolset versions at certain
points in the development process for this reason.

> 
> --
> 
> Nick

Re: Safety-critical development in Ada and Eiffel

[Richie Bielak]

Nick Leaton wrote:

[...]
 
> From other posters, it seems that with life critical systems (avionics)
> that this is an important consideration. Am I the only one who finds
> this worrying, that systems you have to trust depend on some calculation
> as to how the program is going to run? What happens if a new compiler
> comes out that has a different optimisation technique?
> 

I always thought it would be nice to have postconditions of the form:

	ensure
		execution_time < 10 -- 10 milliseconds, let's say

So an exception would be raised if the routine took too long
to execute.

...richie

-- 
* richieb@XYZZYnetlabs.net       - at home |  Richie Bielak        *
* richieb@XYZZYcalfp.com         - at work |                       *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *
*        (Remove XYZZY  from my address before replying)           *

Re: Safety-critical development in Ada and Eiffel

[Karel Th�nissen]

Richie Bielak wrote:
> 
> Nick Leaton wrote:
> > From other posters, it seems that with life critical systems (avionics)
> > that this is an important consideration. Am I the only one who finds
> > this worrying, that systems you have to trust depend on some calculation
> > as to how the program is going to run? What happens if a new compiler
> > comes out that has a different optimisation technique?

> I always thought it would be nice to have postconditions of the form:
> 
>         ensure
>                 execution_time < 10 -- 10 milliseconds, let's say
> 
> So an exception would be raised if the routine took too long
> to execute.

I agree with aforementioned posters that timing dependency should be
made explicit in a formal way. In general it is not good engineering if
the correctness of a program depends in undocumented ways on the
compilers, its optimiser, the use of assertions in production code, the
clock frequency, etc.

I do agree with Ken and Robert that assertions do effect timing and
caching, so that assertions in production code may be impossible, and
that even testing with assertions included my give unpredicatable
results.

Richie's proposal has a nice property: if we include assertions during
testing, then if the additional coding affects the timing in an unwanted
way, then the timing assertion will fail and the problem is revealed. It
should be clear that in that case the system cannot be tested with
assertions switched on, and no logical assumptions as described by the
other assertions can be tested, but at least we know it, and we shall
have no suprises of unexplanable difference between testing (with
assertions) and production (without assertions).

However, it can very well be that this assertion cannot be used in the
production code for the very same reason that non-timing assertions
cannot be included.

I imagine that in avionics the code is made for a very specific hardware
configuration and with a very well defined set of development tools. 
So the dependency on compiler, hardware platform, etc., may not be a
problem there. This difference has other consequences, I understood from
Ken. A programmer for say an IS is not designing for a particular
platform, so assumptions can sometimes be necessary, and should then be
documented (possibly with assertions that are propagated up). However,
with avionics, everything is known in advance so there is no reason to
make assumptions about the platform and tools. The same thing applies to
the specifications of the other systems in the plain it is connected
with:  assumptions are never wanted and never necessary.

Groeten, Karel

Re: Safety-critical development in Ada and Eiffel

[Samuel Tardieu]

>>>>> "Richie" == Richie Bielak <richieb@XYZZYcalfp.com> writes:

Richie> I always thought it would be nice to have postconditions of
Richie> the form:

Richie>   ensure
Richie>     execution_time < 10 -- 10 milliseconds, let's say

Richie> So an exception would be raised if the routine took too long
Richie> to execute.

Well, I find the corresponding Ada code readable enough:

   select
      delay 0.010;               --  The 10ms you were talking about
      raise Timeout_Failure;     --  Raise an exception, or do anything else
                                 --  you need (use a fast version of
                                 --  your computation for example).
   then abort
      [...your code here...]     --  This piece of code will be
                                 --  aborted if it is not terminated within
                                 --  the 10ms you required above.
   end select;

And I don't think this should be a pre or post-condition, since it is
not something which will be checked at the beginning or at the end of
the job, but something which will indirectly interact with it (the job
will be potentially aborted).

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Safety-critical development in Ada and Eiffel

[Richie Bielak]

Samuel Tardieu wrote:

[...]
> 
> Well, I find the corresponding Ada code readable enough:
> 
>    select
>       delay 0.010;               --  The 10ms you were talking about
>       raise Timeout_Failure;     --  Raise an exception, or do anything else
>                                  --  you need (use a fast version of
>                                  --  your computation for example).
>    then abort
>       [...your code here...]     --  This piece of code will be
>                                  --  aborted if it is not terminated within
>                                  --  the 10ms you required above.
>    end select;
> 

That's neat. Except that a postcondition will be part of the contract
(i.e. specification) for the routine, so the caller will know what to 
expect. Your code is part of the implementation.

When you are using someone else's component you usually don't want
to look at the source.

...richie

-- 
* richieb@XYZZYnetlabs.net       - at home |  Richie Bielak        *
* richieb@XYZZYcalfp.com         - at work |                       *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *
*        (Remove XYZZY  from my address before replying)           *

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Richie Bielak wrote:

:Samuel Tardieu wrote:
:
:[...]
:> 
:> Well, I find the corresponding Ada code readable enough:
:> 
:>    select
:>       delay 0.010;               --  The 10ms you were talking about
:>       raise Timeout_Failure;     --  Raise an exception, or do anything else
:>                                  --  you need (use a fast version of
:>                                  --  your computation for example).
:>    then abort
:>       [...your code here...]     --  This piece of code will be
:>                                  --  aborted if it is not terminated within
:>                                  --  the 10ms you required above.
:>    end select;
:> 
:
:That's neat. Except that a postcondition will be part of the contract
:(i.e. specification) for the routine, so the caller will know what to 
:expect. Your code is part of the implementation.

I agree - it's belongs in a contract.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Richie Bielak wrote:
> 
> :Samuel Tardieu wrote:
> :
> :[...]
> :>
> :> Well, I find the corresponding Ada code readable enough:
> :>
> :>    select
> :>       delay 0.010;               --  The 10ms you were talking about
> :>       raise Timeout_Failure;     --  Raise an exception, or do anything else
> :>                                  --  you need (use a fast version of
> :>                                  --  your computation for example).
> :>    then abort
> :>       [...your code here...]     --  This piece of code will be
> :>                                  --  aborted if it is not terminated within
> :>                                  --  the 10ms you required above.
> :>    end select;
> :>
> :
> :That's neat. Except that a postcondition will be part of the contract
> :(i.e. specification) for the routine, so the caller will know what to
> :expect. Your code is part of the implementation.
> 
> I agree - it's belongs in a contract.

However, if this is an actor task, there is no contract (in any
language;
it would not be called explicitly by other parts of the application). If
it
is an agent or server task, the comment shown above would be associated
in
the task specification with the particular entry(ies) it affected.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:However, if this is an actor task, there is no contract (in any
:language;
:it would not be called explicitly by other parts of the application). If
:it
:is an agent or server task, the comment shown above would be associated
:in
:the task specification with the particular entry(ies) it affected.

In SCOOP, there is no concept of explicit active and passive objects. This is 
an atificial distinction which is neither necessary nor desirable (in an OO 
concurrency model). For the reasoning behind this, see "Object-oriented 
Software Construction" 2nd ed. - "Active objects" (P. 957).


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Karel Th�nissen]

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


Don Harrison wrote:
> 
> Richie Bielak wrote:
> 
> :Samuel Tardieu wrote:
> :
> :[...]
> :>
> :> Well, I find the corresponding Ada code readable enough:
> :>
> :>    select
> :>       delay 0.010;               --  The 10ms you were talking about
> :>       raise Timeout_Failure;     --  Raise an exception, or do anything else
> :>                                  --  you need (use a fast version of
> :>                                  --  your computation for example).
> :>    then abort
> :>       [...your code here...]     --  This piece of code will be
> :>                                  --  aborted if it is not terminated within
> :>                                  --  the 10ms you required above.
> :>    end select;
> :>
> :
> :That's neat. Except that a postcondition will be part of the contract
> :(i.e. specification) for the routine, so the caller will know what to
> :expect. Your code is part of the implementation.
> 
> I agree - it's belongs in a contract.

I think it only belongs in a contract if the timing of an method
invocation is concerned. However, this avenue of the thread was started
with the observation that a program should not depend on timing in an
unspecified/undocumented way.

The execution time of a method is one thing we need to time, and for
this the postcondition is the proper place.

However, there are a lot more things we may have to time, but that are
not directly linked to a particular (interface of) an object. For
example:

- the timing between two iterations of a loop
- the interval between two read outs of a memory mapped IO-port
- the timing of the execution of a method where the timing is critical
  on the part of the calling method and not of the called method itself
- timing of the interaction with the user (which is not a method for
  which one can specify a contract)
- timing of a number of instructions within a method
- etc.

So even though timing specifications with postconditions are useful, it
definitely is not sufficient for many HRT systems.

-- 
Groeten, Karel Th�nissen

-- my e-mail address is scrambled to confuse spammers
-- remove the confusion to obtain my true address

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

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


Karel Th�nissen wrote:

:Don Harrison wrote:

:> I agree - it's belongs in a contract.
:
:I think it only belongs in a contract if the timing of an method
:invocation is concerned. 

I don't agree. I'll outline what we *can* do and then address your specific 
examples.

1) We can time how long it takes for a method to execute using a postcondition:

     do_something (.., time_started: TIME) is
     do
       ...
     ensure (time_now - time_started <= allowable_duration) <<<<
     end

   (We agree on this). 

2) You can time the periodicity (time between drinks) of a call using a 
   precondition and an attribute of the enclosing class which records the time 
   last called:

     class SOME_CLASS 
     creation make
     feature
       do_something (..) is
       require 
         not called_before or else (time_now - time_last_called <= max_duration) <<<<
       do 
         time_last_called := time_now
         called_before := TRUE
         ...
       end

       make is
       do called_before := FALSE; end

     feature {NONE}
       time_last_called: TIME
       called_before: BOOLEAN
     end

3) You can time how long it takes to perform any action within the body of a 
   routine using a check-instruction and a local attribute recording the time
   the action started:

 a)  do_something (..) is
     local time_started: TIME
     do
       ...
       time_started := time_now
       ... -- timed action
       check (time_now - time_started < max_duration) end <<<<
       ...
     end

   Note that the check-instruction can appear anywhere so can be used to time
   a conditional branch or the average duration of a loop iteration:

 b)  time_started := time_now
     no_of_iterations := 0
     loop
       no_of_iterations := no_of_iterations + 1
       ...
     end
     check 
       (time_now - time_started) / no_of_iterations <= max_iteration_duration <<<<
     end

4) You can time the periodicity of calls made by a caller by using a 
   check-instruction and an attribute in the caller's class which records the 
   time the last call was made:

     class CALLING_CLASS 
     creation make
     feature
       ...
       !!a.make
       ...
       check 
         not called_before or else (time_now - time_of_last_call <= max_duration) <<<<
       end
       time_of_last_call := time_now
       a.do_something -- the call
       ...

       make is
       do called_before := FALSE; end

     feature {NONE}
       a: CALLED_CLASS
       time_of_last_call: TIME
       called_before: BOOLEAN
     end

5) You can ensure that no call made by a caller takes longer than a specified 
   duration by using an invariant and an attribute in the caller's class which 
   records the time a call was made:

     class CALLING_CLASS 
     feature
       ...
       !!a.make
       ...
       time_started := time_now
       a.do_something -- the call
       ...

     feature {NONE}
       a: CALLED_CLASS
       time_started: TIME

     invariant
       time_now - time_started <= max_duration <<<<
     end

6) You can ensure that no call made to a callee takes longer than a specified 
   duration by using an invariant and an attribute in the enclosing class which 
   records the time a call was made:

   (Details omitted - similar to 5) ).


:However, this avenue of the thread was started
:with the observation that a program should not depend on timing in an
:unspecified/undocumented way.

I agree. However, I think you'll agree on the basis of the examples above,
Eiffel assertions are a powerful means of, not only specifying and documenting 
timing dependencies, but validating at runtime that they're complied with.


:... there are a lot more things we may have to time, but that are
:not directly linked to a particular (interface of) an object. 

Correct - hence the need for check-instructions.


For example:
:
:- the timing between two iterations of a loop

  See 3) b) above.

:- the interval between two read outs of a memory mapped IO-port

  See 4) above.

:- the timing of the execution of a method where the timing is critical
:  on the part of the calling method and not of the called method itself

  See 4) above.

:- timing of the interaction with the user (which is not a method for
:  which one can specify a contract)

  Nor should we. No action (or not taken by a user) should ever be the basis 
  of an assertion. Such cases should be catered for by logic in the code 
  proper because are not indicative of errors in the software. A couple of 
  examples are a) user input validation and b) failure of a pilot to take 
  remedial action (or taking too much remedial action - Ken's example).

:- timing of a number of instructions within a method

  See 3) a) above.

 - timing of any call made by an object

  See 5) above.

 - timing of any call made to an object

  See 6) above.


:So even though timing specifications with postconditions are useful, it
:definitely is not sufficient for many HRT systems.

Agree, you also need preconditions, check-instructions and invariants.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

A point of clarification. I wrote:

:       !!a.make

As previously discussed, for realtime systems, the overhead of dynamic memory 
allocation can be removed by using a pre-allocated pool. For an HRT system, you 
can go a step further and remove the dynamic binding by freezing the routine 
used to create.


Note also that:

a) There is no equivalent for some of these timing assertions in Ada - in 
   particular, timing invariants.

b) For those that *are* emulatable in Ada, there is effectively *no extra* 
   runtime overhead from using assertions compared with the equivalent Ada.
   Where Ada offers a built-in mechanism, as for task time-outs, the overhead
   is hidden within the mechanism.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> :So even though timing specifications with postconditions are useful, it
> :definitely is not sufficient for many HRT systems.
> 
> Agree, you also need preconditions, check-instructions and invariants.

I responded elsewhere in this thread about difficulties in trying
to accurately measure thread timings at the object level, but let
me ask you this: Have you used the technique you describe in a
production hard real-time system? Or is this just a theoretical
discussion?

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:I responded elsewhere in this thread about difficulties in trying
:to accurately measure thread timings at the object level, 

As I've already explained, SCOOP *does* support thread-level timing. The fact 
this has not yet been tested in a realtime system doesn't invalidate any 
logical arguments made about it. 


Empirical evidence doesn't *prove* anything. It merely adds credibility to 
theoretical arguments. We believe that General Relativity is valid because 
empirical evidence backs it up. But arguments made about its effects 
(gravitational lenses, behaviour of clocks etc.) were valid even *before* they 
were observed empirically. Observing these phenomena merely helps us to 
*believe* that it's a valid model of reality.

A good example of how empirical observation proves nothing is found in the 
breakdown of Classical Physics. It was thought to be a valid physical model
because empirical observations backed it up. The fact that those observations 
didn't *prove* its validity can be seen by its failure to explain *other* 
subsequent empirical observations - namely those concerning objects with high 
relative velocities. These observations conflicted with the theoretical model 
and led to Einstein's formulation of Special Relativity. Even though Special 
Relativity has been observed to be a better physical model, it can never be 
*proven* by those observations.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ron Kohl]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :I responded elsewhere in this thread about difficulties in trying
> :to accurately measure thread timings at the object level,
> 
> As I've already explained, SCOOP *does* support thread-level timing. The fact
> this has not yet been tested in a realtime system doesn't invalidate any
> logical arguments made about it.
> 
  Ken's point is still valid.  If a 'system feature' (in this case
SCOOP's thread-level timing capability) is claimed to support hard
real-time and then this feature is implemented into a hard real-time
system and does not perform according to it's advertisement, then the
empirical data has provided a counter-example to the claims about that
feature.  The point being that empirical data can either provide
examples to support theoretical claims/conjectures or it can totally
invalidate such claims if it can produce a single, valid counter
example.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ron Kohl wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :I responded elsewhere in this thread about difficulties in trying
:> :to accurately measure thread timings at the object level,
:> 
:> As I've already explained, SCOOP *does* support thread-level timing. The fact
:> this has not yet been tested in a realtime system doesn't invalidate any
:> logical arguments made about it.
:> 
:  Ken's point is still valid.  

Yes, sorry - I was a bit blunt. I agree with Ken's statement. Unless an 
object corresponds directly with a thread, it isn't possible to measure thread 
timings at the object level.
 
:If a 'system feature' (in this case
:SCOOP's thread-level timing capability) is claimed to support hard
:real-time and then this feature is implemented into a hard real-time
:system and does not perform according to it's advertisement, then the
:empirical data has provided a counter-example to the claims about that
:feature.  The point being that empirical data can either provide
:examples to support theoretical claims/conjectures or it can totally
:invalidate such claims if it can produce a single, valid counter
:example.

Absolutely! Empirical data can *disprove* a theory but not prove it. A single 
contrary observation is sufficient to disprove a theory whereas any number of
supportive observations cannot prove it.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Let's try this again..

Ron Kohl wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :I responded elsewhere in this thread about difficulties in trying
:> :to accurately measure thread timings at the object level,
:> 
:> As I've already explained, SCOOP *does* support thread-level timing. The fact
:> this has not yet been tested in a realtime system doesn't invalidate any
:> logical arguments made about it.
:> 
:  Ken's point is still valid.  

Yes, sorry - I was a bit blunt. I agree with Ken's statement. Unless an 
object corresponds directly with a thread, it isn't possible to measure thread 
timings at the object level.
 
:If a 'system feature' (in this case
:SCOOP's thread-level timing capability) is claimed to support hard
:real-time and then this feature is implemented into a hard real-time
:system and does not perform according to it's advertisement, then the
:empirical data has provided a counter-example to the claims about that
:feature.  The point being that empirical data can either provide
:examples to support theoretical claims/conjectures or it can totally
:invalidate such claims if it can produce a single, valid counter
:example.

Absolutely! Empirical data can *disprove* a theory but not prove it. A single 
correctly-interpreted contrary observation is sufficient to disprove a theory 
whereas any number of supportive observations cannot prove it. Obviously, any 
number of incorrectly-interpreted contrary observations can never disprove a 
theory.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au





-- 
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :I responded elsewhere in this thread about difficulties in trying
> :to accurately measure thread timings at the object level,
> 
> As I've already explained, SCOOP *does* support thread-level timing. The fact
> this has not yet been tested in a realtime system doesn't invalidate any
> logical arguments made about it.

No, but then again, saying "X *does* support thread-level timing" isn't
a
logical argument, it's an assertion. And assertions, in the absence of
any experience (either general experience from the author, or specific
experience with X in a real system) are not particularly useful.

Futhermore, here is a counter-argument to writing timing assertions
at the object level:

Using letters to denote objects, let's build a thread. The notation
x{object}y means that the object is executed between x and y times.
The arrows indicate that one object is executed before another object
in the sequence. (For simplicity, we'll neglect objects calling
objects).

Thread: A -> B -> 1{C}4 -> D

The max time for this thread is: A + B + 4*C + D, right?

No!

It also includes:
 1. the entry/exit code for each object (4 times that, for C),
 2. the time to start and stop the thread itself
 3. Any time between object invocations "stolen" by other threads.

If you start the measurement before the call to A, and stop it
after the call to D, you only have to worry about #2 above
(which is usually fixed). If you do the measurement at the object
level, all three will skew your results. What's worse, #1's
effect increases with the number of objects/calls to objects in
the thread. As a result, it's not a particularly useful approach
when dealing with thread timings (as opposed to object timings).
(This IS backed up by empirical evidence, by the way!)

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :I responded elsewhere in this thread about difficulties in trying
:> :to accurately measure thread timings at the object level,
:> 
:> As I've already explained, SCOOP *does* support thread-level timing. The fact
:> this has not yet been tested in a realtime system doesn't invalidate any
:> logical arguments made about it.
:
:No, but then again, saying "X *does* support thread-level timing" isn't
:a
:logical argument, it's an assertion. And assertions, in the absence of
:any experience (either general experience from the author, or specific
:experience with X in a real system) are not particularly useful.

Not at all. It's more than an assertion - it's a fact. You may choose to 
disbelieve that fact for whatever reason but that doesn't alter its truth.


:Futhermore, here is a counter-argument to writing timing assertions
:at the object level:
:
:Using letters to denote objects, let's build a thread. The notation
:x{object}y means that the object is executed between x and y times.
:The arrows indicate that one object is executed before another object
:in the sequence. (For simplicity, we'll neglect objects calling
:objects).
:
:Thread: A -> B -> 1{C}4 -> D
:
:The max time for this thread is: A + B + 4*C + D, right?
:
:No!
:
:It also includes:
: 1. the entry/exit code for each object (4 times that, for C),
: 2. the time to start and stop the thread itself
: 3. Any time between object invocations "stolen" by other threads.

3) doesn't apply to SCOOP because all objects are locked.
1) and 2) can be included.

:If you start the measurement before the call to A, and stop it
:after the call to D, you only have to worry about #2 above
:(which is usually fixed). If you do the measurement at the object
:level, all three will skew your results. 

Not true. If you really want to get a clue on this, I suggest you get hold 
of OOSC-2 and read the chapter on concurrency. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> Ken Garlington wrote:
> :>
> :> :I responded elsewhere in this thread about difficulties in trying
> :> :to accurately measure thread timings at the object level,
> :>
> :> As I've already explained, SCOOP *does* support thread-level timing. The fact
> :> this has not yet been tested in a realtime system doesn't invalidate any
> :> logical arguments made about it.
> :
> :No, but then again, saying "X *does* support thread-level timing" isn't
> :a
> :logical argument, it's an assertion. And assertions, in the absence of
> :any experience (either general experience from the author, or specific
> :experience with X in a real system) are not particularly useful.
> 
> Not at all. It's more than an assertion - it's a fact. You may choose to
> disbelieve that fact for whatever reason but that doesn't alter its truth.

I hadn't realized we were dealing in terms of a "higher truth" that
doesn't
require argument or evidence. I never argue religion, so we'll have to
just
disagree on this one.

> 
> :Futhermore, here is a counter-argument to writing timing assertions
> :at the object level:
> :
> :Using letters to denote objects, let's build a thread. The notation
> :x{object}y means that the object is executed between x and y times.
> :The arrows indicate that one object is executed before another object
> :in the sequence. (For simplicity, we'll neglect objects calling
> :objects).
> :
> :Thread: A -> B -> 1{C}4 -> D
> :
> :The max time for this thread is: A + B + 4*C + D, right?
> :
> :No!
> :
> :It also includes:
> : 1. the entry/exit code for each object (4 times that, for C),
> : 2. the time to start and stop the thread itself
> : 3. Any time between object invocations "stolen" by other threads.
> 
> 3) doesn't apply to SCOOP because all objects are locked.

(3) represents the time _in between_ object invocations. If you are
saying that a thread (a series of object invocations) cannot be
interrupted at _any point_, then that pretty much eliminates
concurrency, doesn't it?

I have a feeling that we're just not communicating on this issue. My
experience is in real-time systems, and I think I'm just not
properly conveying the issues involved in developing those systems.

> 1) and 2) can be included.
> 
> :If you start the measurement before the call to A, and stop it
> :after the call to D, you only have to worry about #2 above
> :(which is usually fixed). If you do the measurement at the object
> :level, all three will skew your results.
> 
> Not true. If you really want to get a clue on this, I suggest you get hold
> of OOSC-2 and read the chapter on concurrency.

Once I see an appeal to authority, I pretty much have to assume the
discussion is over. We'll just have to agree to disagree on this as
well.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken asked for evidence that SCOOP supports thread-level timing.

Ken Garlington wrote:

:I hadn't realized we were dealing in terms of a "higher truth" that
:doesn't require argument or evidence. 

The evidence is in OOSC-2. I would leave it at that but I'll give an example 
because I may have been responsible for confusing you. :(  Sorry if that's the
case.

I might have said that locking in SCOOP occurs at the object level. Anyone 
familiar with protected types would immediately assume this means objects are 
locked one-at-a-time (whenever they're called). SCOOP is fundamentally different 
in that groups of objects are locked together. As I'll explain later, this 
is an important distinction.

Why are they collectively locked?
Answer: So that processing can be performed under known conditions without 
  interference from other threads (helping to avoid race conditions). Also,
  so that we know up-front that we have all the resources we needed (helping
  to avoid deadlock).

When are they collectively locked? 
Answer: When they're supplied as parameters to an operation.

What if they're not supplied as parameters?
Answer: They always *are* (in the case of concurrent (separate) objects. 
  In the case of sequential (non-separate) object, we don't care because 
  we know they're local to the calling thread.

See the example below..

:> :Futhermore, here is a counter-argument to writing timing assertions
:> :at the object level:
:> :
:> :Using letters to denote objects, let's build a thread. The notation
:> :x{object}y means that the object is executed between x and y times.
:> :The arrows indicate that one object is executed before another object
:> :in the sequence. (For simplicity, we'll neglect objects calling
:> :objects).
:> :
:> :Thread: A -> B -> 1{C}4 -> D
:> :
:> :The max time for this thread is: A + B + 4*C + D, right?
:> :
:> :No!
:> :
:> :It also includes:
:> : 1. the entry/exit code for each object (4 times that, for C),
:> : 2. the time to start and stop the thread itself
:> : 3. Any time between object invocations "stolen" by other threads.
:> 
:> 3) doesn't apply to SCOOP because all objects are locked.
:
:(3) represents the time _in between_ object invocations. 

You might code your example in pseudo-SCOOP:

Assuming separate (allocated to different threads) entities

  my_p: separate P
  my_q: separate Q
  my_r: separate R
  my_s: separate S

and operation

  do_something (p: separate P; q: separate Q; r: separate R; s: separate S) is
  local
    start_time: time
    duration: ...
  do
    start_time := time_now
    p.a
    q.b
    loop (4 times)
      r.c
    end
    s.d
    duration := time_now - start_time
    ...
  end

the call

  do_something (my_p, my_q, my_r, my_s)

will do the required actions and measure the elapsed time.

Note that all four objects are locked for the block between "do" and "end".
This means that there is no intervening time between calls to them and there
is no opportunity for any other threads to jump in and make a mess of things.

Note that this offers more protection than Ada protected objects which are 
only locked on single object basis. As you will see later, this also removes 
the need for a "requeue" statement.


:If you are saying that a thread (a series of object invocations) cannot be
:interrupted at _any point_, then that pretty much eliminates
:concurrency, doesn't it?

No, it just means it's more controlled (and safer). There is a complementary 
library mechanism called "express messages" which allows pre-emption of threads.


:I have a feeling that we're just not communicating on this issue. 

True.

:My experience is in real-time systems, and I think I'm just not
:properly conveying the issues involved in developing those systems.

Likewise.

:> :If you start the measurement before the call to A, and stop it
:> :after the call to D, you only have to worry about #2 above
:> :(which is usually fixed). If you do the measurement at the object
:> :level, all three will skew your results.
:> 
:> Not true. If you really want to get a clue on this, I suggest you get hold
:> of OOSC-2 and read the chapter on concurrency.

Sorry, Ken. I was a bit rude here.



:Ken Garlington wrote (about Ada protected types):

::can requeue requests, 

I wrote:

:IMO, the situations in which you would use "requeue" are better handled by 
:designing differently - perhaps by using an additional class. 

Sorry, this is wrong. The problem in Ada which "requeue" is designed to deal 
with doesn't arise in SCOOP because successive calls to the same separate 
object are atomic. That is, the object doesn't get unlocked between calls.
For example,

  do_something (a: separate A) is
  do
    a.do_x
    a.do_y
  end

does exactly what we expect. There is no need for do_x to "requeue" do_y.
IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely 
locking at the object level. Further, it's a *deficient* workaround because 
supplier objects are forced to do things (do_y) that should be the 
responsibility of clients (do_something).

:If anything, "requeue" probably encourages poor design.

.. as I've just explained.



Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken asked for evidence that SCOOP supports thread-level timing.
> 
> Ken Garlington wrote:
> 
> Why are they collectively locked?
> Answer: So that processing can be performed under known conditions without
>   interference from other threads (helping to avoid race conditions). Also,
>   so that we know up-front that we have all the resources we needed (helping
>   to avoid deadlock).

What happens if the resource is unavailable (already locked by a
lower-priority
thread, for example)?

It seems to me that, locking _all_ objects involved in an operation
(without
regard to whether they guard a sensitive resource, such as a data store
that
can be written by multiple threads) means that the latencies associated
with
the threads goes up dramatically, particularly if the locking is
transitive.
Priority inversion would also seem to be much more likely.

Ada has a different approach. Consider a fairly simple case of a value
that
is read by some tasks, written by others. Clearly, if a thread is
writing
a value, it should start and complete that operation before any other
access to that resource. Similarly, any attempt to read the resource
should
start and complete before any write to the resource begins. However,
a read by a low-priority task can be suspended to permit a
higher-priority
task to read the same resouirce (assuming no side-effects of the read).
As I understand it, you would prohibit this benign "interference." Thus,
the high-priority task (which may run much more frequently than the
low-priority task) is unnecessarily delayed, potentially causing it
to meet it's deadline.

You claimed that the compiler could optimize the timing properties of
the system; I would be interested in seeing such a compiler. Today,
there are tools that can help the designer analyze the system; I have
yet to see one that could do a real-time architecture design
autonomously!

> 
> When are they collectively locked?
> Answer: When they're supplied as parameters to an operation.
> 
> What if they're not supplied as parameters?
> Answer: They always *are* (in the case of concurrent (separate) objects.
>   In the case of sequential (non-separate) object, we don't care because
>   we know they're local to the calling thread.
> 
> See the example below..
> 
> :> :Futhermore, here is a counter-argument to writing timing assertions
> :> :at the object level:
> :> :
> :> :Using letters to denote objects, let's build a thread. The notation
> :> :x{object}y means that the object is executed between x and y times.
> :> :The arrows indicate that one object is executed before another object
> :> :in the sequence. (For simplicity, we'll neglect objects calling
> :> :objects).
> :> :
> :> :Thread: A -> B -> 1{C}4 -> D
> :> :
> :> :The max time for this thread is: A + B + 4*C + D, right?
> :> :
> :> :No!
> :> :
> :> :It also includes:
> :> : 1. the entry/exit code for each object (4 times that, for C),
> :> : 2. the time to start and stop the thread itself
> :> : 3. Any time between object invocations "stolen" by other threads.
> :>
> :> 3) doesn't apply to SCOOP because all objects are locked.
> :
> :(3) represents the time _in between_ object invocations.
> 
> You might code your example in pseudo-SCOOP:
> 
> Assuming separate (allocated to different threads) entities
> 
>   my_p: separate P
>   my_q: separate Q
>   my_r: separate R
>   my_s: separate S
> 
> and operation
> 
>   do_something (p: separate P; q: separate Q; r: separate R; s: separate S) is
>   local
>     start_time: time
>     duration: ...
>   do
>     start_time := time_now
>     p.a
>     q.b
>     loop (4 times)
>       r.c
>     end
>     s.d
>     duration := time_now - start_time
>     ...
>   end
> 
> the call
> 
>   do_something (my_p, my_q, my_r, my_s)

It wouldn't catch the extry/exit time of do_something, but
that's not a big deal. I see you've missed the original
part of the thread. The poster suggested writing 
assertions (post-conditions) on P, Q, R, and S as the
way to do this, which (as I said) won't work effectively.
Your approach is at the thread level, not the object
level, which is the way I would have done it as well.
So, in fact, we agree that the original post is in
error (I assume).

> 
> will do the required actions and measure the elapsed time.
> 
> Note that all four objects are locked for the block between "do" and "end".
> This means that there is no intervening time between calls to them and there
> is no opportunity for any other threads to jump in and make a mess of things.

Just out of curiosity, can the "local" section make reference to these
objects?

Also, how is "do_something" attached to a hardware event? What are the
implications
of doing so?

> Note that this offers more protection than Ada protected objects which are
> only locked on single object basis. As you will see later, this also removes
> the need for a "requeue" statement.

True. However, you pay a pretty terrible price for this protection, as
far as I can tell. I can see several systems which literally could not
be implemented under these rules.

> 
> :If you are saying that a thread (a series of object invocations) cannot be
> :interrupted at _any point_, then that pretty much eliminates
> :concurrency, doesn't it?
> 
> No, it just means it's more controlled (and safer). There is a complementary
> library mechanism called "express messages" which allows pre-emption of threads.

Perhaps this "express messages" is the backdoor which I have to believe
a real system would need.

Correct me if I'm wrong, but no other thread can run while do_something
is
executing? Or are you saying it can be interrupted, just that no other
thread
can access the objects referenced in the parameter list (or any objects
referenced in _their_ parameter lists? )?

> 
> :I have a feeling that we're just not communicating on this issue.
> 
> True.
> 
> :My experience is in real-time systems, and I think I'm just not
> :properly conveying the issues involved in developing those systems.
> 
> Likewise.
> 
> :> :If you start the measurement before the call to A, and stop it
> :> :after the call to D, you only have to worry about #2 above
> :> :(which is usually fixed). If you do the measurement at the object
> :> :level, all three will skew your results.
> :>
> :> Not true. If you really want to get a clue on this, I suggest you get hold
> :> of OOSC-2 and read the chapter on concurrency.
> 
> Sorry, Ken. I was a bit rude here.

A little confusing, too, since you _do_ in fact start the measurement
befoire the call to A (or P.A) and after the last call in your example!

> 
> :Ken Garlington wrote (about Ada protected types):
> 
> ::can requeue requests,
> 
> I wrote:
> 
> :IMO, the situations in which you would use "requeue" are better handled by
> :designing differently - perhaps by using an additional class.
> 
> Sorry, this is wrong. The problem in Ada which "requeue" is designed to deal
> with doesn't arise in SCOOP because successive calls to the same separate
> object are atomic. That is, the object doesn't get unlocked between calls.

True. However, the question still stands: What happens if a thread
attempts to
access a locked (or otherwise unavailable) resource? I can use requeue
in
these situations; what do you do?

> For example,
> 
>   do_something (a: separate A) is
>   do
>     a.do_x
>     a.do_y
>   end
> 
> does exactly what we expect. There is no need for do_x to "requeue" do_y.

That's not how requeue works, as I understand it. The issue is more: you
attempt to do a.do_x, and someone else has already seized the resource,
or
there is some other time-based reason why a.do_x is unavailable.

> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
> locking at the object level. Further, it's a *deficient* workaround because
> supplier objects are forced to do things (do_y) that should be the
> responsibility of clients (do_something).

It depends. A "requeue" may be needed because of the state of the
object, and may not be related to the state of do_something.

> :If anything, "requeue" probably encourages poor design.
> 
> .. as I've just explained.

Sorry, don't see it.

I think you would need to apply SCOOP to some fairly complex
real-time systems to see the problems I'm discussing. So long
as all the objects have short lifetimes, and no priority issues
are around, I would assume it seems to work fine for simple systems.


> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken asked for evidence that SCOOP supports thread-level timing.
:> 
:> Ken Garlington wrote:
:> 
:> Why are they collectively locked?
:> Answer: So that processing can be performed under known conditions without
:>   interference from other threads (helping to avoid race conditions). Also,
:>   so that we know up-front that we have all the resources we needed (helping
:>   to avoid deadlock).
:
:What happens if the resource is unavailable (already locked by a
:lower-priority thread, for example)?

The caller blocks until the resource is available. There are actually no 
lower-priority threads - all threads are the same priority and their requests 
are queued impartially. Where timing is not an issue this gives you what you 
want because you get a kind of statistical "prioritisation". What I mean is 
that threads will automatically get serviced by a supplier object in proportion 
to the number of calls they make to it. In this situation, you don't care 
which threads are serviced first. You only care about whether there is enough
processing capacity and if there isn't enough, you have a problem regardless 
of what queueing scheme is used.

Where timing *is* an issue, you use express messages. This mechanism allows 
threads to dynamically change their "priority" relative to other threads.
This mechanism should only be used where it's critical to transfer control.
There are two parties involved - the holder and the challenger - and they "duel"
for control of a resource. Duels either result in a transfer of control or 
the challenger waiting till the holder finishes with the resource.

Threads change their relative "priority" through calls to library routines:

  Holder: 
    - retain (the default) makes the holder resist a challenge.
    - yield makes the holder willing to yield.

  Challenger: 
    - wait_turn (the default) makes the challenger willing to wait.
    - demand makes the challenger mount a challenge and commit suicide if resisted.
    - insist makes the challenger mount a challenge but wait if resisted.

The outcome of duels is summarised in the following table:

                                              Challenger
                   -----------------------------------------------------------------
                  |    [wait_turn]              demand               insist
        ----------|-----------------------------------------------------------------
Holder | [retain] | [Challenger waits]  Exception in Challenger  Challenger waits
       | yield    | Challenger waits    Exception in holder      Exception in holder


Notes:

1) Defaults are exclosed in square brackets. Note the default behaviour of 
   the challenger waiting.

2) This simple dual priority scheme can be embellished to offer multiple 
   relative "priorities".

Examples of use:

  - A thread which absolutely must execute (possibly driven by a timer) can
    issue a challenge for a resource.
  - A thread performing a long IO operation can offer to yield to a more 
    critical thread.


:It seems to me that, locking _all_ objects involved in an operation (without
:regard to whether they guard a sensitive resource, such as a data store
:that can be written by multiple threads) means that the latencies associated
:with the threads goes up dramatically, particularly if the locking is
:transitive.

I was also concerned about this issue initially but came to the conclusion 
that objects would be locked for just as long as they (safely) need to be.
Where it's important to release a frequently used shared resource quickly, 
various design strategies can be applied to minimise locking.
 
:Priority inversion would also seem to be much more likely.

Can you explain what you mean by this?


:Ada has a different approach. Consider a fairly simple case of a value that
:is read by some tasks, written by others. Clearly, if a thread is writing
:a value, it should start and complete that operation before any other
:access to that resource. Similarly, any attempt to read the resource should
:start and complete before any write to the resource begins. 

Agree.

:However,
:a read by a low-priority task can be suspended to permit a higher-priority
:task to read the same resouirce (assuming no side-effects of the read).
:As I understand it, you would prohibit this benign "interference." Thus,
:the high-priority task (which may run much more frequently than the
:low-priority task) is unnecessarily delayed, potentially causing it
:to meet it's deadline.

No. In this case, the reads could occur concurrently (due to optimisations).

:You claimed that the compiler could optimize the timing properties of
:the system; I would be interested in seeing such a compiler..

I don't think it would be too hard. The compiler just has to verify that 
queries (functions) are truly benign and implement two types of locks 
- read and write. This is yet another reason to strictly enforce side-effect-
free functions.


:It wouldn't catch the extry/exit time of do_something, but
:that's not a big deal. 

At a higher level call, perhaps..

:I see you've missed the original
:part of the thread. The poster suggested writing 
:assertions (post-conditions) on P, Q, R, and S as the
:way to do this, which (as I said) won't work effectively.
:Your approach is at the thread level, not the object
:level, which is the way I would have done it as well.
:So, in fact, we agree that the original post is in
:error (I assume).

Probably - can't remember what was said.


:> will do the required actions and measure the elapsed time.
:> 
:> Note that all four objects are locked for the block between "do" and "end".
:> This means that there is no intervening time between calls to them and there
:> is no opportunity for any other threads to jump in and make a mess of things.
:
:Just out of curiosity, can the "local" section make reference to these
:objects?

Can't recall (and couldn't see from a quick glance at OOSC-2) but do know 
you would be limited in what you could do. For example, a local separate 
object couldn't be the target of a call. Why do you ask? 


:Also, how is "do_something" attached to a hardware event? 

Not sure, but probably via a call to a library routine.


:> Note that this offers more protection than Ada protected objects which are
:> only locked on single object basis. As you will see later, this also removes
:> the need for a "requeue" statement.
:
:True. However, you pay a pretty terrible price for this protection, as
:far as I can tell. I can see several systems which literally could not
:be implemented under these rules.

They would likely be designed differently, though, by paying more attention
to locking issues. 


:> :If you are saying that a thread (a series of object invocations) cannot be
:> :interrupted at _any point_, then that pretty much eliminates
:> :concurrency, doesn't it?
:> 
:> No, it just means it's more controlled (and safer). There is a complementary
:> library mechanism called "express messages" which allows pre-emption of threads.
:
:Perhaps this "express messages" is the backdoor which I have to believe
:a real system would need.

Correct.

:Correct me if I'm wrong, but no other thread can run while do_something is
:executing? 

On a single processor, yes. On a multiple processor, no.

:Or are you saying it can be interrupted, just that no other thread
:can access the objects referenced in the parameter list (or any objects
:referenced in _their_ parameter lists? )?

Correct.


Have run out of time. Will respond to the rest tomorrow.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

I wrote:

::>... There is a complementary
::> library mechanism called "express messages" which allows pre-emption of threads.
::
::Perhaps this "express messages" is the backdoor which I have to believe
::a real system would need.
:
:Correct.
:
::Correct me if I'm wrong, but no other thread can run while do_something is
::executing? 
:
:On a single processor, yes. On a multiple processor, no.
:
::Or are you saying it can be interrupted, just that no other thread
::can access the objects referenced in the parameter list (or any objects
::referenced in _their_ parameter lists? )?
:
:Correct.

I need to clarify this. Unless the default duelling status of the objects 
involved changes as a result of calls to class CONCURRENCY (retain, yield,
wait_turn, demand, insist), a thread will not be interrupted and (in theory)
no other thread can access the objects in the parameter list of the operation
being called.


On protected types:

Ken Garlington wrote:
 
:> ::can requeue requests,
:> 
:> I wrote:
:> ... The problem in Ada which "requeue" is designed to deal
:> with doesn't arise in SCOOP because successive calls to the same separate
:> object are atomic. That is, the object doesn't get unlocked between calls.

This means that, under SCOOP, locking is operation-based rather than 
object-based. Protected types, in contrast, have object-based locking. This 
means that a calling thread issuing two consecutive calls to a protected 
object cannot be guaranteed that no other thread will update the protected 
object between the calls. 

If I understand correctly, requeues are a means of getting around this problem
by allowing the callee (the protected object)  to issue extra calls (on behalf 
of the calling thread) while it is still locked. I think this scheme is 
deficient for a couple of reasons:

1) It doesn't fix the underlying problem - the lack of atomicity inherent in
   object-based locking. As such, it's a workaround rather than a mechanism 
   that should exist in its own right.

2) It's undesirable from a modelling perspective:

   a) It's incorrect for a caller to be making calls to itself *on behalf 
      of the caller*.

   b) It introduces undesirable interdependencies between entries - for example,
      the blocking abstraction on P. 9-16 of the Ada95 Rationale. 

      Under SCOOP, inherently autonomous operations remain autonomous in 
      accordance with sound design (read "OO principles").

One thing I'm curious about is where the requeued call gets placed on the 
entry queue. I guess it must be placed on the head, rather than the tail, 
for this to work. Is that the case?


:True. However, the question still stands: What happens if a thread attempts to
:access a locked (or otherwise unavailable) resource? 

It gets queued in the queue of callers for that object (one queue per object).
Out of interest, is there one queue per protected object or one queue per entry?

:I can use requeue in these situations; 

Sorry, don't see what you mean. As far as I can see, requeue is used by the
thread that has control of the protected object, not a thread that's trying 
to get hold of it.

what do you do?

The controlling thread doesn't have to worry about it because it retains control
of the separate object even when individual calls to it have completed. The 
separate object only gets unlocked when the calling operation itself completes.


:> For example,
:> 
:>   do_something (a: separate A) is
:>   do
:>     a.do_x
:>     a.do_y
:>   end
:> 
:> does exactly what we expect. There is no need for do_x to "requeue" do_y.
:
:That's not how requeue works, as I understand it. The issue is more: you
:attempt to do a.do_x, and someone else has already seized the resource, or
:there is some other time-based reason why a.do_x is unavailable.

What you've described sounds more like the mechanism for queuing calls. Requeue 
is something different, as I understand it.


:> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
:> locking at the object level. Further, it's a *deficient* workaround because
:> supplier objects are forced to do things (do_y) that should be the
:> responsibility of clients (do_something).
:
:It depends. A "requeue" may be needed because of the state of the
:object, and may not be related to the state of do_something.

In that case, do_somthing need only test the state of the separate object 
and take whatever action is necessary - calling another operation in it,
for example.

   do_something (a: separate A) is
   do
     a.do_x
     if a.some_condition then
       a.do_y
     end
   end


:> :If anything, "requeue" probably encourages poor design.
:> 
:> .. as I've just explained.
:
:Sorry, don't see it.
:
:I think you would need to apply SCOOP to some fairly complex
:real-time systems to see the problems I'm discussing. 

I think I've addressed all the issues you were concerned about. From a 
theoretical standpoint, SCOOP should work and should be scaleable. Of course, 
it will be reassuring to have the theory vindicated by seeing it applied 
successfully to a significant-sized project.

:So long as all the objects have short lifetimes, and no priority issues
:are around, I would assume it seems to work fine for simple systems.

I think it will be fine for *any* size system. Obviously, it will require a 
different design approach to that used with Ada because of some fundamental 
differences. These differences make it both more restrictive (in reliability-
enhancing ways) and less restrictive (in ways that enhance reuse and modelling 
integrity).


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> ::Or are you saying it can be interrupted, just that no other thread
> ::can access the objects referenced in the parameter list (or any objects
> ::referenced in _their_ parameter lists? )?
> :
> :Correct.
> 
> I need to clarify this. Unless the default duelling status of the objects
> involved changes as a result of calls to class CONCURRENCY (retain, yield,
> wait_turn, demand, insist), a thread will not be interrupted and (in theory)
> no other thread can access the objects in the parameter list of the operation
> being called.

This makes no sense, given your last post. If no other thread can
interrupt,
how is a duel initiated?

> 
> On protected types:
> 
> Ken Garlington wrote:
> 
> :> ::can requeue requests,
> :>
> :> I wrote:
> :> ... The problem in Ada which "requeue" is designed to deal
> :> with doesn't arise in SCOOP because successive calls to the same separate
> :> object are atomic. That is, the object doesn't get unlocked between calls.
> 
> This means that, under SCOOP, locking is operation-based rather than
> object-based. Protected types, in contrast, have object-based locking. This
> means that a calling thread issuing two consecutive calls to a protected
> object cannot be guaranteed that no other thread will update the protected
> object between the calls.
> 
> If I understand correctly, requeues are a means of getting around this problem
> by allowing the callee (the protected object)  to issue extra calls (on behalf
> of the calling thread) while it is still locked. I think this scheme is
> deficient for a couple of reasons:
> 
> 1) It doesn't fix the underlying problem - the lack of atomicity inherent in
>    object-based locking. As such, it's a workaround rather than a mechanism
>    that should exist in its own right.
> 
> 2) It's undesirable from a modelling perspective:
> 
>    a) It's incorrect for a caller to be making calls to itself *on behalf
>       of the caller*.
> 
>    b) It introduces undesirable interdependencies between entries - for example,
>       the blocking abstraction on P. 9-16 of the Ada95 Rationale.
> 
>       Under SCOOP, inherently autonomous operations remain autonomous in
>       accordance with sound design (read "OO principles").

Actually, it promotes OO principles, since the reasons for the requeue
are
often due to the internal implementation of the protected object, and
thus
can be hidden from the caller.

> One thing I'm curious about is where the requeued call gets placed on the
> entry queue. I guess it must be placed on the head, rather than the tail,
> for this to work. Is that the case?

All queues are generally FIFO. Note that the requeued call doesn't have
to
be on the _same_ queue.

"The entry queuing policy controls selection among queued calls both
for task and protected entry queues. The default entry queuing policy
is to select calls on a given entry queue in order of arrival. If calls
from two or more queues are simultaneously eligible for selection, the
default entry queuing policy does not specify which queue is serviced
first.
Other entry queuing policies can be specified by pragmas (see D.4)."

> 
> :True. However, the question still stands: What happens if a thread attempts to
> :access a locked (or otherwise unavailable) resource?
> 
> It gets queued in the queue of callers for that object (one queue per object).
> Out of interest, is there one queue per protected object or one queue per entry?

One per entry (which is what you want, if you want the timing behavior
to be
different based on the operation/entry called).

> 
> :I can use requeue in these situations;
> 
> Sorry, don't see what you mean. As far as I can see, requeue is used by the
> thread that has control of the protected object, not a thread that's trying
> to get hold of it.

No, any entry can be requeued. Furthermore, it's not up to the caller or
callee,
it's up to the protected object:

"A requeue_statement can be used to complete an accept_statement or
entry_body,
while redirecting the corresponding entry call to a new (or the same)
entry
queue. Such a requeue can be performed with or without allowing an
intermediate cancellation of the call, due to an abort or the expiration
of a delay."

"A requeue_statement shall be within a callable construct that is either
an
entry_body or an accept_statement, and this construct shall be the
innermost
enclosing body or callable construct."

Again, the internal timing/sequence requirements can be hidden within
the
object. It makes the decisions based on its internal state, not the
caller
or callee. This is what you want a server task to be able to do, of
course.

> 
> what do you do?
> 
> The controlling thread doesn't have to worry about it because it retains control
> of the separate object even when individual calls to it have completed. The
> separate object only gets unlocked when the calling operation itself completes.
> 
> :> For example,
> :>
> :>   do_something (a: separate A) is
> :>   do
> :>     a.do_x
> :>     a.do_y
> :>   end
> :>
> :> does exactly what we expect. There is no need for do_x to "requeue" do_y.
> :
> :That's not how requeue works, as I understand it. The issue is more: you
> :attempt to do a.do_x, and someone else has already seized the resource, or
> :there is some other time-based reason why a.do_x is unavailable.
> 
> What you've described sounds more like the mechanism for queuing calls. Requeue
> is something different, as I understand it.

Well, I'm new to Ada 95, so you may be right. However, take a peek at

  http://www.adahome.com/rm95/rm9x-09-05-04.html#1

or the quotes from it above.

> 
> :> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
> :> locking at the object level. Further, it's a *deficient* workaround because
> :> supplier objects are forced to do things (do_y) that should be the
> :> responsibility of clients (do_something).
> :
> :It depends. A "requeue" may be needed because of the state of the
> :object, and may not be related to the state of do_something.
> 
> In that case, do_somthing need only test the state of the separate object
> and take whatever action is necessary - calling another operation in it,
> for example.

It's that "test the state" that bothers me. Why do I need to expose the
internal state of the object? Seems somewhat non-OO to me. It also means
that the object can't enforce it's own timing policies -- it has to
trust
the caller to do the right thing.

> 
>    do_something (a: separate A) is
>    do
>      a.do_x
>      if a.some_condition then
>        a.do_y
>      end
>    end
> 
> :> :If anything, "requeue" probably encourages poor design.
> :>
> :> .. as I've just explained.
> :
> :Sorry, don't see it.
> :
> :I think you would need to apply SCOOP to some fairly complex
> :real-time systems to see the problems I'm discussing.
> 
> I think I've addressed all the issues you were concerned about. From a
> theoretical standpoint, SCOOP should work and should be scaleable. Of course,
> it will be reassuring to have the theory vindicated by seeing it applied
> successfully to a significant-sized project.

Agreed. I think I would be much more convinced once this optimizing
compiler
hits the streets, and people start looking at the effort to define all
of
the dueling relationships.

> 
> :So long as all the objects have short lifetimes, and no priority issues
> :are around, I would assume it seems to work fine for simple systems.
> 
> I think it will be fine for *any* size system. Obviously, it will require a
> different design approach to that used with Ada because of some fundamental
> differences. These differences make it both more restrictive (in reliability-
> enhancing ways) and less restrictive (in ways that enhance reuse and modelling
> integrity).

The design approaches I describe didn't come with Ada. They've been
around
since assembly days. The same issues are described in real-time courses
regardless of implementation language.

It would be interested to take some examples from these courses, such as
the
HAS Buoy, Cruise Control, and ATD/CWM case studies from the ADARTS
material,
and have them coded in SCOOP and executed.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33F526A9.23E5@flash.net> Ken Garlington <kennieg@flash.net> writes:

> > :That's not how requeue works, as I understand it. The issue is more: you
> > :attempt to do a.do_x, and someone else has already seized the resource, or
> > :there is some other time-based reason why a.do_x is unavailable.
> > 
> > What you've described sounds more like the mechanism for queuing
> > calls. Requeue is something different, as I understand it.
> 
> Well, I'm new to Ada 95, so you may be right.

From what I can see, you have it pretty much right.  Ergo, Don has it...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:

:> On protected types:

:Actually, it promotes OO principles, since the reasons for the requeue are
:often due to the internal implementation of the protected object, and thus
:can be hidden from the caller.

Actually, on having another look, it probably *is* okay. The situation with
requeues seems roughly equivalent to the valid situation of a separate object 
executing one of its own operations. Reflexive queueing just seems a little 
weird. 

:> One thing I'm curious about is where the requeued call gets placed on the
:> entry queue. I guess it must be placed on the head, rather than the tail,
:> for this to work. Is that the case?
:
:All queues are generally FIFO. 

The tail, in other words.

:> Out of interest, is there one queue per protected object or one queue per entry?
:
:One per entry (which is what you want, if you want the timing behavior to be
:different based on the operation/entry called). 

So, how does the runtime system select which queue to take the next call from?
Is it arbitrary? ..or the one for the first declared entry? ..something else? 
I think entries, by default, should be serviced in the order in which they 
are received by the object - which implies object-based, rather than entry-based
queueing. This is how SCOOP works.


:.. any entry can be requeued. Furthermore, it's not up to the caller or callee,
:it's up to the protected object:

The callee *is* the protected object. What do you mean by callee?

:"A requeue_statement can be used to complete an accept_statement or entry_body,
:while redirecting the corresponding entry call to a new (or the same) entry
:queue. Such a requeue can be performed with or without allowing an
:intermediate cancellation of the call, due to an abort or the expiration
:of a delay."
:
:"A requeue_statement shall be within a callable construct that is either an
:entry_body or an accept_statement, and this construct shall be the innermost
:enclosing body or callable construct."
:
:Again, the internal timing/sequence requirements can be hidden within the
:object. It makes the decisions based on its internal state, ..

Seems okay.

:> :> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
:> :> locking at the object level. Further, it's a *deficient* workaround because
:> :> supplier objects are forced to do things (do_y) that should be the
:> :> responsibility of clients (do_something).

I think I probably misunderstood requeue's purpose here. The criticism of 
object-level locking reamains valid, though.


:> I think it will be fine for *any* size system. Obviously, it will require a
:> different design approach to that used with Ada because of some fundamental
:> differences. These differences make it both more restrictive (in reliability-
:> enhancing ways) and less restrictive (in ways that enhance reuse and modelling
:> integrity).
:
:The design approaches I describe didn't come with Ada. They've been around
:since assembly days. The same issues are described in real-time courses
:regardless of implementation language.
:
:It would be interested to take some examples from these courses, such as the
:HAS Buoy, Cruise Control, and ATD/CWM case studies from the ADARTS material,
:and have them coded in SCOOP and executed.

I agree - it would. If I get a chance, I'll take a look. Where are they?


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> 
> So, how does the runtime system select which queue to take the next call from?
> Is it arbitrary? ..or the one for the first declared entry? ..something else?

See http://www.adahome.com/rm95/rm9x-09-05-03.html para (17):

"If calls from two or more queues are simultaneously eligible for
selection,
the default entry queuing policy does not specify which queue is
serviced first.
Other entry queuing policies can be specified by pragmas (see D.4)."

> I think entries, by default, should be serviced in the order in which they
> are received by the object - which implies object-based, rather than entry-based
> queueing. This is how SCOOP works.

If you prefer this, you can use Priority_Queuing as described in D.4, or
just
provide a single entry to the object (with a parameter denoting what
needs to
be done). The extra flexibility of multiple queues lets you provide
different
entries for different priorities, so that you can take calls "out of
order"
based on some policy.

> 
> :.. any entry can be requeued. Furthermore, it's not up to the caller or callee,
> :it's up to the protected object:
> 
> The callee *is* the protected object. What do you mean by callee?

I meant to say "either caller" - the two tasks that would be dueling in
SCOOP.

> :"A requeue_statement can be used to complete an accept_statement or entry_body,
> :while redirecting the corresponding entry call to a new (or the same) entry
> :queue. Such a requeue can be performed with or without allowing an
> :intermediate cancellation of the call, due to an abort or the expiration
> :of a delay."
> :
> :"A requeue_statement shall be within a callable construct that is either an
> :entry_body or an accept_statement, and this construct shall be the innermost
> :enclosing body or callable construct."
> :
> :Again, the internal timing/sequence requirements can be hidden within the
> :object. It makes the decisions based on its internal state, ..
> 
> Seems okay.
> 
> :> :> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
> :> :> locking at the object level. Further, it's a *deficient* workaround because
> :> :> supplier objects are forced to do things (do_y) that should be the
> :> :> responsibility of clients (do_something).
> 
> I think I probably misunderstood requeue's purpose here. The criticism of
> object-level locking reamains valid, though.

If you say so...

> 
> :> I think it will be fine for *any* size system. Obviously, it will require a
> :> different design approach to that used with Ada because of some fundamental
> :> differences. These differences make it both more restrictive (in reliability-
> :> enhancing ways) and less restrictive (in ways that enhance reuse and modelling
> :> integrity).
> :
> :The design approaches I describe didn't come with Ada. They've been around
> :since assembly days. The same issues are described in real-time courses
> :regardless of implementation language.
> :
> :It would be interested to take some examples from these courses, such as the
> :HAS Buoy, Cruise Control, and ATD/CWM case studies from the ADARTS material,
> :and have them coded in SCOOP and executed.
> 
> I agree - it would. If I get a chance, I'll take a look. Where are they?

See http://www.software.org for more information.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> The caller blocks until the resource is available. There are actually no
> lower-priority threads - all threads are the same priority and their requests
> are queued impartially. Where timing is not an issue this gives you what you
> want because you get a kind of statistical "prioritisation". What I mean is
> that threads will automatically get serviced by a supplier object in proportion
> to the number of calls they make to it. In this situation, you don't care
> which threads are serviced first. You only care about whether there is enough
> processing capacity and if there isn't enough, you have a problem regardless
> of what queueing scheme is used.

That's true iff the threads are all the same priority. I've yet to work
on a
real system where this is the case, so this doesn't really help much...

> 
> Where timing *is* an issue, you use express messages. This mechanism allows
> threads to dynamically change their "priority" relative to other threads.
> This mechanism should only be used where it's critical to transfer control.
> There are two parties involved - the holder and the challenger - and they "duel"
> for control of a resource. Duels either result in a transfer of control or
> the challenger waiting till the holder finishes with the resource.

Does this mean that each thread has to know it's relative priority to
all other
threads (more to the point, thread interfaces)? That would be a serious
maintainability issue, I would think. You might want to look at some of
the real-time projet examples in the ADARTS courseware, for example.

>   - A thread which absolutely must execute (possibly driven by a timer) can
>     issue a challenge for a resource.

If, while another thread is operating, it cannot be interrrupted (as
your
previous note said, a thread cannot be interrupted even between object
calls),
then how does the other thread begin execution to issue the challenge?

> I was also concerned about this issue initially but came to the conclusion
> that objects would be locked for just as long as they (safely) need to be.
> Where it's important to release a frequently used shared resource quickly,
> various design strategies can be applied to minimise locking.

Don't these "design strategies" cause the same uncertainly that you said
you
didn't want? For example, if a lower-priority thread agrees to give up
control
of an object to a higher-priority thread, then race conditions are
possible
if the threads are not designed properly.

This seems counter-intuitive. Consider the simple protected object
discussed
earlier with the Read and Write operations. It would seem that the
object
itself, with its internal knowledge of how Read and Write works, would
be
the better place to control when blocking needs to occur. In order for
the
threads that use this object to decide the outcome of their "duel",
don't
they have to know the internal operation of the object -- an object
contract
violation?

> 
> :Priority inversion would also seem to be much more likely.
> 
> Can you explain what you mean by this?

Priority inversion? When a low prioity task seizes a high prioity
resource,
it effectively operates at the priority of the seized resource. If a
high
priority task then attempts to seize the resource, it is effectively
blocked
by the lower priority task -- priority inversion. However, since you can
in
fact have a thread interrupt another thread (has to happen, otherwise
there
is no "dueling"), and since the higher-priority thread can seize the
lower
one, I assume this can be avoided. However, it also opens the door to
both mutual exclusion and deadlock.

> :Ada has a different approach. Consider a fairly simple case of a value that
> :is read by some tasks, written by others. Clearly, if a thread is writing
> :a value, it should start and complete that operation before any other
> :access to that resource. Similarly, any attempt to read the resource should
> :start and complete before any write to the resource begins.
> 
> Agree.
> 
> :However,
> :a read by a low-priority task can be suspended to permit a higher-priority
> :task to read the same resouirce (assuming no side-effects of the read).
> :As I understand it, you would prohibit this benign "interference." Thus,
> :the high-priority task (which may run much more frequently than the
> :low-priority task) is unnecessarily delayed, potentially causing it
> :to meet it's deadline.
> 
> No. In this case, the reads could occur concurrently (due to optimisations).

Describe the general-purpose algorithm used to determince this by a
compiler.
If you can, you'll put a lot of system architects out of business!

Has such an algorithm been implemented yet? I would like to test this
wonderful
tool!

> :You claimed that the compiler could optimize the timing properties of
> :the system; I would be interested in seeing such a compiler..
> 
> I don't think it would be too hard. The compiler just has to verify that
> queries (functions) are truly benign 

Define "benign"! For example, is a read of a memory location "benign"?
Maybe not, if it's memory-mapped I/O. Some devices, for example, don't
take
kindly to starting a read and being interrupted in the middle to do a
new
read.

You may not think it's too hard, but I suspect you haven't encountered
many of these real-life systems.

> and implement two types of locks
> - read and write. This is yet another reason to strictly enforce side-effect-
> free functions.
> 
> :It wouldn't catch the extry/exit time of do_something, but
> :that's not a big deal.
> 
> At a higher level call, perhaps..
> 
> :I see you've missed the original
> :part of the thread. The poster suggested writing
> :assertions (post-conditions) on P, Q, R, and S as the
> :way to do this, which (as I said) won't work effectively.
> :Your approach is at the thread level, not the object
> :level, which is the way I would have done it as well.
> :So, in fact, we agree that the original post is in
> :error (I assume).
> 
> Probably - can't remember what was said.
> 
> :> will do the required actions and measure the elapsed time.
> :>
> :> Note that all four objects are locked for the block between "do" and "end".
> :> This means that there is no intervening time between calls to them and there
> :> is no opportunity for any other threads to jump in and make a mess of things.
> :
> :Just out of curiosity, can the "local" section make reference to these
> :objects?
> 
> Can't recall (and couldn't see from a quick glance at OOSC-2) but do know
> you would be limited in what you could do. For example, a local separate
> object couldn't be the target of a call. Why do you ask?

Because you said that they were locked between the "do" and "end". If
they
can be referenced in the local section, but are not locked, this would
seem
to be a Bad Thing.

> :Also, how is "do_something" attached to a hardware event?
> 
> Not sure, but probably via a call to a library routine.
> 
> :> Note that this offers more protection than Ada protected objects which are
> :> only locked on single object basis. As you will see later, this also removes
> :> the need for a "requeue" statement.
> :
> :True. However, you pay a pretty terrible price for this protection, as
> :far as I can tell. I can see several systems which literally could not
> :be implemented under these rules.
> 
> They would likely be designed differently, though, by paying more attention
> to locking issues.

It's difficult to communicate to someone without the experience, but
it's much like asking someone to do a periodic task without reference to
any timer, clock, etc. It's theoretically possible, but in practice such
an implementation is pretty much impossible.

> 
> :> :If you are saying that a thread (a series of object invocations) cannot be
> :> :interrupted at _any point_, then that pretty much eliminates
> :> :concurrency, doesn't it?
> :>
> :> No, it just means it's more controlled (and safer). There is a complementary
> :> library mechanism called "express messages" which allows pre-emption of threads.
> :
> :Perhaps this "express messages" is the backdoor which I have to believe
> :a real system would need.
> 
> Correct.
> 
> :Correct me if I'm wrong, but no other thread can run while do_something is
> :executing?
> 
> On a single processor, yes. 
> On a multiple processor, no.
> 
> :Or are you saying it can be interrupted, just that no other thread
> :can access the objects referenced in the parameter list (or any objects
> :referenced in _their_ parameter lists? )?
> 
> Correct.

OK, this makes more sense. However, it does mean that my original
comment
is correct -- assertions at the object level cannot be added up to
form the thread time, since threads can be interrupted. That's all
I needed to know.

> 
> Have run out of time. Will respond to the rest tomorrow.
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> The caller blocks until the resource is available. There are actually no
:> lower-priority threads - all threads are the same priority and their requests
:> are queued impartially. Where timing is not an issue this gives you what you
:> want because you get a kind of statistical "prioritisation". What I mean is
:> that threads will automatically get serviced by a supplier object in proportion
:> to the number of calls they make to it. In this situation, you don't care
:> which threads are serviced first. You only care about whether there is enough
:> processing capacity and if there isn't enough, you have a problem regardless
:> of what queueing scheme is used.
:
:That's true iff the threads are all the same priority. I've yet to work
:on a real system where this is the case, so this doesn't really help much...

I think it depends what you use priorities for. If you use them for their 
intended purpose of ensuring threads meet their deadlines, then they only 
need be applied to threads that have deadlines.

The problem is many Ada developers misuse priorities to acheive correct 
synchronisation. Realtime systems that misuse priorities in this way tend 
(not surprisingly) to be very fragile, suffering from race conditions. 
The basic problem with using priorities for syncronisation is that you cannot 
guarantee correct behaviour. It is the *wrong* tool for the job. So, what's
the right tool? 

It's Design by Contract! Why? Because it allows you to express the necessary 
(*blocking*) conditions which are assumed to exist when a concurrent operation 
is executed. We recall that when those assumptions are violated in a sequential 
context, an exception is raised. In a concurrent context (ie. when the 
precondition involves a separate object), they assume synchronisation semantics. 
The caller blocks till another thread performs does something which causes the 
precondition to now be satisfied.

For example, an operation adding an item to a buffer:

  add_to_buffer (b: BUFFER; item: SOME_TYPE) is
  require not b.full
  do 
    b.add (item)
  end

Because b is non-separate (sequential), the precondition will fail if b is full.

  add_to_buffer (b: separate BUFFER; item: SOME_TYPE) is
  require not b.full
  do 
    b.add (item)
  end

Because b is separate (concurrent), the precondition will cause blocking until
another thread removes an item from the buffer (ie. b is not full).

Any Ada developer reading this should immediately recognise the similarity 
with guarded task entries and barriers on protected type entries. These 
mechanisms, then, are additional ways (apart from predefined assertions (think 
program_error etc.) and range-constrained subtypes) in which Ada provides some 
support for DBC. In fact, because guards and barriers are *general* boolean 
expressions, they are about as close as Ada gets to the generality of Eiifel's 
support for DBC.


Now, back to the priority issue..

Because, under SCOOP, you can apply such synchronisation assertions to any 
separate object, you are able to specify precisely the assumptions relevant 
to the operations offered by those objects and guarantee correct use.
This leaves priorities to be used for what their proper use - expressing 
relative importance of threads for facilitating timeliness. Consequently,
I expect a system implemented using SCOOP would have more "priority-less" 
threads.
 

:> Where timing *is* an issue, you use express messages. This mechanism allows
:> threads to dynamically change their "priority" relative to other threads.
:> This mechanism should only be used where it's critical to transfer control.
:> There are two parties involved - the holder and the challenger - and they "duel"
:> for control of a resource. Duels either result in a transfer of control or
:> the challenger waiting till the holder finishes with the resource.
:
:Does this mean that each thread has to know it's relative priority to all other
:threads (more to the point, thread interfaces)? 

No, but it does suggest the priority of a thread relative to all threads that 
it interacts with must be known. I'm not aware of any published information 
about how this is intended to work but imagine it could use abslolute priorities
(so implying relative ones):

  set_priority (p: PRIORITY) is ..        -- set absolute priority
  yield (p: PRIORITY) is ..               -- yield to priority p or greater
  etc.

:That would be a serious maintainability issue, I would think. 

Yes, if it were true - but it isn't.


:>   - A thread which absolutely must execute (possibly driven by a timer) can
:>     issue a challenge for a resource.
:
:If, while another thread is operating, it cannot be interrrupted (as your
:previous note said, a thread cannot be interrupted even between object calls),
:then how does the other thread begin execution to issue the challenge?

We're talking single processor here, of course (the issue doesn't arise with 
multi-processors). An executing thread will give up the processor to another 
thread if it blocks on a synchronisation condition (a precondition on a 
separate object). Expanding the buffer example above:

  x: separate BUFFER
  s: SOME_TYPE
  ...

  do_something is
  do
    ...
    add_to_buffer (x, s)
    ...
  end

do_something may block on the call to add_to_buffer (because the buffer is full)
causing another thread to run.


:> I was also concerned about this issue initially but came to the conclusion
:> that objects would be locked for just as long as they (safely) need to be.
:> Where it's important to release a frequently used shared resource quickly,
:> various design strategies can be applied to minimise locking.
:
:Don't these "design strategies" cause the same uncertainly that you said
:you didn't want? 

No. Also, these techniques can be applied to *any* concurrent system - they 
are not SCOOP-specific. Hence, they're not relevant to any discussion about 
the relative merits of different concurrency models. 


:For example, if a lower-priority thread agrees to give up control
:of an object to a higher-priority thread, then race conditions are possible
:if the threads are not designed properly.

Assertions would help you to design them properly and avoid such conditions. 
Also, invariants will guarantee that an object yielding in a duel will end 
up in a consistent state. 


:This seems counter-intuitive. Consider the simple protected object discussed
:earlier with the Read and Write operations. It would seem that the object
:itself, with its internal knowledge of how Read and Write works, would be
:the better place to control when blocking needs to occur. 

That *is* how blocking works under SCOOP. The operation of the supplier object 
contains the precondition, so the supplier determines the (synchronisation) 
contract.

:In order for the
:threads that use this object to decide the outcome of their "duel", don't
:they have to know the internal operation of the object -- an object contract
:violation?

No, only the object has to know (and how to restore its invariant - ie. how 
to return to a consistent state).


:> :Priority inversion would also seem to be much more likely.
:> 
:> Can you explain what you mean by this?
:
:Priority inversion? When a low prioity task seizes a high prioity resource,
:it effectively operates at the priority of the seized resource. If a high
:priority task then attempts to seize the resource, it is effectively blocked
:by the lower priority task -- priority inversion. However, since you can in
:fact have a thread interrupt another thread (has to happen, otherwise there
:is no "dueling"), and since the higher-priority thread can seize the lower
:one, I assume this can be avoided. 

Correct.

:However, it also opens the door to both mutual exclusion and deadlock.

..which are avoided (as in *any* concurrent system) by designing correctly.

:> No. In this case, the reads could occur concurrently (due to optimisations).
:
:Describe the general-purpose algorithm used to determince this by a compiler.

Ask Robert Dewar because that's what happens with protected types.  :)


:> :You claimed that the compiler could optimize the timing properties of
:> :the system; I would be interested in seeing such a compiler..
:> 
:> I don't think it would be too hard. The compiler just has to verify that
:> queries (functions) are truly benign 
:
:Define "benign"! For example, is a read of a memory location "benign"?
:Maybe not, if it's memory-mapped I/O. Some devices, for example, don't take
:kindly to starting a read and being interrupted in the middle to do a new
:read.

This issue is common to any concurrency model. But the answer is simple:
"If it isn't benign, don't allow concurrent reads".

:You may not think it's too hard, but I suspect you haven't encountered
:many of these real-life systems.

You could be right. Perhaps, I've learnt nothing from my 8 years realtime 
experience (including 3 years hard realtime). (I think combat systems qualify
for hard realtime - at least, I found it quite hard. :) 


:> :Just out of curiosity, can the "local" section make reference to these
:> :objects?
:> 
:> Can't recall (and couldn't see from a quick glance at OOSC-2) but do know
:> you would be limited in what you could do. For example, a local separate
:> object couldn't be the target of a call. Why do you ask?
:
:Because you said that they were locked between the "do" and "end". If they
:can be referenced in the local section, but are not locked, this would seem
:to be a Bad Thing.

It appears the reattachment rules would ensure that it can only reference a 
locked object.

:> :Correct me if I'm wrong, but no other thread can run while do_something is
:> :executing?
:> 
:> On a single processor, yes. 
:> On a multiple processor, no.

Sorry, this was misleading. Another thread can run if the original blocks.
 
:> :Or are you saying it can be interrupted, just that no other thread
:> :can access the objects referenced in the parameter list (or any objects
:> :referenced in _their_ parameter lists? )?
:> 
:> Correct.
:
:OK, this makes more sense. However, it does mean that my original comment
:is correct -- assertions at the object level cannot be added up to
:form the thread time, since threads can be interrupted. That's all
:I needed to know.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Lee Webber]

On Tue, 19 Aug 1997 02:18:04 GMT, donh@syd.csa.com.au (Don Harrison)
wrote:

>Ken Garlington wrote:
>
>:Don Harrison wrote:

>That *is* how blocking works under SCOOP. The operation of the supplier object 
>contains the precondition, so the supplier determines the (synchronisation) 
>contract.

It's not clear to me that we're getting at the truth here on either
side.  Let me throw in an example and we can go from there.
(Caveat: I'm not a guru, but I have just finished studying chapter 30
of OOSC2 very closely.)

Assume:

   two objects X and Y on which we want to synchronize.
   a client C that wants exclusive access to them.

We will assume that when X and Y were instantiated, they were attached
to 'separate' entities x and y.  This is not necessary for
exclusivity, but most interesting cases happen this way as far as I
can see.

Now to get exclusive access to X and Y, C has to define a feature as
follows:

feature access_xy (separate xx, yy) is
require
   conditions_on_x	-- if these are not met, access_xy blocks
   conditions_on_y
do
     -- at this point, C has exclusive access to X and Y
    operations_on_x
    operations_on_y    -- possibly interleaved
end
     -- at this point, C has given up X and Y

Now my point.  It is likely that operations_on_x and operations_on_y
have preconditions.  However, it is not those preconditions that are
used for blocking, but the preconditions on access_xy.  Hopefully,
the latter subsume the former to the extent they do not ensure them
directly, but it's not enforced.  SCOOP requires you to duplicate the
preconditions if you want to block on them.

So DH's statement above is only true if C is considered the supplier!
Now normally that would be the case -- i.e., a wrapper class is
written that performs the synchronization functions and is then called
by the real client -- but it must be made clear that the class(es) to
be synchronized on do not directly specify the blocking preconditions.


See OOSC2 p. 996.

>
>:In order for the
>:threads that use this object to decide the outcome of their "duel", don't
>:they have to know the internal operation of the object -- an object contract
>:violation?
>
>No, only the object has to know (and how to restore its invariant - ie. how 
>to return to a consistent state).

On the other hand, DH is correct here. The exception occurs in the
object being contended for (the one that is executing a routine at the
time -- there can be at most one such).  (Question for guru'ier
people: what happens if the challenge occurs when access_to_xy is
calling a non-separate object?  Who gets the exception?)

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> I think it depends what you use priorities for. If you use them for their
> intended purpose of ensuring threads meet their deadlines, then they only
> need be applied to threads that have deadlines.

In feedback systems, it is a fundamental property that most of the
threads
have explicit deadlines, or the analog transfer function you've
discretized
will not be appropriately implemented.

> The problem is many Ada developers misuse priorities to acheive correct
> synchronisation. Realtime systems that misuse priorities in this way tend
> (not surprisingly) to be very fragile, suffering from race conditions.
> The basic problem with using priorities for syncronisation is that you cannot
> guarantee correct behaviour. It is the *wrong* tool for the job. So, what's
> the right tool?

Possibly true, although I've never seen it done (for the obvious reason
you cite!)

> It's Design by Contract! Why? Because it allows you to express the necessary
> (*blocking*) conditions which are assumed to exist when a concurrent operation
> is executed.

So can Ada.

> We recall that when those assumptions are violated in a sequential
> context, an exception is raised. In a concurrent context (ie. when the
> precondition involves a separate object), they assume synchronisation semantics.
> The caller blocks till another thread performs does something which causes the
> precondition to now be satisfied.
> 
> For example, an operation adding an item to a buffer:
> 
>   add_to_buffer (b: BUFFER; item: SOME_TYPE) is
>   require not b.full
>   do
>     b.add (item)
>   end
> 
> Because b is non-separate (sequential), the precondition will fail if b is full.
> 
>   add_to_buffer (b: separate BUFFER; item: SOME_TYPE) is
>   require not b.full
>   do
>     b.add (item)
>   end
> 
> Because b is separate (concurrent), the precondition will cause blocking until
> another thread removes an item from the buffer (ie. b is not full).
> 
> Any Ada developer reading this should immediately recognise the similarity
> with guarded task entries and barriers on protected type entries. These
> mechanisms, then, are additional ways (apart from predefined assertions (think
> program_error etc.) and range-constrained subtypes) in which Ada provides some
> support for DBC. In fact, because guards and barriers are *general* boolean
> expressions, they are about as close as Ada gets to the generality of Eiifel's
> support for DBC.
> 
> Now, back to the priority issue..
> 
> Because, under SCOOP, you can apply such synchronisation assertions to any
> separate object, you are able to specify precisely the assumptions relevant
> to the operations offered by those objects and guarantee correct use.
> This leaves priorities to be used for what their proper use - expressing
> relative importance of threads for facilitating timeliness. Consequently,
> I expect a system implemented using SCOOP would have more "priority-less"
> threads.

Unfortunately, systems that represent digital models of analog functions
(e.g.
flight controls, IRSs) will confound your expectations :)

> 
> 
> :> Where timing *is* an issue, you use express messages. This mechanism allows
> :> threads to dynamically change their "priority" relative to other threads.
> :> This mechanism should only be used where it's critical to transfer control.
> :> There are two parties involved - the holder and the challenger - and they "duel"
> :> for control of a resource. Duels either result in a transfer of control or
> :> the challenger waiting till the holder finishes with the resource.
> :
> :Does this mean that each thread has to know it's relative priority to all other
> :threads (more to the point, thread interfaces)?
> 
> No, but it does suggest the priority of a thread relative to all threads that
> it interacts with must be known.

That, to me, seems to be a problem with respect to encapsulating this
information
(which is what I want to do).

>  I'm not aware of any published information
> about how this is intended to work but imagine it could use abslolute priorities
> (so implying relative ones):
> 
>   set_priority (p: PRIORITY) is ..        -- set absolute priority
>   yield (p: PRIORITY) is ..               -- yield to priority p or greater
>   etc.
> 
> :That would be a serious maintainability issue, I would think.
> 
> Yes, if it were true - but it isn't.

See above. If the relative priority of each interaction is distributed,
then
it's true.

> 
> :>   - A thread which absolutely must execute (possibly driven by a timer) can
> :>     issue a challenge for a resource.
> :
> :If, while another thread is operating, it cannot be interrrupted (as your
> :previous note said, a thread cannot be interrupted even between object calls),
> :then how does the other thread begin execution to issue the challenge?
> 
> We're talking single processor here, of course (the issue doesn't arise with
> multi-processors). An executing thread will give up the processor to another
> thread if it blocks on a synchronisation condition (a precondition on a
> separate object). 

Not in the real word of embedded systems. Think about non-maskable
hardware
interrupts.

> Expanding the buffer example above:
> 
>   x: separate BUFFER
>   s: SOME_TYPE
>   ...
> 
>   do_something is
>   do
>     ...
>     add_to_buffer (x, s)
>     ...
>   end
> 
> do_something may block on the call to add_to_buffer (because the buffer is full)
> causing another thread to run.
> 
> :> I was also concerned about this issue initially but came to the conclusion
> :> that objects would be locked for just as long as they (safely) need to be.
> :> Where it's important to release a frequently used shared resource quickly,
> :> various design strategies can be applied to minimise locking.
> :
> :Don't these "design strategies" cause the same uncertainly that you said
> :you didn't want?
> 
> No.

Why not? Can't the developer (whom you don't trust) fail to properly
implement
these "design strategies"?

> Also, these techniques can be applied to *any* concurrent system - they
> are not SCOOP-specific. Hence, they're not relevant to any discussion about
> the relative merits of different concurrency models.

Are there deployed systems that use these techniques?

> 
> :For example, if a lower-priority thread agrees to give up control
> :of an object to a higher-priority thread, then race conditions are possible
> :if the threads are not designed properly.
> 
> Assertions would help you to design them properly and avoid such conditions.

See above. Your original position was that the compiler should take care
of
all of this, so that the designer would not make an error. Now you
depend
upon the designer to implement the timing process properly (and write
the
proper assertions; an issue which my Ariane response addresses in some
detail).

> Also, invariants will guarantee that an object yielding in a duel will end
> up in a consistent state.
> 
> :This seems counter-intuitive. Consider the simple protected object discussed
> :earlier with the Read and Write operations. It would seem that the object
> :itself, with its internal knowledge of how Read and Write works, would be
> :the better place to control when blocking needs to occur.
> 
> That *is* how blocking works under SCOOP. The operation of the supplier object
> contains the precondition, so the supplier determines the (synchronisation)
> contract.
> 
> :In order for the
> :threads that use this object to decide the outcome of their "duel", don't
> :they have to know the internal operation of the object -- an object contract
> :violation?
> 
> No, only the object has to know (and how to restore its invariant - ie. how
> to return to a consistent state).

You're using the word "no" a lot without explanation. Two callers to the
object decide between *themselves* who gets to maintain access. Now it's
the
called object that determines the outcome of the duel?

You've pretty much worked me around in circles. I think I'll just wait
until
someone actually uses SCOOP to make up my mind.


> 
> :> :Priority inversion would also seem to be much more likely.
> :>
> :> Can you explain what you mean by this?
> :
> :Priority inversion? When a low prioity task seizes a high prioity resource,
> :it effectively operates at the priority of the seized resource. If a high
> :priority task then attempts to seize the resource, it is effectively blocked
> :by the lower priority task -- priority inversion. However, since you can in
> :fact have a thread interrupt another thread (has to happen, otherwise there
> :is no "dueling"), and since the higher-priority thread can seize the lower
> :one, I assume this can be avoided.
> 
> Correct.
> 
> :However, it also opens the door to both mutual exclusion and deadlock.
> 
> ..which are avoided (as in *any* concurrent system) by designing correctly.
> 
> :> No. In this case, the reads could occur concurrently (due to optimisations).
> :
> :Describe the general-purpose algorithm used to determince this by a compiler.
> 
> Ask Robert Dewar because that's what happens with protected types.  :)

ABSOLUTELY NOT. The developer of the protected type explicitly provides
the
criteria; there's no magic going on in the compiler. I think your
understanding
of Ada is at least as hazy as my understanding of SCOOP :)

> 
> :> :You claimed that the compiler could optimize the timing properties of
> :> :the system; I would be interested in seeing such a compiler..
> :>
> :> I don't think it would be too hard. The compiler just has to verify that
> :> queries (functions) are truly benign
> :
> :Define "benign"! For example, is a read of a memory location "benign"?
> :Maybe not, if it's memory-mapped I/O. Some devices, for example, don't take
> :kindly to starting a read and being interrupted in the middle to do a new
> :read.
> 
> This issue is common to any concurrency model.

Which is why it's a situation that the _developer_, not the compiler,
must address. It is also why the language has to give the _developer_
the flexibility to address it (even if he is still capable of shooting
himself in the foot).

> But the answer is simple:
> "If it isn't benign, don't allow concurrent reads".

To repeat: Define "benign!!!!!!!!" It has to be sufficiently loose to
permit
working systems, but tight enough to prohibit concurrency faults (your
original claim).

> 
> :You may not think it's too hard, but I suspect you haven't encountered
> :many of these real-life systems.
> 
> You could be right. Perhaps, I've learnt nothing from my 8 years realtime
> experience (including 3 years hard realtime). (I think combat systems qualify
> for hard realtime - at least, I found it quite hard. :)

Absolutely not, if the combat systems (1) were not _embedded_ (which is
where
many of these problems come up), (2) had minimal OS support (I've seen
workstation
programmers with over ten years experience with realtime systems that
have
never had to worry about these issues), and (3) had to deal with hard
realtime
in the sense that the system _totally fails_ if a complex set of
deadlines
fail -- as opposed to the user getting irritated that the system is too
slow.

> 
> :> :Just out of curiosity, can the "local" section make reference to these
> :> :objects?
> :>
> :> Can't recall (and couldn't see from a quick glance at OOSC-2) but do know
> :> you would be limited in what you could do. For example, a local separate
> :> object couldn't be the target of a call. Why do you ask?
> :
> :Because you said that they were locked between the "do" and "end". If they
> :can be referenced in the local section, but are not locked, this would seem
> :to be a Bad Thing.
> 
> It appears the reattachment rules would ensure that it can only reference a
> locked object.
> 
> :> :Correct me if I'm wrong, but no other thread can run while do_something is
> :> :executing?
> :>
> :> On a single processor, yes.
> :> On a multiple processor, no.
> 
> Sorry, this was misleading. Another thread can run if the original blocks.
> 
> :> :Or are you saying it can be interrupted, just that no other thread
> :> :can access the objects referenced in the parameter list (or any objects
> :> :referenced in _their_ parameter lists? )?
> :>
> :> Correct.
> :
> :OK, this makes more sense. However, it does mean that my original comment
> :is correct -- assertions at the object level cannot be added up to
> :form the thread time, since threads can be interrupted. That's all
> :I needed to know.
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:

[...]

:> The problem is many Ada developers misuse priorities to acheive correct
:> synchronisation. Realtime systems that misuse priorities in this way tend
:> (not surprisingly) to be very fragile, suffering from race conditions.
:> The basic problem with using priorities for syncronisation is that you cannot
:> guarantee correct behaviour. It is the *wrong* tool for the job. So, what's
:> the right tool?
:
:Possibly true, although I've never seen it done (for the obvious reason
:you cite!)

I find that hard to believe. Judging by the sort of problems that have been 
raised in this thread alone, that's *exactly* how a lot of Ada software works.

[...]

:> Now, back to the priority issue..
:> 
:> Because, under SCOOP, you can apply such synchronisation assertions to any
:> separate object, you are able to specify precisely the assumptions relevant
:> to the operations offered by those objects and guarantee correct use.
:> This leaves priorities to be used for what their proper use - expressing
:> relative importance of threads for facilitating timeliness. Consequently,
:> I expect a system implemented using SCOOP would have more "priority-less"
:> threads.
:
:Unfortunately, systems that represent digital models of analog functions (e.g.
:flight controls, IRSs) will confound your expectations :)

..in spite of not having any expectations of them. If you say so.

What I *do* expect is that more prioritisation is required the more numerous 
and more stringent timing constraints become. 


[...]

:>  I'm not aware of any published information
:> about how this is intended to work but imagine it could use abslolute priorities
:> (so implying relative ones):
:> 
:>   set_priority (p: PRIORITY) is ..        -- set absolute priority
:>   yield (p: PRIORITY) is ..               -- yield to priority p or greater
:>   etc.
:> 
:> :That would be a serious maintainability issue, I would think.
:> 
:> Yes, if it were true - but it isn't.
:
:See above. If the relative priority of each interaction is distributed, then
:it's true.

Perhaps you haven't grasped what I'm saying here. I'm saying that's exactly 
what you *wouldn't* do. You would use absolute priorities (as you do in Ada)
to *imply* relative ones.


:> :>   - A thread which absolutely must execute (possibly driven by a timer) can
:> :>     issue a challenge for a resource.
:> :
:> :If, while another thread is operating, it cannot be interrrupted (as your
:> :previous note said, a thread cannot be interrupted even between object calls),
:> :then how does the other thread begin execution to issue the challenge?
:> 
:> We're talking single processor here, of course (the issue doesn't arise with
:> multi-processors). An executing thread will give up the processor to another
:> thread if it blocks on a synchronisation condition (a precondition on a
:> separate object). 
:
:Not in the real word of embedded systems. Think about non-maskable hardware
:interrupts.

Not sure what you mean by "non-maskable .. interrupts". Care to explain?
However, wrt interrupts generally, a SCOOP implementation could provide 
an external mechanism for attaching routines to interrupts. This information 
would appear in an external configuration file as for non-benign functions (see 
below).


:> :> I was also concerned about this issue initially but came to the conclusion
:> :> that objects would be locked for just as long as they (safely) need to be.
:> :> Where it's important to release a frequently used shared resource quickly,
:> :> various design strategies can be applied to minimise locking.
:> :
:> :Don't these "design strategies" cause the same uncertainly that you said
:> :you didn't want?
:> 
:> No.
:
:Why not? Can't the developer (whom you don't trust) fail to properly implement
:these "design strategies"?

Here it is again (since you obviously missed it the first time)..

:> Also, these techniques can be applied to *any* concurrent system - they
:> are not SCOOP-specific. Hence, they're not relevant to any discussion about
:> the relative merits of different concurrency models.
:
:Are there deployed systems that use these techniques?

Yes, you probably use them yourself. :)

:> :For example, if a lower-priority thread agrees to give up control
:> :of an object to a higher-priority thread, then race conditions are possible
:> :if the threads are not designed properly.
:> 
:> Assertions would help you to design them properly and avoid such conditions.
:
:... Your original position was that the compiler should take care of
:all of this, so that the designer would not make an error. 

Rubbish! Report accurately what I say or forget about discussing anything.

What I *did* say was something like "Under SCOOP, race conditions would not
be an issue..". "Under SCOOP" implies not just using the mechanism but using
it to its full potential. If you use (synchronisation) assertions to document 
your assumptions, race conditions shouldn't exist. Naturally, race conditions
*will* exist in the absence of such specifications.

Having said that, I need to clarify what I mean by "race conditions". I mean 
incorrect behaviour resulting from inadequate (or non-existent) synchronisation.
I *don't* mean thread starvation or deadlock. These are avoided by designing 
correctly.

:Now you depend upon the designer to implement the timing process properly 
(and write the proper assertions; 

No, that was always implied. You incorrectly *assumed* I meant something else.


:> Also, invariants will guarantee that an object yielding in a duel will end
:> up in a consistent state.
:> 
:> :This seems counter-intuitive. Consider the simple protected object discussed
:> :earlier with the Read and Write operations. It would seem that the object
:> :itself, with its internal knowledge of how Read and Write works, would be
:> :the better place to control when blocking needs to occur.
:> 
:> That *is* how blocking works under SCOOP. The operation of the supplier object
:> contains the precondition, so the supplier determines the (synchronisation)
:> contract.
:> 
:> :In order for the
:> :threads that use this object to decide the outcome of their "duel", don't
:> :they have to know the internal operation of the object -- an object contract
:> :violation?

Sorry, I should have pointed out here you're confusing blocking and duels.

In the case of blocking, the callee determines how a caller will synchronise 
with it. In the case of callers duelling for a callee, their relative 
"priorities" (probably inferred from absolute priorities) will determine the 
outcome of the duel.

:> No, only the object has to know (and how to restore its invariant - ie. how
:> to return to a consistent state).

Sorry, I gave you a bum steer here. :(

The state of a called object has nothing to do with the outcome of a duel - 
it's determined by the relative "priorities" of the callers (duellers). My 
explanations of blocking and duels may make more sense to you now if you re-read 
them.

:You've pretty much worked me around in circles. 

Thank you. :)


:> :Describe the general-purpose algorithm used to determince this by a compiler.
:> 
:> Ask Robert Dewar because that's what happens with protected types.  :)
:
:ABSOLUTELY NOT. The developer of the protected type explicitly provides the
:criteria; there's no magic going on in the compiler. I think your understanding
:of Ada is at least as hazy as my understanding of SCOOP :)

We may be talking about different things here. I'm talking about the ability
to have concurrent reads (queries). This is precisely what happens with 
protected types (where functions can be executed concurrently) so the 
optimisations I say are possible in SCOOP would be materially no different from
those implemented for protected types.


:> :> :You claimed that the compiler could optimize the timing properties of
:> :> :the system; I would be interested in seeing such a compiler..
:> :>
:> :> I don't think it would be too hard. The compiler just has to verify that
:> :> queries (functions) are truly benign
:> :
:> :Define "benign"! For example, is a read of a memory location "benign"?
:> :Maybe not, if it's memory-mapped I/O. Some devices, for example, don't take
:> :kindly to starting a read and being interrupted in the middle to do a new
:> :read.

A function is "benign" if it has no side-effects. That is calling it (and,
possibly, interrupting it in the middle) will not change the state of the 
system - software *and* hardware.

:> This issue is common to any concurrency model.
:
:Which is why it's a situation that the _developer_, not the compiler,
:must address. It is also why the language has to give the _developer_
:the flexibility to address it (even if he is still capable of shooting
:himself in the foot).

Sure. A SCOOP implementation could provide for this in an external configuration
file, for example. This would be a better option, IMO, than some language 
construct. An appropriate mechanism will give you both efficient sharing of 
resources and safety.


:> :You may not think it's too hard, but I suspect you haven't encountered
:> :many of these real-life systems.
:> 
:> You could be right. Perhaps, I've learnt nothing from my 8 years realtime
:> experience (including 3 years hard realtime). (I think combat systems qualify
:> for hard realtime - at least, I found it quite hard. :)
:
:Absolutely not, if the combat systems (1) were not _embedded_ (which is where
:many of these problems come up), (2) had minimal OS support (I've seen workstation
:programmers with over ten years experience with realtime systems that have
:never had to worry about these issues), and (3) had to deal with hard realtime
:in the sense that the system _totally fails_ if a complex set of deadlines
:fail -- as opposed to the user getting irritated that the system is too slow.

My combat systems qualifies on all counts but, frankly, its quite irrelevant
to whether what I have to say has any substance.

IMHO, sprouting one's experience (or academic credentials) as though it is the 
final arbiter of truth is just pissing on power poles. Rather than adding weight 
to one's arguments, it betrays the fact you think you know it all. Sadly, anyone 
with that sort of attitude is impervious to learning anything new.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Lee Webber]

On Thu, 14 Aug 1997 07:38:08 GMT, donh@syd.csa.com.au (Don Harrison)
wrote:

>Ken Garlington wrote:
>
>:Don Harrison wrote:
     ...
>:It seems to me that, locking _all_ objects involved in an operation (without
>:regard to whether they guard a sensitive resource, such as a data store
>:that can be written by multiple threads) means that the latencies associated
>:with the threads goes up dramatically, particularly if the locking is
>:transitive.
>
>I was also concerned about this issue initially but came to the conclusion 
>that objects would be locked for just as long as they (safely) need to be.
>Where it's important to release a frequently used shared resource quickly, 
>various design strategies can be applied to minimise locking.
  ^^^^^^^^^^^^^^^^^^^

I would be interested in your expanding on this.  In particular, how
would you implement this in SCOOP:

        gain exclusive access to A
           perform time-consuming work using A and local resources
        gain exclusive access to A and B jointly
           perform work using A, B and local resources computed above
        release A, retain B
           perform time-consuming work using B and local resources
              computed above
        release access to B

making sure that neither A nor B is held when it is not needed.  (You
may assume that all competing processes attempt to acquire A and B in
the order above -- otherwise there is no solution other than the
trivial that avoids deadlock.)

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Lee Webber wrote:

:On Thu, 14 Aug 1997 07:38:08 GMT, donh@syd.csa.com.au (Don Harrison)
:wrote:
:
:>Ken Garlington wrote:
:>
:>:Don Harrison wrote:
:     ...
:>:It seems to me that, locking _all_ objects involved in an operation (without
:>:regard to whether they guard a sensitive resource, such as a data store
:>:that can be written by multiple threads) means that the latencies associated
:>:with the threads goes up dramatically, particularly if the locking is
:>:transitive.
:>
:>I was also concerned about this issue initially but came to the conclusion 
:>that objects would be locked for just as long as they (safely) need to be.
:>Where it's important to release a frequently used shared resource quickly, 
:>various design strategies can be applied to minimise locking.
:  ^^^^^^^^^^^^^^^^^^^
:
:I would be interested in your expanding on this.  

Looks like you think your bogometer's gone off again. :)

As I said in my response to Ken, they're not model-specific so I don't intend
being more specific.

:In particular, how would you implement this in SCOOP:
:
:        gain exclusive access to A
:           perform time-consuming work using A and local resources
:        gain exclusive access to A and B jointly
:           perform work using A, B and local resources computed above
:        release A, retain B
:           perform time-consuming work using B and local resources
:              computed above
:        release access to B
:
:making sure that neither A nor B is held when it is not needed.  
:(You may assume that all competing processes attempt to acquire A and B in
:the order above -- otherwise there is no solution other than the
:trivial that avoids deadlock.)

The solution I'm thinking of would use:

  - A staged approach in which intermediate data is computed.
  - Express messages to yield to higher "priority" threads.
  - A transaction-based approach to apply the results at the end on 
    successful completion.

I don't have the time to thrash out the details, but it should work and should 
be safe.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Lee Webber]

On Tue, 19 Aug 1997 05:15:59 GMT, donh@syd.csa.com.au (Don Harrison)
wrote:

>Lee Webber wrote:
>
>:On Thu, 14 Aug 1997 07:38:08 GMT, donh@syd.csa.com.au (Don Harrison)
>:wrote:
>:>various design strategies can be applied to minimise locking.
>:  ^^^^^^^^^^^^^^^^^^^
>:
>:I would be interested in your expanding on this.  
>
>Looks like you think your bogometer's gone off again. :)

   In spades.

>:In particular, how would you implement this in SCOOP:
>:
>:        gain exclusive access to A
>:           perform time-consuming work using A and local resources
>:        gain exclusive access to A and B jointly
>:           perform work using A, B and local resources computed above
>:        release A, retain B
>:           perform time-consuming work using B and local resources
>:              computed above
>:        release access to B
>:
>:making sure that neither A nor B is held when it is not needed.  
>:(You may assume that all competing processes attempt to acquire A and B in
>:the order above -- otherwise there is no solution other than the
>:trivial that avoids deadlock.)
>
>The solution I'm thinking of would use:
>
>  - A staged approach in which intermediate data is computed.
>  - Express messages to yield to higher "priority" threads.
>  - A transaction-based approach to apply the results at the end on 
>    successful completion.
>
>I don't have the time to thrash out the details, but it should work and should 
>be safe.
>

I'll help you out, then.  It can't be done under SCOOP, **assuming as
I did in my problem that each stage uses the results from the previous
ones so you can't rearrange the code**.

The reason for this is simple: SCOOP ties acquisition and release of
objects to entry and exit from subroutines.  Therefore, the objects
will be obtained and released LIFO; you can't release objects other
than in the opposite order you acquired them.  This avoids deadlocks,
but at the possible cost of efficiency, as in my example.

Express messages don't help.  In order to seize control of an object
prematurely, you have to cause an exception in the context of the
holder, thus destroying that context.  (Checkpoints, and other such
hacks to allow resumption of processing at the same call level as the
exception, are treated here with the disdain they deserve.)
Attempting to rebuild the context involves reacquiring all the objects
and rolling back their states[1], thus making the efficiency problem
far worse.

Nor can you say that compiler optimization should allow the implicit
release of A as soon as the last feature call on it is complete.  The
problem here is that B may call A, and the client may be depending on
that call being synchronized with the calls it itself made -- a
guarantee made by SCOOP because the call is made in the scope of the
client's routine.  In order to make that guarantee, and unless you
want to do system flow analysis, you can't release any separate
objects until all of them have been used for the last time in the
routine.

[1] This raises a serious problem in the use of challenge/yield. It is
true that the exception in the separate object being invoked allows it
to restore its invariant.  But what its client probably wants to do is
to roll back the state of the object to what it was at the entry to
the routine -- and it doesn't own the object to tell it to do that.
(You could clone the object at the top of the routine just in case,
but cloning a separate object is not my idea of fun.)

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EDrGL0.DD2@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Richie Bielak wrote:
> 
> :Samuel Tardieu wrote:
> :
> :[...]
> :> 
> :> Well, I find the corresponding Ada code readable enough:
> :> 
> :>    select
> :>       delay 0.010;               --  The 10ms you were talking about
> :>       raise Timeout_Failure;     --  Raise an exception, or do anything else
> :>                                  --  you need (use a fast version of
> :>                                  --  your computation for example).
> :>    then abort
> :>       [...your code here...]     --  This piece of code will be
> :>                                  --  aborted if it is not terminated within
> :>                                  --  the 10ms you required above.
> :>    end select;
> :> 
> :
> :That's neat. Except that a postcondition will be part of the contract
> :(i.e. specification) for the routine, so the caller will know what to 
> :expect. Your code is part of the implementation.
> 
> I agree - it's belongs in a contract.

That is trivial to provide:

function Do_Something_Within_Time_Slice (
    ...
    Duration_Before_Abort : Our_Duration_Limits := 0.010;
    ...
    ) return Whatever_Type;


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Jon S Anthony wrote:

:In article <EDrGL0.DD2@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> Richie Bielak wrote:
:> 
:> :Samuel Tardieu wrote:
:> :
:> :[...]
:> :> 
:> :> Well, I find the corresponding Ada code readable enough:
:> :> 
:> :>    select
:> :>       delay 0.010;               --  The 10ms you were talking about
:> :>       raise Timeout_Failure;     --  Raise an exception, or do anything else
:> :>                                  --  you need (use a fast version of
:> :>                                  --  your computation for example).
:> :>    then abort
:> :>       [...your code here...]     --  This piece of code will be
:> :>                                  --  aborted if it is not terminated within
:> :>                                  --  the 10ms you required above.
:> :>    end select;
:> :> 
:> :
:> :That's neat. Except that a postcondition will be part of the contract
:> :(i.e. specification) for the routine, so the caller will know what to 
:> :expect. Your code is part of the implementation.
:> 
:> I agree - it's belongs in a contract.
:
:That is trivial to provide:
:
:function Do_Something_Within_Time_Slice (
:    ...
:    Duration_Before_Abort : Our_Duration_Limits := 0.010;
:    ...
:    ) return Whatever_Type;

Sorry, I don't see how this acheives anything resembling the Eiffel contract..


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EDswrJ.Jq1@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> :> :That's neat. Except that a postcondition will be part of the contract
> :> :(i.e. specification) for the routine, so the caller will know what to 
> :> :expect. Your code is part of the implementation.
> :> 
> :> I agree - it's belongs in a contract.
> :
> :That is trivial to provide:
> :
> :function Do_Something_Within_Time_Slice (
> :    ...
> :    Duration_Before_Abort : Our_Duration_Limits := 0.010;
> :    ...
> :    ) return Whatever_Type;
>
>  Sorry, I don't see how this acheives anything resembling the Eiffel
> contract..

Who cares about the "Eiffel contract"???  The "Eiffel contract" is no
where to be seen in this sub-discussion.  BFD to the "Eiffel
contract".  The fact is, this is a contract with the client which
describes the piece of possible behavior in question.

Actually, I don't even think you can express this sort of capability
in direct Eiffel.  So, that point is moot (yes, Robert, I know this is
an abuse of "moot" :-)

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Richie Bielak wrote:
> 
> Nick Leaton wrote:
> 
> [...]
> 
> > From other posters, it seems that with life critical systems (avionics)
> > that this is an important consideration. Am I the only one who finds
> > this worrying, that systems you have to trust depend on some calculation
> > as to how the program is going to run? What happens if a new compiler
> > comes out that has a different optimisation technique?
> >
> 
> I always thought it would be nice to have postconditions of the form:
> 
>         ensure
>                 execution_time < 10 -- 10 milliseconds, let's say
> 
> So an exception would be raised if the routine took too long
> to execute.

Of course, you have to decide if "execution time" includes the time for
the postcondition (including any code that executes after the actual
test instruction)!

We usually have such measurements _outside_ the code sequence being
measured (i.e., in the scheduler).

> 
> ...richie
> 
> --
> * richieb@XYZZYnetlabs.net       - at home |  Richie Bielak        *
> * richieb@XYZZYcalfp.com         - at work |                       *
> *          Home page:   http://www.netlabs.net/hp/richieb          *
> *        "Fight software piracy, use free software!" (me)          *
> *        (Remove XYZZY  from my address before replying)           *

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Richie Bielak wrote:

:> I always thought it would be nice to have postconditions of the form:
:> 
:>         ensure
:>                 execution_time < 10 -- 10 milliseconds, let's say
           end
           ^^^
           my addition
:> 
:> So an exception would be raised if the routine took too long
:> to execute.
:
:Of course, you have to decide if "execution time" includes the time for
:the postcondition (including any code that executes after the actual
:test instruction)!

It would be the duration when the expression "execution_time" is evaluated.
There would be no statements following the assertion so it should be accurate 
enough for most purposes. If not, you can apply a small compensating adjustment 
to the relational expression:

         ensure
                 execution_time < 9.99  -- milliseconds
         end


:We usually have such measurements _outside_ the code sequence being
:measured (i.e., in the scheduler).

..in which case, you'd presumably be subject to the timing inaccuracies of 
the scheduler, anyway.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Richie Bielak wrote:
> 
> :> I always thought it would be nice to have postconditions of the form:
> :>
> :>         ensure
> :>                 execution_time < 10 -- 10 milliseconds, let's say
>            end
>            ^^^
>            my addition
> :>
> :> So an exception would be raised if the routine took too long
> :> to execute.
> :
> :Of course, you have to decide if "execution time" includes the time for
> :the postcondition (including any code that executes after the actual
> :test instruction)!
> 
> It would be the duration when the expression "execution_time" is evaluated.
> There would be no statements following the assertion so it should be accurate
> enough for most purposes. 

1. Why would there be no statements afterwards?
2. If there were assertions _before_ this one, would their time be
included?
3. How is the assumption "accurate enough" captured in an Eiffel
assertion? (_Would_
it be captured?)

> If not, you can apply a small compensating adjustment
> to the relational expression:
> 
>          ensure
>                  execution_time < 9.99  -- milliseconds
>          end

However, this compensation depends upon making assumptions of the
time it takes to do the assertions... and we want to avoid writing code
whose correctness depends upon assumptions about how fast the code runs,
right?

> 
> :We usually have such measurements _outside_ the code sequence being
> :measured (i.e., in the scheduler).
> 
> ..in which case, you'd presumably be subject to the timing inaccuracies of
> the scheduler, anyway.

But the timing inaccuracies of the scheduler are at the thread level.
Your
inaccuracies are at the object level. If a lot of objects are called in
the course of a thread's execution (or a few are called a lot of times),
your inaccuracies build. Mine don't (particularly if the start of the
thread is controlled by a high-accuracy timer/low-overhead interrupt
handler, which is typical for hard real-time systems).

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

All of the following issues become irrelevant in the context of library classes
that allow thread-based timing. See my previous post about class TIMED.


Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Ken Garlington wrote:
:> 
:> :Richie Bielak wrote:
:> 
:> :> I always thought it would be nice to have postconditions of the form:
:> :>
:> :>         ensure
:> :>                 execution_time < 10 -- 10 milliseconds, let's say
:>            end
:>            ^^^
:>            my addition
:> :>
:> :> So an exception would be raised if the routine took too long
:> :> to execute.
:> :
:> :Of course, you have to decide if "execution time" includes the time for
:> :the postcondition (including any code that executes after the actual
:> :test instruction)!
:> 
:> It would be the duration when the expression "execution_time" is evaluated.
:> There would be no statements following the assertion so it should be accurate
:> enough for most purposes. 
:
:1. Why would there be no statements afterwards?
:2. If there were assertions _before_ this one, would their time be
:included?
:3. How is the assumption "accurate enough" captured in an Eiffel
:assertion? (_Would_
:it be captured?)
:
:> If not, you can apply a small compensating adjustment
:> to the relational expression:
:> 
:>          ensure
:>                  execution_time < 9.99  -- milliseconds
:>          end
:
:However, this compensation depends upon making assumptions of the
:time it takes to do the assertions... and we want to avoid writing code
:whose correctness depends upon assumptions about how fast the code runs,
:right?
:
:> 
:> :We usually have such measurements _outside_ the code sequence being
:> :measured (i.e., in the scheduler).
:> 
:> ..in which case, you'd presumably be subject to the timing inaccuracies of
:> the scheduler, anyway.
:
:But the timing inaccuracies of the scheduler are at the thread level.
:Your
:inaccuracies are at the object level. If a lot of objects are called in
:the course of a thread's execution (or a few are called a lot of times),
:your inaccuracies build. Mine don't (particularly if the start of the
:thread is controlled by a high-accuracy timer/low-overhead interrupt
:handler, which is typical for hard real-time systems).
:
:> 
:> Don.
:> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
:> Don Harrison             donh@syd.csa.com.au



-- 
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Richie Bielak wrote:

:I always thought it would be nice to have postconditions of the form:
:
:	ensure
:		execution_time < 10 -- 10 milliseconds, let's say
:
:So an exception would be raised if the routine took too long
:to execute.

I've also been thinking along these lines since about a year ago. It sits very 
well with DBC, IMO.

Also, the idea of express messages in SCOOP caters for the situation where
a time-critical thread *must* execute without fail. 

(For more information, see Object-oriented Software Construction (2nd ed.) 
Section 30.8 - "Requesting Special Service").


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Ken Garlington]

Don Harrison wrote:
> 
> Richie Bielak wrote:
> 
> :I always thought it would be nice to have postconditions of the form:
> :
> :       ensure
> :               execution_time < 10 -- 10 milliseconds, let's say
> :
> :So an exception would be raised if the routine took too long
> :to execute.
> 
> I've also been thinking along these lines since about a year ago. It sits very
> well with DBC, IMO.

This would work if there is an inherent time limit to the object's
functionality.
It won't work if the issue is the contribution to the object to a thread
of
execution, particularly if the object is going to support multiple
threads. The
issue of specifying absolute time in an environment where objects are
reused
in future applications is also a sticking point. ADARTS does thread
timeline
analysis independently of object interface specification, which in my
experience makes more sense.

> 
> Also, the idea of express messages in SCOOP caters for the situation where
> a time-critical thread *must* execute without fail.
> 
> (For more information, see Object-oriented Software Construction (2nd ed.)
> Section 30.8 - "Requesting Special Service").
> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Ken Garlington wrote:

:Don Harrison wrote:
:> 
:> Richie Bielak wrote:
:> 
:> :I always thought it would be nice to have postconditions of the form:
:> :
:> :       ensure
:> :               execution_time < 10 -- 10 milliseconds, let's say
:> :
:> :So an exception would be raised if the routine took too long
:> :to execute.
:> 
:> I've also been thinking along these lines since about a year ago. It sits very
:> well with DBC, IMO.
:
:This would work if there is an inherent time limit to the object's
:functionality.
:It won't work if the issue is the contribution to the object to a thread
:of
:execution, particularly if the object is going to support multiple
:threads. 
:The issue of specifying absolute time in an environment where objects are
:reused
:in future applications is also a sticking point. ADARTS does thread
:timeline
:analysis independently of object interface specification, which in my
:experience makes more sense.

Actually, after reading more about SCOOP, I think you would probably use 
a different approach to implementing timed actions. You can acheive thread
based timing using predefined library classes. See the discussion of class 
TIMED in "Object-oriented Software Construction" 2nd ed. - "A watchdog 
mechanism" (P. 1019)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Nick Leaton]

Jon S Anthony wrote:
> 
> In article <33CE082E.65FF@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> 
> > Why would you want to place procedural code in an assertion? It is the
> > same as saying you want to have a side effect of a function. If it is
> 
> Unless you are using a pure functional or declarative language, you
> are writing "procedural" code.  Eiffel is about as close to either of
> these as Ada or Pascal or C.  So, if you are writing your assertions
> in Eiffel, you are writing procedural code.
> 
> If you really do want functional code - go use a _functional_ language!

Check the post I was replying too!

Procedure - does something
Function - returns the value of something.

The original post refered to have some critical procedure being placed
in an assertion, and the problem of then diasabling the assertion!


-- 

Nick

Re: Safety-critical development in Ada and Eiffel

[Joachim Durchholz]

Jon S Anthony wrote:
> Unless you are using a pure functional or declarative language, you
> are writing "procedural" code.  Eiffel is about as close to either of
> these as Ada or Pascal or C.  So, if you are writing your assertions
> in Eiffel, you are writing procedural code.
> 
> If you really do want functional code - go use a _functional_
> language!

Sorry, this is plain wrong.
Assertions are indeed considered functional ("applicative" according to
Bertrand's nomenclature) in Eiffel.
I'm pretty sure that the reason is that assertions aren't intended to do
anything - they just specify conditions that have to be true at certain
points in execution. There isn't much procedural one could (or should)
do here.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Sorry, this response is interminably long...


Warwick Pulley wrote:

:Don Harrison wrote:

:> BTW, how do call a procedure under different names in Ada?
:
:By declaring a procedure that "renames" the old one, eg...

Yes, I should have realised! It's the old workaround to the infuriating Ada83 
visibility problem of not being able to see the predefined operators of a user-defined(?) type in client code. In spite of already with-ing the 
supplier module (which I don't think you should have to do, anyway - if you 
*use* features exported by a package, explicitly importing it is redundant), 
you can't see (hence, use) the imported operators.

While Ada95 has ameliorated this restriction via the "with <type>"(?) statement,
it doesn't go far enough, IMO. Better would be removing the need for any
explicit importation of operators. Even better, IMO, would be removing explicit 
imports of everything (including packages). However, I guess the existence 
of "use" clauses would then create ambiguity problems. Never did like "use" 
clauses.

Interestingly, this issue reveals a benefit of unifying module and type. 
A unified model that dictates unique class names (eg. Eiffel's) simplifies 
things by allowing class names to serve a twofold purpose in clients - 
importing modules and entity (variable or routine parameter) declarations.
In one fell swoop, the need for import statements ("with"), visibility 
statements ("use"), and module prefixes for diambiguation disappear.

WRT renaming operations, I'm not sure whether the current semantics provide 
the same capability as Eiffel. For that to be the case, it would need to allow
synonyms in *declarations* as in the Eiffel declaration of the equality 
operator (overlooking the anchored type):

  equal, frozen standard_equal (some: ANY; other like some): BOOLEAN is..

[This declaration gives you a common declaration for a redefinable - "equal" -
and a non-redefinable operation - "standard_equal". In a mission-critical system,
where you wanted to force static binding, you could use the frozen version in 
calls and use the redefinable version to specialise when inheriting.]

A cursory glance at the Rationale - 8.3 suggests you may be able to do this 
but I'm not sure.

BTW, I recall reading somewhere in the Rationale that Ada allows some sort of
anchored type declaration. Anyone care to give an example?..


:> Yes, timing *is* something to be concerned about when applied to realtime 
:> systems. That's why I suggested not using assertions in the hard realtime
:> threads of a process. BTW, software designed using DBC may actually run *faster*
:> than code without it because you get to strip out all the defensive validity
:> checks. You have already ascertained during development that operations are
:> called in valid contexts so you don't have to check the context.
:
:In Eiffel that may be true provided that removal of assertion checks doesn't
:significantly affect the performance of the code in any way.  The issue of timing,
:mentioned by Ken above, is a good example).

Yes, that's particularly an issue in mission-critical HRT domains such as Ken's
(spacecraft(?)..). For domains where timing is less critical such as ours 
(simulators), it becomes a viable tool. I should reiterate (in case it's been 
forgotten) my original suggestion that individual threads *within* an HRT system 
may be medium RT and hence candidates for Eiffel-style contracting. This implies
an architecture in which threads may be allocated to specific processors of 
multi-processor hardware. In this way, the HRT threads can happily do their 
stuff without risk of interference from slower threads. This reality of this
scenario depends, of course, on the timing requirements of inter-thread 
communication.


:I imagine that one needs to take special care when using assertions in
:languages that don't fully support them.  

Definitely, and I would hope GNAT, for example, allows you to use assertions
without enclosing if-statements or compiler directives like 

  begin
    assert (<boolean_expression>)           -- precondition
    ...                                     -- actual body of routine
    assert (<other_boolean_expression>)     -- postcondition
  end;

and allows you to turn them on or off via a compiler switch. Is this true?


:From my (sorely lacking!!) knowledge
:of Eiffel, clauses that define the precondition and postcondition of an
:operation contain exactly one boolean statement which automatically restricts
:the coder from including procedural code within these sections.

Yes, the above would look like

  require <boolean_expression>              -- precondition
  do
    ...                                     -- actual body of routine
  ensure <other_boolean_expression>         -- postcondition
  end;


:While this argument favours Eiffel in terms of assertions, it doesn't
:mean that porting this functionality to Ada will not introduce other faults.

Sure. It's best to use a technique that minimises the risks - hence my 
expectation of what GNAT provides.


:With Don's demonstration of assertions last Friday (Jul 11 18:05:13 EST) the
:postcondition was implemented in the form:
:
:if <assertions on> and then <bool_postcondition>
:  raise <postcondition exception>
:end if;
:
:The implementation of the assertion is done with multiple statements, so
:there is the possibility of important sections of code being inadvertently
:added within the if-statement which would then be removed when assertions
:are disabled.

I agree and this certainly isn't my prefered way of emulating assertions. 
I would much prefer to use the technique I described above but doing so 
with our Ada83 Verdix compiler would require using compiler directives to 
wrap each assertions. As this, would be messy, I chose to use if-statements
where the conditional expression was a short-circuit boolean expression.
This represented a minimal risk to correctness (the first component is 
Assertions_On so the rest is ignored if set to False) and a small execution 
overhead acceptable for our medium RT domain.


:I have seen this happen at least once, where an executable was released to
:the test group which AFAIK was only tested with assertions enabled, and then
:it was discovered that a crucial line of code was removed because it was
:within an assertion block and once this error was encountered the executable
:didn't crash but its functionality was imparired severely enough so that
:it had to be run again.

I expect you are referring to my own error (actually it was two) in which 
I coded the incorrect logic. I hope you'll allow me a few mistakes. After all,
these were the only two extant miskakes following integration out of 172 
such statements. That implies 98.84% were logically correct which, you'll 
agree, isn't too bad. What this does reinforce is that assertions do not 
obviate the need for testing but are a tool to help facilitate it.

BTW, assuming what you say is correct, the assertions were turned off and 
the code handed over to the testers without my knowledge. I would have tested
it first.

:Even one error, however minor, is enough to warrant another round of
:testing after assertions are removed: at least for languages that don't
:fully support assertions.  

..*especially* for such languages.

:Even if no errors are discovered in the process
:I would consider it a worthwhile exercise, if only to convince myself that
:the software functions how I intended.

Certainly.

:A suggestion: to avoid some of these problems one could have written two
:procedures, say 'precondition' and 'postcondition', each having an 'in'
:boolean parameter.  Each procedure should do nothing if assertions are
:disabled, but if they are enabled then they would raise the appropriate
:exception if the 'in' parameter was false.
:
:Then rather than the above block, one could evaluate a postcondition
:by the call:
:
:postcondition(<bool_postcondition>);
:
:and similiarly for preconditions.  A sample implementation of 'postcondition'
:(in pseudo-Ada) is:
:
:--------------------------------------------------------------------------------
:
:procedure postcondition(requirement: in boolean) is
:begin
:
:# if <assertions on> then
:
:  -- check condition and raise exception if violated
:  if not requirement then
:    raise <postcondition exception;>
:  end if;
:
:# else
:
:  null;
:
:# end if;
:
:end postcondition;
:pragma INLINE(postcondition);
:--------------------------------------------------------------------------------
:
:So when exceptions are disabled (via a compiler directive), 'postcondition'
:would have a null body, and since it's inline there would be no unwanted
:procedure call.  It also means that you can conditionally compile
:assertions without having to surround each assertion with conditional
:compilation directives.

Neat idea. What a pity you didn't think of it back in February! Maybe we could 
use it next time if we don't have something better..


:Naturally, my suggestion above still fails to prevent the addition of code
:before a precondition check, or after a postcondition check, etc.

Yes, although the amount of self-discipline to use it effectively is small.
To eliminate that entirely, best use the real thing. :)


:Yes, if you know the compiler has a bug in the first place.  The trouble is
:that you don't know it's a problem until it occurs, and a compiler could
:have a subtle bug that only occurs in very particular circumstances.
:
:Although any respectable compiler has minimal bugs if any, if we don't test
:our products after assertions are suppressed then we unnecessarily transform
:our confidence in, into dependence on, the vendor's compiler to function
:correctly.

Sure. I suppose if anyone is going to emulate assertions in ways that may 
affected by compiler optimisations, it would be wise to become acquainted 
with these so you know what you're in for.


:It would be irresponsible to deliver software that has only been tested with
:assertions enabled, knowing that if an error occurs in the released version
:then it's "not my fault".  So for this reason, and for peace of mind, I would
:certainly test the version of the software to be delivered to the customer.
:Since we expect not to find more errors, this last phase would run smoothly
:and quickly.

Yes, I suspect this is usual practice.


:> :Another consequence of using assertions is that you have to develop and
:> :test the
:> :assertions. 
:> 
:> Correct. My initial reaction when I started using them was "Gee, I've got to
:> do this extra work on top of writing the "real" code! However, I found I was 
:> spending about a third of the time integrating compared with my colleagues
:> which meant I was saving time overall and producing more reliable code to boot.
:
:Why should a short integration period automatically imply code reliability?

Your right - this is mis-phrased. It should be:

  "However, I found I was spending about a third of the time integrating 
   compared with my colleagues which meant I was saving time overall. Despite
   spending less time integrating, my code was more reliable."


[...]

:BTW, how do you verify the correctness of your assertions, 

You already have a built-in assertion checking mechanism in the code proper
because if an assertion is incorrectly coded, it will raise an exception 
in *valid* circumstances rather than invalid ones. If you know that the 
context is correct, examination of the boolean expression cin the assertion 
will very quickly show you what the problem is. The upshot is that you have 
to think catefully about what the valid underlying assumptions are in the first
place and debug assertions that reveal incorrect assumptions or simply coding
errors.

:and that there are
:no errors that the assertions didn't find?  

You can't verify that of course. You can't express everything as an assertion
and their use doesn't obviate the need for testing. Rather, they help 
facilitate testing.

:Do you prefer code inspection,
:or if you do your verification by executing the program itself, how do you
:ensure that each section of code is exercised?  

Both of these. To ensure code coverage, I used the debugger to check that 
the right brancehes were executed in the right circumstances.

:Either way, a documentation
:of your method would provide a good test which can then be reproduced should
:the software be modified.

Yes, that would be a good idea. Not just now though - I have some test reports
to write!  :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Don said

<<Interestingly, this issue reveals a benefit of unifying module and type.
A unified model that dictates unique class names (eg. Eiffel's) simplifies
things by allowing class names to serve a twofold purpose in clients -
>>


Time to restate the following observation:

Unify and Confuse both mean at their root the same thing, namely to
make into one, or to join together, but they express a different
judgment as to the desirability of of the joining.

A lot of the arguments in PL design come doesn to whether joining concepts
together is unification or confusion:

Do expression languages unify or confuse the notion of statement and
expression?

Does Algol-68 unify or confuse the notion of reference and pointer

Does Eiffel unify or confuse the notions of module and type

TO me the answer to the last question is that it confuses, rather than
unifies, quite contrary to Don's point of view. And it is hardly worth
going through the aguments again, since there is unlikely to be anything
new said (Don certainly had nothing new to say on this issue, and neither
do I :-)

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert Dewar wrote:

:Don said
:
:<<Interestingly, this issue reveals a benefit of unifying module and type.
:A unified model that dictates unique class names (eg. Eiffel's) simplifies
:things by allowing class names to serve a twofold purpose in clients -
:>>
:
:
:Time to restate the following observation:
:
:Unify and Confuse both mean at their root the same thing, namely to
:make into one, or to join together, but they express a different
:judgment as to the desirability of of the joining.

Yes, the perspective *does* depend on a judgement of the desirability of 
unification vs. separation in any particular case considered. However, it's a
mistake to assume that a judgement is necessarily arbitrary. On the contrary, 
an informed judgement can be made on the basis of the relative pros/cons of 
each alternative. These pros and cons can be weighted on the basis of 
importance and used to construct a formula for desirability of unification/
separation. Among those qualities I would regard as important are such things 
as simplicity, reusability and reliability. Any rational person will agree 
these are important qualities in software. Pros which promote these qualities
would be heavily weighted as would be cons which compromised them.

Such a formula would provide a fairly objective basis for judgement which 
transcends the "This-is-what-I'm-used-to-so-it-must-be-better mentality".

I don't have the time to do this but it would be an instructive exercise 
given Eiffel's enhancement of the above qualities.


(Don certainly had nothing new to say on this issue, and neither
:do I :-)

There is more to say, but perhaps another day.. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Karel Th�nissen]

Don Harrison wrote:

> Interestingly, this issue reveals a benefit of unifying module and type.
> A unified model that dictates unique class names (eg. Eiffel's) simplifies
> things by allowing class names to serve a twofold purpose in clients -
> importing modules and entity (variable or routine parameter) declarations.
> In one fell swoop, the need for import statements ("with"), visibility
> statements ("use"), and module prefixes for diambiguation disappear.

Correct, that this is unified in Eiffel, but the problem is pushed
towards Lace: in Lace you do more or less the same as with and use in
Ada.

You cannot have human-friendly names for classes/components if you also
want to use classes written by third party vendors. There just is no way
to avoid vendors from using identical symbolic names for their gadgets.
So renaming and specification of classes used remains necessary.

Groeten, Karel

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

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


Karel Th�nissen wrote:

:Don Harrison wrote:
:
:> Interestingly, this issue reveals a benefit of unifying module and type.
:> A unified model that dictates unique class names (eg. Eiffel's) simplifies
:> things by allowing class names to serve a twofold purpose in clients -
:> importing modules and entity (variable or routine parameter) declarations.
:> In one fell swoop, the need for import statements ("with"), visibility
:> statements ("use"), and module prefixes for diambiguation disappear.
:
:Correct, that this is unified in Eiffel, but the problem is pushed
:towards Lace: 

Agree.

:in Lace you do more or less the same as with and use in Ada.

I would have thought it was more like just "renames".

:You cannot have human-friendly names for classes/components if you also
:want to use classes written by third party vendors. There just is no way
:to avoid vendors from using identical symbolic names for their gadgets.
:So renaming and specification of classes used remains necessary.

Agree.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Robert Dewar]

Don Harrison says

<<Yes, I should have realised! It's the old workaround to the infuriating Ada83
visibility problem of not being able to see the predefined operators of a user-d
efined(?) type in client code. In spite of already with-ing the
supplier module (which I don't think you should have to do, anyway - if you
*use* features exported by a package, explicitly importing it is redundant),
you can't see (hence, use) the imported operators.
>>


My goodness, surprising that anyone would think this, but then I guess there
are people who really prefer uncontrolled anarchy.

To me one of the real advantages in Ada is that you know right away, right
at the start of the package, exactly what services are being used, and
you can more easily excercise control over this. If you let code anywwhere
reach anywhere easily, you have a recipe for mess.

The requirement to write a with clause is also the requirement to think
about whether it is appropriate for the unit you are in to "with" the
unit that you think you need.

As for the "infuriating" Ada 83 visibility "problem". I always found this
odd. I understand that people do not like to use "use" because, especially
with poor tools, they want to be easily able to tell where somethintg
comes from, but I never understood why this perfectly understandable
reasoning does not apply to operators (personally I prefer to use "use"
most of the time anyway).

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

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

> As for the "infuriating" Ada 83 visibility "problem". I always found this
> odd. I understand that people do not like to use "use" because, especially
> with poor tools, they want to be easily able to tell where somethintg
> comes from, but I never understood why this perfectly understandable
> reasoning does not apply to operators (personally I prefer to use "use"
> most of the time anyway).

I quite agree.  What I found odd (at best) about the "use type" thing
in Ada95 was that it doesn't really "use type" - you only get the
operators - a kind of "half-use type".  IMO, this gives you the worst
of both worlds.  If it had really given you all the operations on a
type (not just those using operator syntax) it would have been a
pretty nice idea for those cases where you have more than one such
type in a package.  As it is, I find that "use" is still the clearest
thing to do...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Robert A Duff]

In article <JSA.97Jul18144029@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>I quite agree.  What I found odd (at best) about the "use type" thing
>in Ada95 was that it doesn't really "use type" - you only get the
>operators - a kind of "half-use type".

What *I* find odd is that in something like:

    while X /= null loop
        ...
        X := X.Next;
    end loop;

I can see "null" and ":=" without any use_clause, but I can't see "/=".
And if I don't like use_clauses, the way to get visibility on "/=" is to
rename "="!  (Or else to use the intolerably horrible Package_Name."/=".)
(Actually, I'm not use_clause-phobic.)

By the way, "use type" was a compromise.  The language designers
originally wanted to make primitive operators directly visible always.
But that would have been slightly upward incompatible.  So we settled on
"use type".

>...  As it is, I find that "use" is still the clearest
>thing to do...

I have mixed feelings.  But I do think it's unfortunate that both
opinions exist, because it harms reusability -- you tend to choose
different names for things in a package, depending on whether you expect
clients to use use.

Another pet peeve: In order to use Some_Package, you say "with
Some_Package;".

- Bob

Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Brian Rogoff]

On Sat, 19 Jul 1997, Robert A Duff wrote:
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >I quite agree.  What I found odd (at best) about the "use type" thing
> >in Ada95 was that it doesn't really "use type" - you only get the
> >operators - a kind of "half-use type".
> 
> What *I* find odd is that in something like:
> 
>     while X /= null loop
>         ...
>         X := X.Next;
>     end loop;

Agreed on both oddnesses.

> I can see "null" and ":=" without any use_clause, but I can't see "/=".
> And if I don't like use_clauses, the way to get visibility on "/=" is to
> rename "="!  (Or else to use the intolerably horrible Package_Name."/=".)
> (Actually, I'm not use_clause-phobic.)

Great. The discussions of whether or not to use use clauses reminds me of 
the "goto" discussion, and infix operator overloading discussions, and all 
of the other "X considered harmful" discussions. Sure, whacky use of use 
clauses can cause messes, but so can whacky use of function naming (say 
I name my "remove all files" procedure "print") and no one has suggested 
removing it and just using the untyped lamda calculus and Y combinators!
 
> By the way, "use type" was a compromise.  The language designers
> originally wanted to make primitive operators directly visible always.
> But that would have been slightly upward incompatible.  So we settled on
> "use type".

I have always wondered about this, but I never asked. Perhaps we need a 
"Design and Evolution of Ada 95" to answer some of these questions. Do 
you have the values of YY, MM, and DD that I need to find the discussion
in the mrtcomments list? I'm curious because I want to know how you all 
resolved the tension between fixing (perceived) flaws and breaking
backwards compatibility. Making primitive operators always directly visible 
seems like the right approach; what would the extent of the
incompatibility have been? Personally, I don't like "use type", and think
it was a mistake, but my mind has been changed on important Ada issues 
(downard funargs :-) after I read the discussions.

> Another pet peeve: In order to use Some_Package, you say "with
> Some_Package;".

I don't get it. Do you disagree with the choice of names for "with" and
"use", with the fact that "use" doesn't implicitly "with", or something 
else altogether? 

-- Brian

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert A Duff]

In article <Pine.SGI.3.95.970720110809.28934A-100000@shellx.best.com>,
Brian Rogoff  <bpr@shellx.best.com> wrote:
>I have always wondered about this, but I never asked. Perhaps we need a 
>"Design and Evolution of Ada 95" to answer some of these questions. Do 
>you have the values of YY, MM, and DD that I need to find the discussion
>in the mrtcomments list?

No, sorry, but I have enough trouble remembering both Ada 83 and Ada 95,
without trying to remember all the steps in between, and their dates.
;-)  The Ada 83 brain cells have already started to decay.

I'm not sure, but if somebody wanted to dig, they could probably find
all kinds of useful historical stuff somewhere on
sw-eng.falls-church.va.us.  Mrtcomments, old "Mapping Issues" and
"Mapping Documents", minutes of ARG, XRG, and WG9 meetings, etc.  It
would be a lot of work to track it all down.  In some cases, the AARM
retains historical information ("We considered so-and-so, but then
changed our collective mind, because...").

>> Another pet peeve: In order to use Some_Package, you say "with
>> Some_Package;".
>
>I don't get it. Do you disagree with the choice of names for "with" and
>"use", with the fact that "use" doesn't implicitly "with", or something 
>else altogether? 

The choice of names.  "With" should be "use" or "uses" (the latter is
from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
something other than "use".  Then, when I say, "Package X uses package
Y", you wouldn't be confused as to whether I mean "Package X makes use
of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
package X saying 'use Y'".  And we avoid the verbing of "with", as in
"Package X withs package Y." (or is it "with's"?) which sounds horrible
in English.  "To with" ain't a verb, in English.  ;-)

- Bob

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Brian Rogoff]

On Mon, 21 Jul 1997, Robert A Duff wrote:
> In article <Pine.SGI.3.95.970720110809.28934A-100000@shellx.best.com>,
> Brian Rogoff  <bpr@shellx.best.com> wrote:
> >I have always wondered about this, but I never asked. Perhaps we need a 
> >"Design and Evolution of Ada 95" to answer some of these questions. Do 
> >you have the values of YY, MM, and DD that I need to find the discussion
> >in the mrtcomments list?
> 
> No, sorry, but I have enough trouble remembering both Ada 83 and Ada 95,
> without trying to remember all the steps in between, and their dates.
> ;-)  The Ada 83 brain cells have already started to decay.

Its OK, there is a lot of stuff. I remember during the downward funarg
debate that Norman Cohen managed to point out those MRT douments; that 
was a much more important "battle" and it was important to read the 
discussions (even though I still pine for a properly tail recursive Ada 
with downward funargs :-)
> 
> I'm not sure, but if somebody wanted to dig, they could probably find
> all kinds of useful historical stuff somewhere on
> sw-eng.falls-church.va.us.  Mrtcomments, old "Mapping Issues" and
> "Mapping Documents", minutes of ARG, XRG, and WG9 meetings, etc.  It
> would be a lot of work to track it all down.  In some cases, the AARM
> retains historical information ("We considered so-and-so, but then
> changed our collective mind, because...").

This stuff should be HTML-ified for future generations. 

> >I don't get it. Do you disagree with the choice of names for "with" and
> >"use", with the fact that "use" doesn't implicitly "with", or something 
> >else altogether? 
> 
> The choice of names.  "With" should be "use" or "uses" (the latter is
> from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
> something other than "use".  Then, when I say, "Package X uses package
> Y", you wouldn't be confused as to whether I mean "Package X makes use
> of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
> package X saying 'use Y'".  And we avoid the verbing of "with", as in
> "Package X withs package Y." (or is it "with's"?) which sounds horrible
> in English.  "To with" ain't a verb, in English.  ;-)

OK, I guess I thought about it a bit, but got used to it quickly. Spelling 
issues don't bug me as much as semantic issues. 

-- Brian

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Morgan Palaeo Associates]

bobduff@world.std.com (Robert A Duff) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Another pet peeve: In order to use Some_Package, you say "with
>>> Some_Package;".
>>
>>I don't get it. Do you disagree with the choice of names for "with" and
>>"use", with the fact that "use" doesn't implicitly "with", or something
>>else altogether?
>
>The choice of names.  "With" should be "use" or "uses" (the latter is
>from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
>something other than "use".  Then, when I say, "Package X uses package
>Y", you wouldn't be confused as to whether I mean "Package X makes use
>of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
>package X saying 'use Y'".  And we avoid the verbing of "with", as in
>"Package X withs package Y." (or is it "with's"?) which sounds horrible
>in English.  "To with" ain't a verb, in English.  ;-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

use X; view X;

-- Adrian Morgan

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Jon S Anthony]

In article <5r64cq$meh@peg.apc.org> morganpalaeo@peg.apc.org (Morgan Palaeo Associates) writes:

> bobduff@world.std.com (Robert A Duff) wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> >The choice of names.  "With" should be "use" or "uses" (the latter is
> >from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
> >something other than "use".  Then, when I say, "Package X uses package
> >Y", you wouldn't be confused as to whether I mean "Package X makes use
> >of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
> >package X saying 'use Y'".  And we avoid the verbing of "with", as in
> >"Package X withs package Y." (or is it "with's"?) which sounds horrible
> >in English.  "To with" ain't a verb, in English.  ;-)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> use X; view X;

uses X;  localize X;  -- ?? (as in "local phone call")

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Karel Th�nissen]

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


Anonymous wrote:

> > > >The choice of names.  "With" should be "use" or "uses" (the latter is
> > > >from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
> > > >something other than "use".  Then, when I say, "Package X uses package
> > > >Y", you wouldn't be confused as to whether I mean "Package X makes use
> > > >of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
> > > >package X saying 'use Y'".  And we avoid the verbing of "with", as in
> > > >"Package X withs package Y." (or is it "with's"?) which sounds horrible
> > > >in English.  "To with" ain't a verb, in English.  ;-)


> > > use X; view X;

> > uses X;  localize X;  -- ?? (as in "local phone call")
 
> To avoid new resoived woids:
 
> use X; access X;
> use X;     in X; -- Pretend this code is "in" X
> use X;  raise X; -- "raise" the visibility of X
 
> With a new reserved word:
 
> use X; open X;

use X; tutoie X; -- pays tribute to Jean Ichbiah
use X; dutche x; -- for the Germans ('Dutchen' is to be on informal
terms wso)
use X; intimate X;


-- 
Groeten, Karel Th�nissen

Member of the international brigade against Anglo-American cultural
imperalistic denial of the diacritical marks 8-)

-- my e-mail address is scrambled to confuse spammers
-- remove the confusion to obtain my true address

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[J-P. Rosen]

jsa@alexandria.organon.com (Jon S Anthony) wrote:

>In article <5r64cq$meh@peg.apc.org> morganpalaeo@peg.apc.org (Morgan Palaeo Associates) writes:

>> bobduff@world.std.com (Robert A Duff) wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >
>> >The choice of names.  "With" should be "use" or "uses" (the latter is
>> >from UCSD Pascal, I think).  "Use" should be I-don't-know-what, but
>> >something other than "use".  Then, when I say, "Package X uses package
>> >Y", you wouldn't be confused as to whether I mean "Package X makes use
>> >of package Y (i.e. X is a client of Y)", versus "There's a use_clause on
>> >package X saying 'use Y'".  And we avoid the verbing of "with", as in
>> >"Package X withs package Y." (or is it "with's"?) which sounds horrible
>> >in English.  "To with" ain't a verb, in English.  ;-)
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> 
>> use X; view X;

>uses X;  localize X;  -- ?? (as in "local phone call")

I do not agree. When I go walking, I take some food WITH me. I open the box
when I want to USE it.

The whole idea of the use clause is that often, you don't need a  withed
package everywhere. If I write -say- a complex number package with a Put
function, I have to with Text_IO; however I use it only in the Put
function. The use clause is intended to do just that: open visibility only
in places where the package is really used.

This means that in general, it is a bad idea to put the use clause on top
of the pakage, except if you really use the package everywhere.
Unfortunately, this was the case for every example in RM83, and people
tended to do it systematically, and then complained that things got visible
even when not used...

For more details, refer to "In defense of the USE clause" in Ada letters,
Nov. 87.

This note is NOT intended to restart the old debate about the use clause
;-)
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
NEW ! Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert A Duff]

In article <5rrr5a$dds$2@peuplier.wanadoo.fr>,
J-P. Rosen <Rosen.Adalog@wanadoo.fr> wrote:
>I do not agree. When I go walking, I take some food WITH me. I open the box
>when I want to USE it.
>
>The whole idea of the use clause is that often, you don't need a  withed
>package everywhere. If I write -say- a complex number package with a Put
>function, I have to with Text_IO; however I use it only in the Put
           ^^^^^^^^^^^^^^^^^^^^^^
>function. The use clause is intended to do just that: open visibility only
>in places where the package is really used.

Perhaps you mean, "I have to take Text_IO WITH me."  ;-)
At least that's syntactically correct English, unlike "I have to with
Text_IO".  (Either way, I don't mind anthropomorphizing the code.)

To me, "Package Complex_Numbers uses Text_IO" and "Package
Complex_Numbers uses Text_IO only within its Put procedure" and
"Procedure Complex_Numbers.Put uses Text_IO" all make sense in plain
English, and do not necessarily imply a use_clause.  I mean, one way to
use Text_IO is to say "Text_IO.Put(...)".

>THIS means that in general, it is a bad idea to put the use clause on top
>of the pakage, except if you really use the package everywhere.
>Unfortunately, this was the case for every example in RM83, and people
>tended to do it systematically, and then complained that things got visible
>even when not used...
>
>For more details, refer to "In defense of the USE clause" in Ada letters,
>Nov. 87.
>
>This note is NOT intended to restart the old debate about the use clause
>;-)

Hmm.  *I* was just complaining about the reserved word used.  *You're*
the one who inserted the above arguments about if/when it's good to use
these features.

- Bob

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert Dewar]

I must say that the debate about keywords for with/use is about the most
convincing argument I have seen that this choice was reasonable. I find
all the substitutions proposed uniformly MUCH worse than the original,
and some of them are really horrid.

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert Dewar]

Brian says

<<incompatibility have been? Personally, I don't like "use type", and think
it was a mistake, but my mind has been changed on important Ada issues
(downard funargs :-) after I read the discussions.
>>


If you think "use type" was a mistake you have to tell us

(a) why you think that using "use type" makes programs harder to read. We
are not particularly interested if your main reason for thinking it is a
mistake is that it makes programs a (little bit) harder to write.

(b) you have to suggest an alternative. Making operators automatically
visible is not just a serious incomaptibility with Ada 83, it is also
a significant design shift. The intention in Ada is very deliberately
that things are NOT directly visible unless either used, or declared
in the current unit. Violating this principle is not something to be
done lightly, and again, you would have to explain why a change here
would make it easier to read programs.

I think you can certainly argue that "use type" *does* make programs easier
to read, since it is far less syntactic burden on the reader than the
alternatives which in practice people have otherwise used:

  (a) using prefix notation as in "and"(a,b)

  (b) introducing renamings all over the place

Of course there are schemes even in Ada 83 of providing separate
packages containing the renamings and using these, but that also
clutters the program (though less than a and b).

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Brian Rogoff]

On 21 Jul 1997, Robert Dewar wrote:
> Brian says
> 
> <<incompatibility have been? Personally, I don't like "use type", and think
> it was a mistake, but my mind has been changed on important Ada issues
> (downard funargs :-) after I read the discussions.
> >>

> If you think "use type" was a mistake you have to tell us
> 
> (a) why you think that using "use type" makes programs harder to read. We
> are not particularly interested if your main reason for thinking it is a
> mistake is that it makes programs a (little bit) harder to write.

It doesn't.

> (b) you have to suggest an alternative. Making operators automatically
> visible is not just a serious incomaptibility with Ada 83, it is also
> a significant design shift. The intention in Ada is very deliberately
> that things are NOT directly visible unless either used, or declared
> in the current unit. Violating this principle is not something to be
> done lightly, and again, you would have to explain why a change here
> would make it easier to read programs.

Well, why introduce it at all, when a use clause will use-ually suffice? 
It doesn't seem to me (I like regular old use) that it buys you anything, 
and you end up treating the primitive operators as "special", something 
which you said you didn't like. So I retreat from the position of
advocating making primitive operators always visible, but continue to think 
of use type as useless, and use use. 
 
-- Brian

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert Dewar]

Brian said

<<Well, why introduce it at all, when a use clause will use-ually suffice?
It doesn't seem to me (I like regular old use) that it buys you anything,
and you end up treating the primitive operators as "special", something
which you said you didn't like. So I retreat from the position of
>>


OK, I understand where you are coming from. But the fact of the matter is
that there are many, even a clear majority, of Ada users who will not use
full-blown use no matter what, and yet they desparately want to be able
to use operators without qualification and without having to rename them.

The use of "use type" is clearly preferable to either prefix notation or
to having stacks of renaming declarations around the place.

Given this very common viewpoint, I see no good argument *against*
the introduction of use type from a pragmatic point of view. In terms
of language design, I agree that the issue remains moot.

Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel)

[Robert Dewar]

Brian said

<<I have always wondered about this, but I never asked. Perhaps we need a
"Design and Evolution of Ada 95" to answer some of these questions. Do
you have the values of YY, MM, and DD that I need to find the discussion
in the mrtcomments list? I'm curious because I want to know how you all
resolved the tension between fixing (perceived) flaws and breaking
backwards compatibility. Making primitive operators always directly visible
seems like the right approach; what would the extent of the
incompatibility have been? Personally, I don't like "use type", and think
it was a mistake, but my mind has been changed on important Ada issues
(downard funargs :-) after I read the discussions.
>>


I don't understand the motivation at all behind making an exception
for primitive operators. I still don't see why people have such a
different view of

  Add (x, y)

and

  x + y

I appreciate (though usually do not agree with) the position that everything
must be dotted so you can see where it came from in the absence of tools
to identify defining occurrences easily.

But I do not see why the above two examples strike people as so different.
To me the infix notation is simply minor syntactic sugar for the function
call. Minor from a semantic point of view.

I understand that people like the convenience of infix notation, but if
you really believe that dots are needed so that the maintainer knows
exactly where everything comes from, then why the exception?

If your principle is on the other hand: use dots where needed for clarity
(and I have some ideas of what this means). Then why not use "use" clauses
and dot where you want, and don't dot where you don't want.

Sure that is a bit more of a burden on the writer, who has to understand
the principles of when dots are or are not required, but not on the
reader, and it is the reader we are concerned with.

Why not use "use" systematically, and then have the compiler or some other
tool enforce whatever restriction you want on the use of undotted
references.

Note that a pragma like

  pragma Restrictions ("Dot_Where_Required_By_ACME_Tools_Conventions")

is a perfectly valid one.

Re: Safety-critical development in Ada and Eiffel

[W. Wesley Groleau x4923]

> Another pet peeve: In order to use Some_Package, you say "with
> Some_Package;".

I've often wondered whether the choice of "with" and "use" has any
relationship with the fact that one of the (losing) design teams was
the maintainer of UCSD Pascal.  In UCSD Pascal, "use" means EXACTLY
what "with" means in Ada, and Pascal's "with" is superficially similar
to Ada's "use"

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Robert Dewar wrote:

:Don Harrison says
:
:<<Yes, I should have realised! It's the old workaround to the infuriating Ada83
:visibility problem of not being able to see the predefined operators of a user-d
:efined(?) type in client code. In spite of already with-ing the
:supplier module (which I don't think you should have to do, anyway - if you
:*use* features exported by a package, explicitly importing it is redundant),
:you can't see (hence, use) the imported operators.
:>>
:
:
:My goodness, surprising that anyone would think this, but then I guess there
:are people who really prefer uncontrolled anarchy.

No, that's what you get when you don't practise formal software engineering
where you need it. :)

However, your view is quite justified in the case of Ada which doesn't support 
well-specified, safe-to-use software components to the extent that Eiffel 
does. In view of this, you're quite justified in perceiving a need to document 
in one place all the modules used by another. In contrast, because Eiffel 
*does* support safe reuse of components, it isn't as important to separately 
document the modules used.

In any case, if you really want this in Eiffel, it's trivial to write an 
extraction tool to produce it. Implementations may already provide this.

:To me one of the real advantages in Ada is that you know right away, right
:at the start of the package, exactly what services are being used, 

See above.

:and you can more easily excercise control over this. 

This is not true unless you have a CM tool which allows you to separately
control the with-clauses of a package body and the rest of the body. I think
most will agree this would be ridiculous.

:If you let code anywwhere
:reach anywhere easily, you have a recipe for mess.

I agree for Ada. I don't agree for Eiffel which gives you a high level of 
confidence that you can reuse with impunity. Reusing certain modules may 
happen to be nonsensical but that's a design issue - not a reuse issue - and 
irrelevant to this argument.

:The requirement to write a with clause is also the requirement to think
:about whether it is appropriate for the unit you are in to "with" the
:unit that you think you need.

I disagree. An Eiffel software engineer thinks about this when they *use* a 
module. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EDnA6M.FGx@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> in one place all the modules used by another. In contrast, because
> Eiffel *does* support safe reuse of components, it isn't as
> important to separately document the modules used.

???  I don't think so.


> :If you let code anywwhere
> :reach anywhere easily, you have a recipe for mess.
> 
> I agree for Ada. I don't agree for Eiffel which gives you a high
> level of confidence that you can reuse with impunity. Reusing
> certain modules may happen to be nonsensical but that's a design
> issue - not a reuse issue - and irrelevant to this argument.

Come on Don, this problem is in Eiffel as well - it just doesn't offer
any support to fix it.  You have to punt out to something like LACE
which is just a hack.  A hack that works, but a hack nonetheless.

> :The requirement to write a with clause is also the requirement to think
> :about whether it is appropriate for the unit you are in to "with" the
> :unit that you think you need.
> 
> I disagree. An Eiffel software engineer thinks about this when they
> *use* a module.

Irrelevant.  The point is you can't just have "classes" - they do not
support large scale structures.  That's a bit part of why there even
is a LACE for crying out loud.


[[Aside: You know, Eiffel is a fairly decent language - not great, but
decent.  I'm with Brian Rogoff on this - all programming languages
suck.  And Eiffel sucks less than some but definitely more than
others.  IMO, it clearly sucks more than Ada, but people can disagree
on this as they both suck.  The big problem here is simply that many
Eiffel folk act as if it's a religion and sound very similar to the
sort of Ada fanatic that you used to run into.]]

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Brian Rogoff]

On 21 Jul 1997, Jon S Anthony wrote:

> In article <EDnA6M.FGx@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
> > I agree for Ada. I don't agree for Eiffel which gives you a high
> > level of confidence that you can reuse with impunity. Reusing
> > certain modules may happen to be nonsensical but that's a design
> > issue - not a reuse issue - and irrelevant to this argument.
> 
> Come on Don, this problem is in Eiffel as well - it just doesn't offer
> any support to fix it.  You have to punt out to something like LACE
> which is just a hack.  A hack that works, but a hack nonetheless.

	I am still amazed at this entire module class unification thing, 
but I think it is noteworthy that many languages which started their lives
without module systems acquired them, for example Perl, C++, Lisp, ML
dialects, etc. Sather, which began as an Eiffel knock off, will eventually
get one I've been told. Even Eiffel has one, it's just not standardized. 

	I think I can live with a language without an object system, but 
I'd have a much harder time living without modules distinct from types.

-- Brian

Re: Safety-critical development in Ada and Eiffel

[Alan Brain]

Don Harrison wrote:
>
> As an example, in our simulation, we have a vehicles object. This is implemented
> as an array of records (they should be variant records discriminated
> on validity, however..). Vehicles are activated and deactivated during the
> course of a "game" by setting a validity flag. I added preconditions to ensure
> that other attributes (such as heading) were not queried unless the vehicle was
> active. These simple checks caught a whole bunch of errors that may otherwise
> have gone unnoticed. In the absence of such a check, the problem may only
> have come to our attention if spurious behaviour was observed. 

Your experience parallels my own, even to the problem domain (I used to
work for STN Atlas Elektronik GmbH of Bremen, Germany makers of fine
machines-that-go-ping)

The difference is that we _did_ use descriminant records. Something
along the lines of:

type TRACK_RECORD_TYPE ( IS_VALID : boolean ) is
record
  case IS_VALID is
    when false => null;
    when true  =>
      -- a whole heap of information
      -- such as relative bearing, time last updated, etc etc
      -- references to threat library, access types to FRAZ and DEMON
grams
      -- and so on.
  end case;
end record;

-- assume you have a declared index type TRACK_INDEX_TYPE, typically a
-- subtype of integer rather than anonymous, and with a range of about
1..1024

type TRACK_STORE_TYPE is array ( TRACK_INDEX_TYPE ) of
TRACK_RECORD_TYPE;

-- Then just declare however many track stores you need of this type...

In use, of course, this meant that unless you made sure that the track
was valid, an exception would be raised. Forex:

 if TRACK_STORE(THIS_TRACK).IS_VALID then
  -- do whatever is needed, the track is valid, so all the fields exist
 end if;

If you missed out this test, then at run time, you'd get an exception
raised,
caused by the fact that if the track ain't valid, then such items as
relative
bearing etc are undefined, irrelevant, and just plain don't exist. Using
this
method, it's just not possible to assign a speed or whatever to an
invalid track.

I realise you know all this (at least in theory) but this is to confirm
that it works in practice too. Many errors were caught this way.

Any reason why descriminant records weren't used in you project? 

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Alan Brain wrote:

:Don Harrison wrote:
:>
:> As an example, in our simulation, we have a vehicles object. This is implemented
:> as an array of records (they should be variant records discriminated
:> on validity, however..). Vehicles are activated and deactivated during the
:> course of a "game" by setting a validity flag. I added preconditions to ensure
:> that other attributes (such as heading) were not queried unless the vehicle was
:> active. These simple checks caught a whole bunch of errors that may otherwise
:> have gone unnoticed. In the absence of such a check, the problem may only
:> have come to our attention if spurious behaviour was observed. 
:
:Your experience parallels my own, even to the problem domain (I used to
:work for STN Atlas Elektronik GmbH of Bremen, Germany makers of fine
:machines-that-go-ping)
:
:The difference is that we _did_ use descriminant records. Something
:along the lines of..

[example and explanation of contracting benefits elided]

I agree the technique you describe is a useful one for enhancing reliability.
In fact we *did* use this form of contracting (for that is what it is) liberally
and found it very useful.  

:I realise you know all this (at least in theory) but this is to confirm
:that it works in practice too. Many errors were caught this way.
:
:Any reason why descriminant records weren't used in you project? 

They weren't used in this specific object only due to the restricted scope of 
the rewriting activity. There was initially a high degree of paranoia 
about reworking functionality that was deemed out-of-scope. However, it was 
clear that the benefits (in terms of increased reliablity and maintainability
and of meeting a tight schedule) meant that reworking some supposedly 
out-of-scope code was worthwhile. Where I considered reliability and timeliness
(resulting from reduced debugging time) was likely to be enhanced rather than 
compromised, I stepped outside our charter and simplified code. Previous 
experience with this simulation helped in this regard.

This strategy paid off in that a reliable foundation was laid down for higher 
level modules to build on. This was important in light of the generally low 
initial domain experience of team members with this simulation (a Hull-Mounted 
Sonar + its Operator Console). By applying assertions to low-level objects, 
correct usage in higher level modules was enforced which enhanced overall 
reliability. A significant number of errors were identified as a result of 
this strategy. 


[Alan, I visited Le Rendezvous where we used to have pizza when we were at C3.
Unfortunately, it's gone glitzy. What a shame! In the 11 years since then 
I still haven't found a Mexicana to match theirs.]


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Alan Brain]

Don Harrison wrote:

> [Alan, I visited Le Rendezvous where we used to have pizza when we were at C3.
> Unfortunately, it's gone glitzy. What a shame! In the 11 years since then
> I still haven't found a Mexicana to match theirs.]

You might try Alex Cordobes in City Rd, Newtown.

It appears to me that the difference between Ada-95 and Eiffel is like
the difference between Airbags and Seatbelts. Both are great compared
with having neither. So it is with Pizzas, Cordobes or Le Rendezvous =
matter of opinion, but it's objectively provable that either are far
better than, say, Pizza the Hutt. 

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Alan Brain wrote:

:Don Harrison wrote:
:
:> [Alan, I visited Le Rendezvous where we used to have pizza when we were at C3.
:> Unfortunately, it's gone glitzy. What a shame! In the 11 years since then
:> I still haven't found a Mexicana to match theirs.]
:
:You might try Alex Cordobes in City Rd, Newtown.

Thanks. I'll bear that in mind.

:It appears to me that the difference between Ada-95 and Eiffel is like
:the difference between Airbags and Seatbelts. 

I'm paranoid - I'd like an airbag (static typing etc.) *and* a seatbelt 
(DBC etc.)!  :)

:Both are great compared
:with having neither. So it is with Pizzas, Cordobes or Le Rendezvous =
:matter of opinion, but it's objectively provable that either are far
:better than, say, Pizza the Hutt. 

:)  Absolutely!


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <EDquzz.EK4@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> :It appears to me that the difference between Ada-95 and Eiffel is like
> :the difference between Airbags and Seatbelts. 
> 
> I'm paranoid - I'd like an airbag (static typing etc.) *and* a seatbelt 
> (DBC etc.)!  :)

Actually, I think you have that backwards: seatbelts (typing, system
validity, etc.) and airbag (DBC).  Just like where airbags are noted
as being somewhat useful when used with seatbelts, but not
particularly useful (even dangerous) without seatbelts.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Safety-critical development in Ada and Eiffel

[Don Harrison]

Jon S Anthony wrote:

:In article <EDquzz.EK4@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> :It appears to me that the difference between Ada-95 and Eiffel is like
:> :the difference between Airbags and Seatbelts. 
:> 
:> I'm paranoid - I'd like an airbag (static typing etc.) *and* a seatbelt 
:> (DBC etc.)!  :)
:
:Actually, I think you have that backwards: seatbelts (typing, system
:validity, etc.) and airbag (DBC).  Just like where airbags are noted
:as being somewhat useful when used with seatbelts, but not
:particularly useful (even dangerous) without seatbelts.

Yes, quite true. If I *had* to choose between static typing and DBC, I would 
choose static typing.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Safety-critical development in Ada and Eiffel

[Alan Brain]

Jon S Anthony wrote:
> 
> In article <EDquzz.EK4@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
> 
> > :It appears to me that the difference between Ada-95 and Eiffel is like
> > :the difference between Airbags and Seatbelts.
> >
> > I'm paranoid - I'd like an airbag (static typing etc.) *and* a seatbelt
> > (DBC etc.)!  :)
> 
> Actually, I think you have that backwards: seatbelts (typing, system
> validity, etc.) and airbag (DBC).  Just like where airbags are noted
> as being somewhat useful when used with seatbelts, but not
> particularly useful (even dangerous) without seatbelts.

Whatever. His point is that either is preferrable to having none, and
having both is better than having either. A point I am in complete
agreement with.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Safety-critical development in Ada and Eiffel

[Jon S Anthony]

In article <33D990D1.26CD@dynamite.com.au> Alan Brain <aebrain@dynamite.com.au> writes:

> Whatever. His point is that either is preferrable to having none, and
> having both is better than having either. A point I am in complete
> agreement with.

As you say, whatever...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Richard Kenner]

In article <slrn5s1132.hf1.abo@minkirri.apana.org.au> abo@minkirri.apana.org.au (Donovan Baarda) writes:
>As a matter of interest, were the extensions added to the gcc backend for
>Ada and Fortran merged and added to the gcc back end in general, or are
>they mantained seperately as language specific backends?

The changes to GCC for Ada were quite small and were put into the general
GCC distribution quite a long time ago.

There have not been any changes (aside from bug fixes) required for
Fortran.  There are some bouncing around, but they haven't yet reached
the level of being officially suggested for inclusion in GCC.

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Dale Pontius]

In article <mheaney-ya023680000207972142310001@news.ni.net>,
        mheaney@ni.net (Matthew Heaney) writes:
>
> It is my understanding that because of Cs aggressive use of type-casting,
> optimizations are actually more difficult to make than in Ada, where more
> semantic information is given to the compiler (because of the richness of
> its type system), thus allowing better optimization than is possible for C.
>
But I have this annoying feeling that the programming community is
accustomed to optimizing C, even if it is difficult. Even though
Ada gives more information to the compiler that can be used to
optimize code, I have a feeling compiler writers aren't used to
using that information, and don't. (or at least not much.)

Fortunately, Java may help this situation. In terms of optimization
Java is closer to Ada than C, and there is tremendous pressure to
improve Java performance. As compiler technology develops to optimize
Java, it will be applicable to Ada as well.

Yep, Ada was here sooner. But it doesn't command the market attention
that C, C++, and Java do. So strong-typing-assisted optimization may
be late, but at least it's coming.

Dale Pontius
(NOT speaking for IBM)

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Samuel Mize]

In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
Donovan Baarda <abo@minkirri.apana.org.au> wrote:
>One of the things that can make Ada pretty inefficient is its pass by copy
>mechanism. This means that 'in out' parameters have to be copied twice,
>once on calling the procedure, and once again on return. I believe that it
>can add extra overheads even for 'in' and 'out' parameters. For large
>array parameters, this can be a killer.

Sorry, this is erroneous.  Ada's "in out" parameters can be passed by
copy OR by reference, as appropriate for efficiency.  Ada 95 provides
specific rules to make the behavior a little more predictable, but
pass-by-reference is certainly available for anything larger than
a pointer.


>The biggest problem with Ada compared to C, is the language is so complex.
>The compiler writers have such a hard time just getting it to work that
>they hardly get around to putting in optimisation. C is so small that
>compiling it is easy, so more effort gets spent on optimization. 

Ada 83 compiler vendors did use this excuse, but Ada 95 brought the ACT
people and some other skilled compiler vendors into the Ada domain.  You
can now get inexpensive Ada compilers that optimize very well -- certainly
well enough for real-time flight simulators, for example (with full flight
dynamics, complete cockpit and out-the-window graphics, I mean -- we're
not talking Microsoft Flight Simulator here).


>I find it hard to believe that there are people who advocate Ada purely on
>language merits. As a language, Ada sucks.
...
>Where Ada wins is in a combination of language merits...

Interesting perspective.

You might check out the advocacy materials at http://www.adahome.com, if
you want to see why people advocate the use of Ada.  Here's a quick take:

I would advocate Ada for traditional or object-oriented development tasks
with any of the following characteristics:
* large scale (large team, or a small team for a long duration)
* high reliability required
* multiprocessing needed
* tight real-time requirements
* reusing a lot of "legacy" code

When would I *not* use Ada?  Well, for a graphical user interface, I
wouldn't use *any* language directly, I'd use a UI tool.  For some
database programs you can use a "fourth-generation" language (a tool
that generates the UI and the supporting query language).  For logic,
functional or data-flow programming, you need a specialized language.
For a rule-based expert system, you'd use an expert system shell.

Some people in the object-oriented world prefer other languages, but
most of these haven't had/made a chance to evaluate Ada 95's tagged
types yet.  Certainly for a mixed object/functional development
approach, Ada hammers the opposition.

Note also that there are UI tools and expert system shells that
use Ada as their implementation language.

But I'm not arguing that you should like Ada, just that it isn't
a bad choice.  Preference are inarguable.

Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[Larry Kilgallen]

Organization: LJK Software
Lines: 26

In article <slrn5rq1gc.che.abo@minkirri.apana.org.au>, abo@minkirri.apana.org.au (Donovan Baarda) writes:
> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:

>>Also, at least a couple of other compiler vendors in the real-time market
>>have purchased Intermetric's Ada-Magic front end, so that they too can
>>spend their time on optimization, because they were able to buy the front
>>end off the shelf.
>>
> what this also means is the front end is non-trivial, and they were better
> off paying someone else a fortune for it than developing their own.

I, for one, would not equate "trivial" with "good".

At least one of the companies which paid "a fortune" managed to
price the resultant compiler low enough that I can afford it, so
what their total cost was does not concern me (since I have no
intention of getting into the compiler business :-).

Buying from someone else rather than "developing their own"
is what one would call "re-use".  I thought software "re-use"
was one of the _favored_ buzz-words this year.  Of course whether
"re-use" is good or not certainly depends on the quality of the
code which is being re-used.  Presumably those who paid "a fortune"
evaluated the quality of the code before they opened their wallet.

Larry Kilgallen

Re: The stupidity of all the Ariane 5 analysts.

[Joerg Rieling]

hi all,

ok, i perfectly agree with some of the points you made concerning
inherent robustness etc etc etc.

but, a minimum requirement for any software is to test it under
sufficiently realistic conditions, isn't it ?   if the responsible
software engineers would have fed _simulated_ data containing some
information about the trajectory into their programs, they could
(would) have found the  bug, d'accord ?
sometimes experimental programming is not the worst choice ...

bye

j"org.

--
<---->


(- PGP key available.-)

Re: The stupidity of all the Ariane 5 analysts.

[Robert S. White]

In article <5ta2e6$itn$1@enterprise.desy.de>, joerg@hera-b.desy.de says...
>
>but, a minimum requirement for any software is to test it under
>sufficiently realistic conditions, isn't it ?   if the responsible
>software engineers would have fed _simulated_ data containing some
>information about the trajectory into their programs, they could
>(would) have found the  bug, d'accord ?

  That has been _exactly_ one of my positions as an INS (IRS) 
practitioner!  Who exactly are you addressing your comments to?  BM, 
JY, or DH?  The other problem, as pointed out, has been that there 
was software re-use without a correct analysis of its suitability 
by problem domain experts.  A system requirements review with the 
involvement of the right problem domain experts _could_ have 
determined by analysis whether the Ariane 4 IRS software should 
have been reused as is.  The failsafe for this review _should_ have
been proper simulation testing as you describe.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: The stupidity of all the Ariane 5 analysts.

[Marin David Condic, 561.796.8997, M/S 731-96]

Joerg Rieling <joerg@HERA-B.DESY.DE> writes:
>but, a minimum requirement for any software is to test it under
>sufficiently realistic conditions, isn't it ?   if the responsible
>software engineers would have fed _simulated_ data containing some
>information about the trajectory into their programs, they could
>(would) have found the  bug, d'accord ?
>sometimes experimental programming is not the worst choice ...
>
    This is exactly the point that has so many people torqued off
    about the whole debate. (Especially those of us who actually build
    this sort of software for a living.) The claim seems to be on the
    table that a) Existing software development practices are
    insufficient for developing safe software and b) the only way to
    be sure that you don't blow up a rocket is to use Design By
    Contract as exemplified by Eiffel.

    The problem is - as those of us in the business know - existing
    practices, HAD THEY BEEN FOLLOWED, would have caught the problem.
    (Your example of testing the software across the expected flight
    envelope.) So would lots of other existing practices. The problem
    is that the human beings in charge of the process didn't follow
    the usual and customary procedures (probably under cost and
    schedule pressure). Hence, no technology would likely have helped
    keep them out of the Gulag they are now most likely consigned to.
    (It's sad too for those of us who have ever experienced the "Hurry
    up and get it done no matter what the risk..." pressure that can
    be brought onto a project.)

    DBC and Assertions, in my not so humble opinion, would have proven
    to make no significant difference in the situation. DBC is a kind
    of process and apparently the people in charge were into
    circumventing processes. So DBC could have as easily been
    circumvented for the same reasons as they circumvented existing,
    industry accepted and used processes. (which, IMNSHO, would
    probably have caught the problem had they been followed.) If you
    walk a tightrope without a net often enough, eventually you'll
    splat up against the pavement.

    Assertions are just another kind of runtime check which - although
    useful - would probably have made no difference either. The reason
    being that the existing checks were disabled (for good reason)
    and so assertions would also have been disabled. Disabled checks
    don't change anything. The notion that they would have served as
    documentation implies some kind of review/testing and go back to
    the above paragraph on DBC. They had already circumvented that
    part of the game, so forget that argument.

    The seriously flawed notion that the runtime checks be turned
    on during testing and then disabled for production only displays
    lack of knowledge of how flight qualified software is really
    built. Nobody is going to go through any sort of serious
    verification of a software package only to allow you to change
    some of the bits afterwards and claim "well, it's really the same
    thing so let's go fly with it..." That might be O.K. for testing
    something like Microsoft Word, but it will never pass muster for
    safety critical software. Hence, you run with them in or you run
    with them out. Running with them in might have done something to
    save the day - but then so would the existing range checks that
    were taken out.

    MDC