* Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) [not found] ` <JSA.97Jun18155730@alexandria.organon.com> @ 1997-06-19 0:00 ` Mukesh Prasad 1997-06-19 0:00 ` Is Ada " Jon S Anthony ` (3 more replies) 0 siblings, 4 replies; 562+ messages in thread From: Mukesh Prasad @ 1997-06-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is Ada as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Mukesh Prasad @ 1997-06-19 0:00 ` Jon S Anthony 1997-06-19 0:00 ` Is ADA " Steve Jones - JON ` (2 subsequent siblings) 3 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Mukesh Prasad 1997-06-19 0:00 ` Is Ada " Jon S Anthony @ 1997-06-19 0:00 ` Steve Jones - JON 1997-06-19 0:00 ` Mukesh Prasad 1997-06-20 0:00 ` Robert Dewar 1997-06-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Tim Harrison 3 siblings, 1 reply; 562+ messages in thread From: Steve Jones - JON @ 1997-06-19 0:00 UTC (permalink / raw) 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. | ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-19 0:00 ` Is ADA " Steve Jones - JON @ 1997-06-19 0:00 ` Mukesh Prasad 0 siblings, 0 replies; 562+ messages in thread From: Mukesh Prasad @ 1997-06-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Mukesh Prasad 1997-06-19 0:00 ` Is Ada " Jon S Anthony 1997-06-19 0:00 ` Is ADA " Steve Jones - JON @ 1997-06-20 0:00 ` Robert Dewar 1997-06-22 0:00 ` Is ADA as good for graphics programming as C? (WAS: Jerry van Dijk 1997-06-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Tim Harrison 3 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: 1997-06-20 0:00 ` Robert Dewar @ 1997-06-22 0:00 ` Jerry van Dijk 0 siblings, 0 replies; 562+ messages in thread From: Jerry van Dijk @ 1997-06-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Mukesh Prasad ` (2 preceding siblings ...) 1997-06-20 0:00 ` Robert Dewar @ 1997-06-21 0:00 ` Tim Harrison 1997-06-23 0:00 ` Kaz Kylheku 1997-06-24 0:00 ` John Goodsen 3 siblings, 2 replies; 562+ messages in thread From: Tim Harrison @ 1997-06-21 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Tim Harrison @ 1997-06-23 0:00 ` Kaz Kylheku 1997-06-24 0:00 ` John Goodsen 1 sibling, 0 replies; 562+ messages in thread From: Kaz Kylheku @ 1997-06-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Tim Harrison 1997-06-23 0:00 ` Kaz Kylheku @ 1997-06-24 0:00 ` John Goodsen 1997-06-25 0:00 ` Michael Levasseur ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: John Goodsen @ 1997-06-24 0:00 UTC (permalink / raw) To: Tim Harrison 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-24 0:00 ` John Goodsen @ 1997-06-25 0:00 ` Michael Levasseur 1997-06-26 0:00 ` Chris Brand 1997-07-02 0:00 ` Matthew Heaney [not found] ` <33B16CBB.417A@gdesys <slrn5rn570.j6j.abo@minkirri.apana.org.au> [not found] ` <33B16CBB <slrn5rq1gc.che.abo@minkirri.apana.org.au> 2 siblings, 2 replies; 562+ messages in thread From: Michael Levasseur @ 1997-06-25 0:00 UTC (permalink / raw) 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..... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-25 0:00 ` Michael Levasseur @ 1997-06-26 0:00 ` Chris Brand 1997-07-02 0:00 ` Matthew Heaney 1 sibling, 0 replies; 562+ messages in thread From: Chris Brand @ 1997-06-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-06-25 0:00 ` Michael Levasseur 1997-06-26 0:00 ` Chris Brand @ 1997-07-02 0:00 ` Matthew Heaney 1997-07-03 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Dale Pontius 1 sibling, 2 replies; 562+ messages in thread From: Matthew Heaney @ 1997-07-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-02 0:00 ` Matthew Heaney @ 1997-07-03 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Matthew Heaney 1997-07-08 0:00 ` Dale Pontius 1 sibling, 1 reply; 562+ messages in thread From: Donovan Baarda @ 1997-07-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-03 0:00 ` Donovan Baarda @ 1997-07-04 0:00 ` Matthew Heaney 1997-07-04 0:00 ` Donovan Baarda [not found] ` <slrn5rq1gc.che.abo@minkirri. <slrn5s1132.hf1.abo@minkirri.apana.org.au> 0 siblings, 2 replies; 562+ messages in thread From: Matthew Heaney @ 1997-07-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Matthew Heaney @ 1997-07-04 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Brian Rogoff ` (3 more replies) [not found] ` <slrn5rq1gc.che.abo@minkirri. <slrn5s1132.hf1.abo@minkirri.apana.org.au> 1 sibling, 4 replies; 562+ messages in thread From: Donovan Baarda @ 1997-07-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Donovan Baarda @ 1997-07-04 0:00 ` Brian Rogoff 1997-07-07 0:00 ` Donovan Baarda 1997-07-05 0:00 ` John Nagle ` (2 subsequent siblings) 3 siblings, 1 reply; 562+ messages in thread From: Brian Rogoff @ 1997-07-04 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Brian Rogoff @ 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Joachim Durchholz ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Donovan Baarda @ 1997-07-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-07 0:00 ` Donovan Baarda @ 1997-07-08 0:00 ` Joachim Durchholz 1997-07-08 0:00 ` Brian Rogoff 1997-07-09 0:00 ` Don Harrison 2 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Joachim Durchholz @ 1997-07-08 0:00 ` Brian Rogoff 1997-07-09 0:00 ` Don Harrison 2 siblings, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Joachim Durchholz 1997-07-08 0:00 ` Brian Rogoff @ 1997-07-09 0:00 ` Don Harrison 2 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Brian Rogoff @ 1997-07-05 0:00 ` John Nagle 1997-07-05 0:00 ` Jon S Anthony 1997-07-09 0:00 ` Don Harrison 3 siblings, 0 replies; 562+ messages in thread From: John Nagle @ 1997-07-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Brian Rogoff 1997-07-05 0:00 ` John Nagle @ 1997-07-05 0:00 ` Jon S Anthony 1997-07-07 0:00 ` Donovan Baarda 1997-07-09 0:00 ` Don Harrison 3 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-05 0:00 ` Jon S Anthony @ 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Canada Bass 1997-07-09 0:00 ` Matthew Heaney 0 siblings, 2 replies; 562+ messages in thread From: Donovan Baarda @ 1997-07-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-07 0:00 ` Donovan Baarda @ 1997-07-08 0:00 ` Canada Bass 1997-07-08 0:00 ` Dale Pontius 1997-07-08 0:00 ` Martin Tom Brown 1997-07-09 0:00 ` Matthew Heaney 1 sibling, 2 replies; 562+ messages in thread From: Canada Bass @ 1997-07-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-08 0:00 ` Canada Bass @ 1997-07-08 0:00 ` Dale Pontius 1997-07-08 0:00 ` Martin Tom Brown 1 sibling, 0 replies; 562+ messages in thread From: Dale Pontius @ 1997-07-08 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-08 0:00 ` Canada Bass 1997-07-08 0:00 ` Dale Pontius @ 1997-07-08 0:00 ` Martin Tom Brown 1 sibling, 0 replies; 562+ messages in thread From: Martin Tom Brown @ 1997-07-08 0:00 UTC (permalink / raw) 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 /^,,)__/ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Canada Bass @ 1997-07-09 0:00 ` Matthew Heaney 1997-07-10 0:00 ` Nick Leaton 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-07-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-09 0:00 ` Matthew Heaney @ 1997-07-10 0:00 ` Nick Leaton 1997-07-10 0:00 ` Matthew Heaney 1997-07-15 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-10 0:00 ` Nick Leaton @ 1997-07-10 0:00 ` Matthew Heaney 1997-07-11 0:00 ` Nick Leaton 1997-07-14 0:00 ` Don Harrison 1997-07-15 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 562+ messages in thread From: Matthew Heaney @ 1997-07-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-10 0:00 ` Matthew Heaney @ 1997-07-11 0:00 ` Nick Leaton 1997-07-14 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-10 0:00 ` Matthew Heaney 1997-07-11 0:00 ` Nick Leaton @ 1997-07-14 0:00 ` Don Harrison 1997-07-15 0:00 ` Matthew Heaney 1997-07-15 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Jon S Anthony 1 sibling, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-14 0:00 ` Don Harrison @ 1997-07-15 0:00 ` Matthew Heaney 1997-07-15 0:00 ` Brian Rogoff 1997-07-16 0:00 ` Don Harrison 1997-07-15 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Jon S Anthony 1 sibling, 2 replies; 562+ messages in thread From: Matthew Heaney @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-15 0:00 ` Matthew Heaney @ 1997-07-15 0:00 ` Brian Rogoff 1997-07-16 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-15 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-15 0:00 ` Matthew Heaney 1997-07-15 0:00 ` Brian Rogoff @ 1997-07-16 0:00 ` Don Harrison 1997-07-17 0:00 ` Matthew Heaney 1 sibling, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-16 0:00 ` Don Harrison @ 1997-07-17 0:00 ` Matthew Heaney 1997-07-18 0:00 ` Composition vs. Inheritance (was Re: Is ADA as good for graphics programming as C?) Robert I. Eachus ` (4 more replies) 0 siblings, 5 replies; 562+ messages in thread From: Matthew Heaney @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Composition vs. Inheritance (was Re: Is ADA as good for graphics programming as C?) 1997-07-17 0:00 ` Matthew Heaney @ 1997-07-18 0:00 ` Robert I. Eachus 1997-07-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Nasser ` (3 subsequent siblings) 4 siblings, 0 replies; 562+ messages in thread From: Robert I. Eachus @ 1997-07-18 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-17 0:00 ` Matthew Heaney 1997-07-18 0:00 ` Composition vs. Inheritance (was Re: Is ADA as good for graphics programming as C?) Robert I. Eachus @ 1997-07-19 0:00 ` Nasser 1997-07-20 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Jon S Anthony [not found] ` <01bc94e1$46912100$53aa20cc@default> ` (2 subsequent siblings) 4 siblings, 2 replies; 562+ messages in thread From: Nasser @ 1997-07-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Nasser @ 1997-07-20 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Andrew Dunstan 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 2 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-20 0:00 ` Brian Rogoff @ 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Andrew Dunstan 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-20 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Jon S Anthony @ 1997-07-21 0:00 ` Andrew Dunstan 1 sibling, 0 replies; 562+ messages in thread From: Andrew Dunstan @ 1997-07-21 0:00 UTC (permalink / raw) 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 ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Nasser 1997-07-20 0:00 ` Brian Rogoff @ 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <01bc94e1$46912100$53aa20cc@default>]
* Re: Is ADA as good for graphics programming as C? [not found] ` <01bc94e1$46912100$53aa20cc@default> @ 1997-07-20 0:00 ` Matthew Heaney 1997-07-21 0:00 ` Dennis Weldy 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-07-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney @ 1997-07-21 0:00 ` Dennis Weldy 0 siblings, 0 replies; 562+ messages in thread From: Dennis Weldy @ 1997-07-21 0:00 UTC (permalink / raw) 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 >. > ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? [not found] ` <01bc94e1$46912100$53aa20cc@default> 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney @ 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-17 0:00 ` Matthew Heaney ` (2 preceding siblings ...) [not found] ` <01bc94e1$46912100$53aa20cc@default> @ 1997-07-21 0:00 ` Robert C. Martin 1997-07-22 0:00 ` Relative complexity - Eiffel and Ada Don Harrison 4 siblings, 0 replies; 562+ messages in thread From: Robert C. Martin @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Relative complexity - Eiffel and Ada. 1997-07-17 0:00 ` Matthew Heaney ` (3 preceding siblings ...) 1997-07-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Robert C. Martin @ 1997-07-22 0:00 ` Don Harrison 4 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-14 0:00 ` Don Harrison 1997-07-15 0:00 ` Matthew Heaney @ 1997-07-15 0:00 ` Jon S Anthony 1997-07-15 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-15 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Jon S Anthony @ 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-15 0:00 ` Don Harrison @ 1997-07-15 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-10 0:00 ` Nick Leaton 1997-07-10 0:00 ` Matthew Heaney @ 1997-07-15 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 562+ messages in thread From: Robert I. Eachus @ 1997-07-15 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-04 0:00 ` Donovan Baarda ` (2 preceding siblings ...) 1997-07-05 0:00 ` Jon S Anthony @ 1997-07-09 0:00 ` Don Harrison 1997-07-09 0:00 ` Tucker Taft 3 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-09 0:00 ` Don Harrison @ 1997-07-09 0:00 ` Tucker Taft 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Tucker Taft @ 1997-07-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Safety-critical development in Ada and Eiffel 1997-07-09 0:00 ` Tucker Taft @ 1997-07-10 0:00 ` Don Harrison 1997-07-10 0:00 ` Joe Gwinn ` (5 more replies) 0 siblings, 6 replies; 562+ messages in thread From: Don Harrison @ 1997-07-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison @ 1997-07-10 0:00 ` Joe Gwinn 1997-07-11 0:00 ` Robert S. White 1997-07-10 0:00 ` Ken Garlington ` (4 subsequent siblings) 5 siblings, 1 reply; 562+ messages in thread From: Joe Gwinn @ 1997-07-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Joe Gwinn @ 1997-07-11 0:00 ` Robert S. White 1997-07-15 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Robert S. White @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Robert S. White @ 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Don Harrison @ 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Ken Garlington @ 1997-07-16 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-07-10 0:00 ` Joe Gwinn @ 1997-07-10 0:00 ` Ken Garlington 1997-07-11 0:00 ` Ted Velkoff 1997-07-10 0:00 ` Mike Stark ` (3 subsequent siblings) 5 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-10 0:00 UTC (permalink / raw) > 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 > > > ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Ken Garlington @ 1997-07-11 0:00 ` Ted Velkoff 1997-07-12 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Ted Velkoff @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Ted Velkoff @ 1997-07-12 0:00 ` Ken Garlington 1997-07-13 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-12 0:00 ` Ken Garlington @ 1997-07-13 0:00 ` Jon S Anthony 1997-07-14 0:00 ` Wes Groleau ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-13 0:00 ` Jon S Anthony @ 1997-07-14 0:00 ` Wes Groleau 1997-07-15 0:00 ` Jon S Anthony 1997-07-15 0:00 ` Don Harrison 1997-07-16 0:00 ` Paul Johnson 2 siblings, 1 reply; 562+ messages in thread From: Wes Groleau @ 1997-07-14 0:00 UTC (permalink / raw) > > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-14 0:00 ` Wes Groleau @ 1997-07-15 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-13 0:00 ` Jon S Anthony 1997-07-14 0:00 ` Wes Groleau @ 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Paul Johnson 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Don Harrison @ 1997-07-15 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-13 0:00 ` Jon S Anthony 1997-07-14 0:00 ` Wes Groleau 1997-07-15 0:00 ` Don Harrison @ 1997-07-16 0:00 ` Paul Johnson 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` Jon S Anthony 2 siblings, 2 replies; 562+ messages in thread From: Paul Johnson @ 1997-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Paul Johnson @ 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Paul Johnson @ 1997-07-17 0:00 ` Ken Garlington 1997-07-18 0:00 ` Paul Johnson 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Ken Garlington @ 1997-07-18 0:00 ` Paul Johnson 1997-07-18 0:00 ` Ken Garlington 1997-07-18 0:00 ` Jon S Anthony 0 siblings, 2 replies; 562+ messages in thread From: Paul Johnson @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Paul Johnson @ 1997-07-18 0:00 ` Ken Garlington 1997-07-21 0:00 ` Paul Johnson 1997-07-18 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Ken Garlington @ 1997-07-21 0:00 ` Paul Johnson 0 siblings, 0 replies; 562+ messages in thread From: Paul Johnson @ 1997-07-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Paul Johnson 1997-07-18 0:00 ` Ken Garlington @ 1997-07-18 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Paul Johnson 1997-07-16 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Jon S Anthony [not found] ` <EDHqKo.K52@world.std.com> 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <EDHqKo.K52@world.std.com>]
* Re: Safety-critical development in Ada and Eiffel [not found] ` <EDHqKo.K52@world.std.com> @ 1997-07-18 0:00 ` Jon S Anthony 1997-07-19 0:00 ` Robert A Duff 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Jon S Anthony @ 1997-07-19 0:00 ` Robert A Duff 1997-07-20 0:00 ` Tucker Taft 0 siblings, 1 reply; 562+ messages in thread From: Robert A Duff @ 1997-07-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-19 0:00 ` Robert A Duff @ 1997-07-20 0:00 ` Tucker Taft 0 siblings, 0 replies; 562+ messages in thread From: Tucker Taft @ 1997-07-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-07-10 0:00 ` Joe Gwinn 1997-07-10 0:00 ` Ken Garlington @ 1997-07-10 0:00 ` Mike Stark 1997-07-11 0:00 ` Donovan Baarda 1997-07-11 0:00 ` Don Harrison ` (2 subsequent siblings) 5 siblings, 1 reply; 562+ messages in thread From: Mike Stark @ 1997-07-10 0:00 UTC (permalink / raw) 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 -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Mike Stark @ 1997-07-11 0:00 ` Donovan Baarda 1997-07-13 0:00 ` Steve Furlong 0 siblings, 1 reply; 562+ messages in thread From: Donovan Baarda @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Donovan Baarda @ 1997-07-13 0:00 ` Steve Furlong 1997-07-16 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 562+ messages in thread From: Steve Furlong @ 1997-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-13 0:00 ` Steve Furlong @ 1997-07-16 0:00 ` Joachim Durchholz 1997-07-17 0:00 ` Ken Garlington ` (3 more replies) 0 siblings, 4 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Joachim Durchholz @ 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Joachim Durchholz 1997-07-17 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Jon S Anthony 1997-07-18 0:00 ` John Nagle 3 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-17 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Joachim Durchholz 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Robert Dewar @ 1997-07-18 0:00 ` Jon S Anthony 1997-07-18 0:00 ` Nick Leaton 1997-07-18 0:00 ` John Nagle 3 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Jon S Anthony @ 1997-07-18 0:00 ` Nick Leaton 1997-07-18 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Nick Leaton @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Nick Leaton @ 1997-07-18 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Joachim Durchholz ` (2 preceding siblings ...) 1997-07-18 0:00 ` Jon S Anthony @ 1997-07-18 0:00 ` John Nagle 1997-07-18 0:00 ` Jon S Anthony 3 siblings, 1 reply; 562+ messages in thread From: John Nagle @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` John Nagle @ 1997-07-18 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison ` (2 preceding siblings ...) 1997-07-10 0:00 ` Mike Stark @ 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` Kazimir Majorinc 1997-07-11 0:00 ` Don Harrison 5 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison ` (3 preceding siblings ...) 1997-07-11 0:00 ` Don Harrison @ 1997-07-11 0:00 ` Kazimir Majorinc 1997-07-12 0:00 ` Ken Garlington 1997-07-11 0:00 ` Don Harrison 5 siblings, 1 reply; 562+ messages in thread From: Kazimir Majorinc @ 1997-07-11 0:00 UTC (permalink / raw) 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Kazimir Majorinc @ 1997-07-12 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-12 0:00 UTC (permalink / raw) 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison ` (4 preceding siblings ...) 1997-07-11 0:00 ` Kazimir Majorinc @ 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` James Graves ` (2 more replies) 5 siblings, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-07-11 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Don Harrison @ 1997-07-11 0:00 ` James Graves 1997-07-14 0:00 ` Don Harrison 1997-07-12 0:00 ` Ken Garlington 1997-07-16 0:00 ` Alan Brain 2 siblings, 1 reply; 562+ messages in thread From: James Graves @ 1997-07-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` James Graves @ 1997-07-14 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` James Graves @ 1997-07-12 0:00 ` Ken Garlington 1997-07-15 0:00 ` Don Harrison 1997-07-16 0:00 ` Alan Brain 2 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-12 0:00 UTC (permalink / raw) 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! :) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-12 0:00 ` Ken Garlington @ 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Don Harrison @ 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Jean-Marc Jezequel ` (2 more replies) 1997-07-15 0:00 ` Wes Groleau 1997-07-16 0:00 ` Warwick Pulley 2 siblings, 3 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Ken Garlington @ 1997-07-16 0:00 ` Jean-Marc Jezequel 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel Joachim Durchholz 1997-07-18 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Jean-Marc Jezequel @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Jean-Marc Jezequel @ 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` The stupidity of all the Ariane 5 analysts Thaddeus L. Olczyk ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* The stupidity of all the Ariane 5 analysts. 1997-07-16 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Thaddeus L. Olczyk [not found] ` <33CEAF05.6389@flash.net> 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel "Paul E. Bennett" 1997-07-18 0:00 ` Safety-critical development in Ada and Eiffel - Ariane crash Joachim Durchholz 2 siblings, 1 reply; 562+ messages in thread From: Thaddeus L. Olczyk @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <33CEAF05.6389@flash.net>]
* Re: The stupidity of all the Ariane 5 analysts. [not found] ` <33CEAF05.6389@flash.net> @ 1997-07-20 0:00 ` Bertrand Meyer 1997-07-21 0:00 ` Ken Garlington ` (3 more replies) 0 siblings, 4 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-07-20 0:00 UTC (permalink / raw) 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 == ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-20 0:00 ` Bertrand Meyer @ 1997-07-21 0:00 ` Ken Garlington 1997-07-31 0:00 ` Al Christians 1997-07-21 0:00 ` Ian Begg ` (2 subsequent siblings) 3 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-21 0:00 ` Ken Garlington @ 1997-07-31 0:00 ` Al Christians 1997-08-01 0:00 ` "Paul E. Bennett" 0 siblings, 1 reply; 562+ messages in thread From: Al Christians @ 1997-07-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-31 0:00 ` Al Christians @ 1997-08-01 0:00 ` "Paul E. Bennett" 1997-08-01 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: "Paul E. Bennett" @ 1997-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-08-01 0:00 ` "Paul E. Bennett" @ 1997-08-01 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-20 0:00 ` Bertrand Meyer 1997-07-21 0:00 ` Ken Garlington @ 1997-07-21 0:00 ` Ian Begg 1997-07-21 0:00 ` Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Jim Cochrane 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White 1997-07-23 0:00 ` Joerg Rodemann 3 siblings, 1 reply; 562+ messages in thread From: Ian Begg @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) 1997-07-21 0:00 ` Ian Begg @ 1997-07-21 0:00 ` Jim Cochrane 1997-07-22 0:00 ` Jon S Anthony 1997-07-22 0:00 ` Ken Garlington 0 siblings, 2 replies; 562+ messages in thread From: Jim Cochrane @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) 1997-07-21 0:00 ` Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Jim Cochrane @ 1997-07-22 0:00 ` Jon S Anthony 1997-07-22 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) 1997-07-21 0:00 ` Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Jim Cochrane 1997-07-22 0:00 ` Jon S Anthony @ 1997-07-22 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-22 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-20 0:00 ` Bertrand Meyer 1997-07-21 0:00 ` Ken Garlington 1997-07-21 0:00 ` Ian Begg @ 1997-07-21 0:00 ` Robert S. White 1997-07-21 0:00 ` Ken Garlington ` (2 more replies) 1997-07-23 0:00 ` Joerg Rodemann 3 siblings, 3 replies; 562+ messages in thread From: Robert S. White @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White @ 1997-07-21 0:00 ` Ken Garlington 1997-07-23 0:00 ` Robert S. White 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert Dewar 1997-07-22 0:00 ` The stupidity " W. Wesley Groleau x4923 2 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-21 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` Robert S. White 1997-07-23 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Robert S. White @ 1997-07-23 0:00 UTC (permalink / raw) 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") ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-23 0:00 ` Robert S. White @ 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Robert S. White 1997-07-23 0:00 ` Robert Dewar 1997-07-25 0:00 ` Ariane 5,Eiffel, Ada Alan Brain 2 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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") ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-23 0:00 ` Ken Garlington @ 1997-07-25 0:00 ` Robert S. White 0 siblings, 0 replies; 562+ messages in thread From: Robert S. White @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-23 0:00 ` Robert S. White 1997-07-23 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` Robert Dewar 1997-07-24 0:00 ` Ken Garlington 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1997-07-25 0:00 ` Ariane 5,Eiffel, Ada Alan Brain 2 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-23 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-23 0:00 ` Robert Dewar @ 1997-07-24 0:00 ` Ken Garlington 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-23 0:00 ` Robert Dewar 1997-07-24 0:00 ` Ken Garlington @ 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1997-07-31 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-07-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz @ 1997-07-31 0:00 ` Robert Dewar 1997-08-01 0:00 ` Shmuel (Seymour J.) Metz 1997-08-04 0:00 ` Larry Kilgallen 1997-07-31 0:00 ` Warts was " Richard Irvine 1997-08-08 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-31 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-31 0:00 ` Robert Dewar @ 1997-08-01 0:00 ` Shmuel (Seymour J.) Metz 1997-08-04 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 562+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-08-01 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-31 0:00 ` Robert Dewar 1997-08-01 0:00 ` Shmuel (Seymour J.) Metz @ 1997-08-04 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 562+ messages in thread From: Larry Kilgallen @ 1997-08-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1997-07-31 0:00 ` Robert Dewar @ 1997-07-31 0:00 ` Richard Irvine 1997-07-31 0:00 ` Robert Dewar 1997-08-05 0:00 ` Shmuel (Seymour J.) Metz 1997-08-08 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Richard Irvine @ 1997-07-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-07-31 0:00 ` Warts was " Richard Irvine @ 1997-07-31 0:00 ` Robert Dewar 1997-08-05 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-07-31 0:00 ` Warts was " Richard Irvine 1997-07-31 0:00 ` Robert Dewar @ 1997-08-05 0:00 ` Shmuel (Seymour J.) Metz [not found] ` <5scqlr$ju@news.sei.cmu.edu> 1 sibling, 1 reply; 562+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-08-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <5scqlr$ju@news.sei.cmu.edu>]
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. [not found] ` <5scqlr$ju@news.sei.cmu.edu> @ 1997-08-07 0:00 ` Brian Rogoff 1997-08-08 0:00 ` Jon S Anthony 1997-08-10 0:00 ` Matthew Heaney [not found] ` <Pine.SGI.3.95.970807191944.13419A-100000@shellx <JSA.97Aug8161709@alexandria.organon.com> 1 sibling, 2 replies; 562+ messages in thread From: Brian Rogoff @ 1997-08-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-07 0:00 ` Brian Rogoff @ 1997-08-08 0:00 ` Jon S Anthony 1997-08-08 0:00 ` Brian Rogoff 1997-08-10 0:00 ` Matthew Heaney 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-08 0:00 ` Jon S Anthony @ 1997-08-08 0:00 ` Brian Rogoff 0 siblings, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-08-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-07 0:00 ` Brian Rogoff 1997-08-08 0:00 ` Jon S Anthony @ 1997-08-10 0:00 ` Matthew Heaney 1997-08-10 0:00 ` Brian Rogoff 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-08-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-10 0:00 ` Matthew Heaney @ 1997-08-10 0:00 ` Brian Rogoff 1997-08-19 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 562+ messages in thread From: Brian Rogoff @ 1997-08-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-10 0:00 ` Brian Rogoff @ 1997-08-19 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 0 replies; 562+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-08-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <Pine.SGI.3.95.970807191944.13419A-100000@shellx <JSA.97Aug8161709@alexandria.organon.com>]
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. [not found] ` <Pine.SGI.3.95.970807191944.13419A-100000@shellx <JSA.97Aug8161709@alexandria.organon.com> @ 1997-08-08 0:00 ` Robert A Duff 1997-08-11 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Robert A Duff @ 1997-08-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Warts was Re: The stupidity of all the Ariane 5 analysts. 1997-08-08 0:00 ` Robert A Duff @ 1997-08-11 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1997-07-31 0:00 ` Robert Dewar 1997-07-31 0:00 ` Warts was " Richard Irvine @ 1997-08-08 0:00 ` Don Harrison 1997-08-11 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-08-08 0:00 ` Don Harrison @ 1997-08-11 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 0 replies; 562+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-08-11 0:00 UTC (permalink / raw) To: donh 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Ariane 5,Eiffel, Ada. 1997-07-23 0:00 ` Robert S. White 1997-07-23 0:00 ` Ken Garlington 1997-07-23 0:00 ` Robert Dewar @ 1997-07-25 0:00 ` Alan Brain 2 siblings, 0 replies; 562+ messages in thread From: Alan Brain @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White 1997-07-21 0:00 ` Ken Garlington @ 1997-07-21 0:00 ` Robert Dewar 1997-07-21 0:00 ` The presuppositions " Samuel Mize 1997-07-22 0:00 ` The stupidity " W. Wesley Groleau x4923 2 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-07-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The presuppositions of all the Ariane 5 analysts. 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert Dewar @ 1997-07-21 0:00 ` Samuel Mize 1997-07-21 0:00 ` Ken Garlington 1997-07-22 0:00 ` Luther Hampton 0 siblings, 2 replies; 562+ messages in thread From: Samuel Mize @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The presuppositions of all the Ariane 5 analysts. 1997-07-21 0:00 ` The presuppositions " Samuel Mize @ 1997-07-21 0:00 ` Ken Garlington 1997-07-22 0:00 ` Luther Hampton 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The presuppositions of all the Ariane 5 analysts. 1997-07-21 0:00 ` The presuppositions " Samuel Mize 1997-07-21 0:00 ` Ken Garlington @ 1997-07-22 0:00 ` Luther Hampton 1997-07-23 0:00 ` Samuel Mize 1997-07-23 0:00 ` Ken Garlington 1 sibling, 2 replies; 562+ messages in thread From: Luther Hampton @ 1997-07-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The presuppositions of all the Ariane 5 analysts. 1997-07-22 0:00 ` Luther Hampton @ 1997-07-23 0:00 ` Samuel Mize 1997-07-23 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Samuel Mize @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The presuppositions of all the Ariane 5 analysts. 1997-07-22 0:00 ` Luther Hampton 1997-07-23 0:00 ` Samuel Mize @ 1997-07-23 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White 1997-07-21 0:00 ` Ken Garlington 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert Dewar @ 1997-07-22 0:00 ` W. Wesley Groleau x4923 2 siblings, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-22 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: The stupidity of all the Ariane 5 analysts. 1997-07-20 0:00 ` Bertrand Meyer ` (2 preceding siblings ...) 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White @ 1997-07-23 0:00 ` Joerg Rodemann 3 siblings, 0 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` The stupidity of all the Ariane 5 analysts Thaddeus L. Olczyk @ 1997-07-17 0:00 ` "Paul E. Bennett" 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Safety-critical development in Ada and Eiffel - Ariane crash Joachim Durchholz 2 siblings, 1 reply; 562+ messages in thread From: "Paul E. Bennett" @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel "Paul E. Bennett" @ 1997-07-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-17 0:00 UTC (permalink / raw) <<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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel - Ariane crash 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` The stupidity of all the Ariane 5 analysts Thaddeus L. Olczyk 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel "Paul E. Bennett" @ 1997-07-18 0:00 ` Joachim Durchholz 1997-07-18 0:00 ` Ken Garlington 2 siblings, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel - Ariane crash 1997-07-18 0:00 ` Safety-critical development in Ada and Eiffel - Ariane crash Joachim Durchholz @ 1997-07-18 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Jean-Marc Jezequel @ 1997-07-17 0:00 ` Joachim Durchholz 1997-07-19 0:00 ` Ken Garlington 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel Robert S. White 1997-07-18 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel Joachim Durchholz @ 1997-07-19 0:00 ` Ken Garlington 1997-07-21 0:00 ` Ada vs Eiffel (was: Safety-critical development in ...) W. Wesley Groleau x4923 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel Robert S. White 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Ada vs Eiffel (was: Safety-critical development in ...) 1997-07-19 0:00 ` Ken Garlington @ 1997-07-21 0:00 ` W. Wesley Groleau x4923 1997-07-22 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-21 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Ada vs Eiffel (was: Safety-critical development in ...) 1997-07-21 0:00 ` Ada vs Eiffel (was: Safety-critical development in ...) W. Wesley Groleau x4923 @ 1997-07-22 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 0 replies; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-07-22 0:00 UTC (permalink / raw) 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?'" ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel Joachim Durchholz 1997-07-19 0:00 ` Ken Garlington @ 1997-07-21 0:00 ` Robert S. White 1997-07-20 0:00 ` nabbasi 1 sibling, 1 reply; 562+ messages in thread From: Robert S. White @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel Robert S. White @ 1997-07-20 0:00 ` nabbasi 1997-07-21 0:00 ` W. Wesley Groleau x4923 0 siblings, 1 reply; 562+ messages in thread From: nabbasi @ 1997-07-20 0:00 UTC (permalink / raw) > >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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-20 0:00 ` nabbasi @ 1997-07-21 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-21 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Jean-Marc Jezequel 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel Joachim Durchholz @ 1997-07-18 0:00 ` Don Harrison 1997-07-18 0:00 ` Ken Garlington 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Don Harrison @ 1997-07-18 0:00 ` Ken Garlington 1997-07-22 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Ken Garlington @ 1997-07-22 0:00 ` Don Harrison 1997-07-21 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-22 0:00 ` Don Harrison @ 1997-07-21 0:00 ` Ken Garlington 1997-07-23 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-21 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-23 0:00 ` W. Wesley Groleau x4923 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison @ 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 1997-07-23 0:00 ` W. Wesley Groleau x4923 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Ken Garlington @ 1997-07-25 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` W. Wesley Groleau x4923 1997-07-24 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-23 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` W. Wesley Groleau x4923 @ 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Don Harrison @ 1997-07-24 0:00 ` Ken Garlington 1997-07-26 0:00 ` Joachim Durchholz ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Ken Garlington @ 1997-07-26 0:00 ` Joachim Durchholz 1997-07-31 0:00 ` Ken Garlington 1997-07-28 0:00 ` Nick Leaton 1997-07-29 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-07-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-26 0:00 ` Joachim Durchholz @ 1997-07-31 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Ken Garlington 1997-07-26 0:00 ` Joachim Durchholz @ 1997-07-28 0:00 ` Nick Leaton 1997-07-28 0:00 ` Steve Jones - JON 1997-07-31 0:00 ` Ken Garlington 1997-07-29 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-28 0:00 ` Nick Leaton @ 1997-07-28 0:00 ` Steve Jones - JON 1997-07-31 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Steve Jones - JON @ 1997-07-28 0:00 UTC (permalink / raw) 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. | ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-28 0:00 ` Nick Leaton 1997-07-28 0:00 ` Steve Jones - JON @ 1997-07-31 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Ken Garlington 1997-07-26 0:00 ` Joachim Durchholz 1997-07-28 0:00 ` Nick Leaton @ 1997-07-29 0:00 ` Don Harrison 1997-07-31 0:00 ` Ken Garlington 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-29 0:00 ` Don Harrison @ 1997-07-31 0:00 ` Ken Garlington 1997-08-07 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-31 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-31 0:00 ` Ken Garlington @ 1997-08-07 0:00 ` Don Harrison 1997-08-07 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 ` Don Harrison @ 1997-08-07 0:00 ` Ken Garlington 1997-08-09 0:00 ` Jim Cochrane 1997-08-12 0:00 ` Don Harrison 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 ` Ken Garlington @ 1997-08-09 0:00 ` Jim Cochrane 1997-08-11 0:00 ` Paul Johnson 1997-08-12 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Jim Cochrane @ 1997-08-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-09 0:00 ` Jim Cochrane @ 1997-08-11 0:00 ` Paul Johnson 1997-08-11 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-11 0:00 ` Paul Johnson @ 1997-08-11 0:00 ` Ken Garlington 1997-08-12 0:00 ` Mark A Biggar 1997-08-13 0:00 ` Paul Johnson 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-11 0:00 ` Ken Garlington @ 1997-08-12 0:00 ` Mark A Biggar 1997-08-19 0:00 ` Robert Dewar 1997-08-13 0:00 ` Paul Johnson 1 sibling, 1 reply; 562+ messages in thread From: Mark A Biggar @ 1997-08-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Mark A Biggar @ 1997-08-19 0:00 ` Robert Dewar 1997-08-19 0:00 ` Bertrand Meyer ` (3 more replies) 0 siblings, 4 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-19 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar @ 1997-08-19 0:00 ` Bertrand Meyer 1997-08-19 0:00 ` Robert Dewar 1997-08-19 0:00 ` Nick Leaton ` (2 subsequent siblings) 3 siblings, 1 reply; 562+ messages in thread From: Bertrand Meyer @ 1997-08-19 0:00 UTC (permalink / raw) 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 == ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Bertrand Meyer @ 1997-08-19 0:00 ` Robert Dewar 1997-08-20 0:00 ` Lee Webber 1997-08-20 0:00 ` Nick Leaton 0 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar @ 1997-08-20 0:00 ` Lee Webber 1997-08-21 0:00 ` Don Harrison 1997-08-20 0:00 ` Nick Leaton 1 sibling, 1 reply; 562+ messages in thread From: Lee Webber @ 1997-08-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Lee Webber @ 1997-08-21 0:00 ` Don Harrison 1997-08-23 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Don Harrison @ 1997-08-23 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-23 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar 1997-08-20 0:00 ` Lee Webber @ 1997-08-20 0:00 ` Nick Leaton 1997-08-21 0:00 ` Joachim Durchholz 1997-08-21 0:00 ` Jon S Anthony 1 sibling, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Nick Leaton @ 1997-08-21 0:00 ` Joachim Durchholz 1997-08-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-08-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Nick Leaton 1997-08-21 0:00 ` Joachim Durchholz @ 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Nick Leaton 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Jon S Anthony @ 1997-08-22 0:00 ` Nick Leaton 0 siblings, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar 1997-08-19 0:00 ` Bertrand Meyer @ 1997-08-19 0:00 ` Nick Leaton 1997-08-20 0:00 ` Ken Garlington 1997-08-26 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar 1997-08-19 0:00 ` Bertrand Meyer 1997-08-19 0:00 ` Nick Leaton @ 1997-08-20 0:00 ` Ken Garlington 1997-08-26 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-20 0:00 UTC (permalink / raw) 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 :) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1997-08-20 0:00 ` Ken Garlington @ 1997-08-26 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 562+ messages in thread From: Richard A. O'Keefe @ 1997-08-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-11 0:00 ` Ken Garlington 1997-08-12 0:00 ` Mark A Biggar @ 1997-08-13 0:00 ` Paul Johnson 1997-08-13 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-08-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Paul Johnson @ 1997-08-13 0:00 ` Ken Garlington 1997-08-15 0:00 ` Paul Johnson 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ken Garlington @ 1997-08-15 0:00 ` Paul Johnson 1997-08-15 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-08-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Paul Johnson @ 1997-08-15 0:00 ` Ken Garlington 1997-08-18 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Ken Garlington @ 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-08-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-18 0:00 ` Joachim Durchholz @ 1997-08-19 0:00 ` Ken Garlington 1997-08-20 0:00 ` Nick Leaton 1997-08-21 0:00 ` Joachim Durchholz 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Ken Garlington @ 1997-08-20 0:00 ` Nick Leaton 1997-08-20 0:00 ` Nasser 1997-08-21 0:00 ` Jon S Anthony 1997-08-21 0:00 ` Joachim Durchholz 1 sibling, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-20 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Nick Leaton @ 1997-08-20 0:00 ` Nasser 1997-08-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Nasser @ 1997-08-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Nick Leaton 1997-08-20 0:00 ` Nasser @ 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Nick Leaton 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Jon S Anthony @ 1997-08-22 0:00 ` Nick Leaton 1997-08-23 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Nick Leaton @ 1997-08-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-22 0:00 ` Nick Leaton @ 1997-08-23 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Ken Garlington 1997-08-20 0:00 ` Nick Leaton @ 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-08-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Joachim Durchholz @ 1997-08-23 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 ` Ken Garlington 1997-08-09 0:00 ` Jim Cochrane @ 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Ken Garlington ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-08-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Don Harrison @ 1997-08-12 0:00 ` Ken Garlington 1997-08-12 0:00 ` Jon S Anthony 1997-08-23 0:00 ` W. Wesley Groleau x4923 2 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Ken Garlington @ 1997-08-12 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-08-23 0:00 ` W. Wesley Groleau x4923 2 siblings, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Jon S Anthony @ 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ken Garlington 1997-08-13 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1 sibling, 2 replies; 562+ messages in thread From: Ted Velkoff @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ted Velkoff @ 1997-08-13 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Jon S Anthony @ 1997-08-13 0:00 ` Ken Garlington 1997-08-13 0:00 ` Ted Velkoff 1997-08-14 0:00 ` Nick Leaton 1 sibling, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ken Garlington @ 1997-08-13 0:00 ` Ted Velkoff 1997-08-14 0:00 ` Matt Austern 1997-08-15 0:00 ` Ken Garlington 1997-08-14 0:00 ` Nick Leaton 1 sibling, 2 replies; 562+ messages in thread From: Ted Velkoff @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ted Velkoff @ 1997-08-14 0:00 ` Matt Austern 1997-08-14 0:00 ` Ted Velkoff 1997-08-15 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Matt Austern @ 1997-08-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Matt Austern @ 1997-08-14 0:00 ` Ted Velkoff 1997-08-18 0:00 ` Matt Austern 0 siblings, 1 reply; 562+ messages in thread From: Ted Velkoff @ 1997-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Ted Velkoff @ 1997-08-18 0:00 ` Matt Austern 1997-08-20 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 562+ messages in thread From: Matt Austern @ 1997-08-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-18 0:00 ` Matt Austern @ 1997-08-20 0:00 ` Joachim Durchholz 1997-08-21 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-08-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Joachim Durchholz @ 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Jon S Anthony @ 1997-08-22 0:00 ` Joachim Durchholz 0 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-08-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ted Velkoff 1997-08-14 0:00 ` Matt Austern @ 1997-08-15 0:00 ` Ken Garlington 1997-08-16 0:00 ` Ted Velkoff 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Ken Garlington @ 1997-08-16 0:00 ` Ted Velkoff 1997-08-16 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Ted Velkoff @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-16 0:00 ` Ted Velkoff @ 1997-08-16 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony 1997-08-18 0:00 ` Ted Velkoff 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-16 0:00 ` Ken Garlington @ 1997-08-16 0:00 ` Jon S Anthony 1997-08-16 0:00 ` Ken Garlington 1997-08-18 0:00 ` Ted Velkoff 1997-08-18 0:00 ` Ted Velkoff 1 sibling, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-16 0:00 ` Jon S Anthony @ 1997-08-16 0:00 ` Ken Garlington 1997-08-18 0:00 ` Ted Velkoff 1 sibling, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-16 0:00 ` Jon S Anthony 1997-08-16 0:00 ` Ken Garlington @ 1997-08-18 0:00 ` Ted Velkoff 1 sibling, 0 replies; 562+ messages in thread From: Ted Velkoff @ 1997-08-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-16 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony @ 1997-08-18 0:00 ` Ted Velkoff 1997-08-19 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Ted Velkoff @ 1997-08-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-18 0:00 ` Ted Velkoff @ 1997-08-19 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ken Garlington 1997-08-13 0:00 ` Ted Velkoff @ 1997-08-14 0:00 ` Nick Leaton 1997-08-16 0:00 ` Robert Dewar 1997-08-18 0:00 ` Joachim Durchholz 1 sibling, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Nick Leaton @ 1997-08-16 0:00 ` Robert Dewar 1997-08-18 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Nick Leaton 1997-08-16 0:00 ` Robert Dewar @ 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-08-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-18 0:00 ` Joachim Durchholz @ 1997-08-19 0:00 ` Ken Garlington 1997-08-21 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Ken Garlington @ 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-08-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Joachim Durchholz @ 1997-08-23 0:00 ` Ken Garlington [not found] ` <JSA.97Aug25181856@alexandria.organon.com> 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <JSA.97Aug25181856@alexandria.organon.com>]
[parent not found: <34023A1F.41C67EA6@eiffel.com>]
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> @ 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <JSA.97Aug26151833@alexandria.organon.com> 1997-08-25 0:00 ` Bertrand Meyer ` (2 subsequent siblings) 3 siblings, 1 reply; 562+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <JSA.97Aug26151833@alexandria.organon.com>]
* Re: Design by Contract [not found] ` <JSA.97Aug26151833@alexandria.organon.com> @ 1997-08-27 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-08-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 2 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-08-25 0:00 ` Bertrand Meyer @ 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Steve Stringfellow @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow @ 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-08-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer 1997-08-25 0:00 ` Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> ` (2 more replies) 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 3 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <3402d123.0@news.uni-ulm.de>]
* Re: Design by Contract [not found] ` <3402d123.0@news.uni-ulm.de> @ 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> 0 siblings, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-26 0:00 UTC (permalink / raw) To: Joerg Rodemann 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <3402e51d.0@news.uni-ulm.de>]
[parent not found: <3402E8C9.3384D976@calfp.co.uk>]
[parent not found: <dewar.872631036@merv>]
[parent not found: <3403F668.F6B57D97@calfp.co.uk>]
[parent not found: <34041331.0@news.uni-ulm.de>]
[parent not found: <3404696D.4487EB71@eiffel.com>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3404696D.4487EB71@eiffel.com> @ 1997-08-27 0:00 ` Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> 1997-08-28 0:00 ` Tucker Taft 0 siblings, 2 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-08-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <34048FDC.13728473@eiffel.com>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <34048FDC.13728473@eiffel.com> @ 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Patrick Doyle 1997-08-28 0:00 ` Jon S Anthony 0 siblings, 2 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-08-27 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Bertrand Meyer @ 1997-08-28 0:00 ` Patrick Doyle 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Patrick Doyle @ 1997-08-28 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-28 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Patrick Doyle @ 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> 1 sibling, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Jon S Anthony @ 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> 1 sibling, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <EForsv.Fqo@ecf.toronto.edu>]
[parent not found: <JSA.97Aug29191413@alexandria.organon.com>]
[parent not found: <EFqDAG.2zn@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFqDAG.2zn@ecf.toronto.edu> @ 1997-08-30 0:00 ` Jon S Anthony 1997-09-02 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFqDAG.2zn@ecf.toronto.edu> 1997-08-30 0:00 ` Jon S Anthony @ 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1 sibling, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Don Harrison @ 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Jon S Anthony @ 1997-09-03 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <EFwuzD.BxE@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFwuzD.BxE@ecf.toronto.edu> @ 1997-09-04 0:00 ` Don Harrison 1997-09-05 0:00 ` Patrick Doyle 1997-09-04 0:00 ` John G. Volan 1 sibling, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-09-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` Don Harrison @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison @ 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1 sibling, 2 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-09 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-10 0:00 ` Samuel Mize 1997-09-12 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Veli-Pekka Nousiainen @ 1997-09-10 0:00 UTC (permalink / raw) 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! > ---------------------------------------------------------------------- > ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Veli-Pekka Nousiainen @ 1997-09-10 0:00 ` Samuel Mize 0 siblings, 0 replies; 562+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen @ 1997-09-12 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-12 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Joachim Durchholz 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Robert S. White 1997-09-12 0:00 ` Jon S Anthony 2 siblings, 2 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-10 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Patrick Doyle 1 sibling, 1 reply; 562+ messages in thread From: Joachim Durchholz @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joachim Durchholz @ 1997-09-12 0:00 ` Joerg Rodemann 0 siblings, 0 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Joachim Durchholz @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Matt Austern 1 sibling, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 0 siblings, 2 replies; 562+ messages in thread From: Matt Austern @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Matt Austern @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-13 0:00 ` Patrick Doyle 1 sibling, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison ` (2 more replies) 1997-09-12 0:00 ` Jon S Anthony 2 siblings, 3 replies; 562+ messages in thread From: Robert S. White @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White @ 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison @ 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar @ 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-11 0:00 ` Robert S. White @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-13 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Brian Rogoff 0 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-13 0:00 ` Patrick Doyle @ 1997-09-16 0:00 ` Brian Rogoff 0 siblings, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1997-09-04 0:00 ` Don Harrison @ 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: John G. Volan @ 1997-09-04 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan @ 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle ` (2 more replies) 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Franck Arnaud 2 siblings, 3 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-04 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1997-09-06 0:00 ` Jon S Anthony 1 sibling, 2 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1 sibling, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` Paul Johnson 1 sibling, 0 replies; 562+ messages in thread From: Paul Johnson @ 1997-09-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Robert S. White ` (2 more replies) 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 3 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar @ 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Paul Johnson 2 siblings, 0 replies; 562+ messages in thread From: Robert S. White @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Robert S. White @ 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Paul Johnson 2 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Paul Johnson @ 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 0 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 1 sibling, 0 replies; 562+ messages in thread From: Veli-Pekka Nousiainen @ 1997-09-11 0:00 UTC (permalink / raw) 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 !? > ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen @ 1997-09-12 0:00 ` Paul Johnson 1997-09-14 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Paul Johnson @ 1997-09-12 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Paul Johnson @ 1997-09-14 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-09-14 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Robert Dewar @ 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` John Viega 2 siblings, 1 reply; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-09 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 ` John Viega 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 1 reply; 562+ messages in thread From: John Viega @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` John Viega @ 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 0 replies; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Franck Arnaud 2 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-05 0:00 ` Franck Arnaud 2 siblings, 0 replies; 562+ messages in thread From: Franck Arnaud @ 1997-09-05 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> @ 1997-08-28 0:00 ` Tucker Taft 1997-08-28 0:00 ` W. Wesley Groleau x4923 [not found] ` <3406A707.787D@dmu.ac.uk> 1 sibling, 2 replies; 562+ messages in thread From: Tucker Taft @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Tucker Taft @ 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony [not found] ` <3406A707.787D@dmu.ac.uk> 1 sibling, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-28 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` W. Wesley Groleau x4923 @ 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <EFnK8D.Lsv@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> @ 1997-08-29 0:00 ` Jon S Anthony 1997-08-30 0:00 ` Patrick Doyle 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Jon S Anthony @ 1997-08-30 0:00 ` Patrick Doyle 1997-08-30 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-30 0:00 ` Patrick Doyle @ 1997-08-30 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-30 0:00 ` Jon S Anthony @ 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> @ 1997-08-29 0:00 ` Suzanne Zampella 1997-08-29 0:00 ` Jon S Anthony [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> 2 siblings, 1 reply; 562+ messages in thread From: Suzanne Zampella @ 1997-08-29 0:00 UTC (permalink / raw) 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} ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Suzanne Zampella @ 1997-08-29 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <340E9BA2.32B3@rbgg252.rbg1.siemens.de>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> @ 1997-09-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-07 0:00 UTC (permalink / raw) <<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!) ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <3406A707.787D@dmu.ac.uk>]
* a fairy tale (was: Re: Interface/Implementation ) [not found] ` <3406A707.787D@dmu.ac.uk> @ 1997-08-29 0:00 ` Fred Long 1997-08-29 0:00 ` Interface/Implementation (was Re: Design by Contract) Joerg Rodemann ` (2 subsequent siblings) 3 siblings, 0 replies; 562+ messages in thread From: Fred Long @ 1997-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3406A707.787D@dmu.ac.uk> 1997-08-29 0:00 ` a fairy tale (was: Re: Interface/Implementation ) Fred Long @ 1997-08-29 0:00 ` Joerg Rodemann 1997-08-29 0:00 ` Ralph Paul 1997-09-01 0:00 ` In defence of plain ascii files ( was " Chris RL Morgan 1997-09-01 0:00 ` Don Harrison 3 siblings, 1 reply; 562+ messages in thread From: Joerg Rodemann @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Interface/Implementation (was Re: Design by Contract) Joerg Rodemann @ 1997-08-29 0:00 ` Ralph Paul 0 siblings, 0 replies; 562+ messages in thread From: Ralph Paul @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* In defence of plain ascii files ( was Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3406A707.787D@dmu.ac.uk> 1997-08-29 0:00 ` a fairy tale (was: Re: Interface/Implementation ) Fred Long 1997-08-29 0:00 ` Interface/Implementation (was Re: Design by Contract) Joerg Rodemann @ 1997-09-01 0:00 ` Chris RL Morgan 1997-09-01 0:00 ` Don Harrison 3 siblings, 0 replies; 562+ messages in thread From: Chris RL Morgan @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3406A707.787D@dmu.ac.uk> ` (2 preceding siblings ...) 1997-09-01 0:00 ` In defence of plain ascii files ( was " Chris RL Morgan @ 1997-09-01 0:00 ` Don Harrison 3 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract [not found] ` <dewar.872631036@merv> [not found] ` <3403F668.F6B57D97@calfp.co.uk> @ 1997-08-27 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-08-27 0:00 ` Ted Velkoff [not found] ` <34050F3C.5A3A@invest.amp.com.au> 3 siblings, 0 replies; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-08-27 0:00 UTC (permalink / raw) 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?'" ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract [not found] ` <dewar.872631036@merv> [not found] ` <3403F668.F6B57D97@calfp.co.uk> 1997-08-27 0:00 ` Design by Contract Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-08-27 0:00 ` Ted Velkoff [not found] ` <34050F3C.5A3A@invest.amp.com.au> 3 siblings, 0 replies; 562+ messages in thread From: Ted Velkoff @ 1997-08-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <34050F3C.5A3A@invest.amp.com.au>]
* Re: Design by Contract [not found] ` <34050F3C.5A3A@invest.amp.com.au> @ 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Paul Johnson 0 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) <<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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-08-28 0:00 ` Robert Dewar @ 1997-08-29 0:00 ` Paul Johnson 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) [not found] ` <dewar.872887402@merv> 0 siblings, 2 replies; 562+ messages in thread From: Paul Johnson @ 1997-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-08-29 0:00 ` Paul Johnson @ 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-01 0:00 ` John F. Bell III [not found] ` <dewar.872887402@merv> 1 sibling, 1 reply; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-08-31 0:00 UTC (permalink / raw) 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?'" ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-01 0:00 ` John F. Bell III 1997-09-02 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: John F. Bell III @ 1997-09-01 0:00 UTC (permalink / raw) 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?'" ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-09-01 0:00 ` John F. Bell III @ 1997-09-02 0:00 ` Ken Garlington 1997-09-05 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington @ 1997-09-05 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <dewar.872887402@merv>]
* Re: Design by Contract [not found] ` <dewar.872887402@merv> @ 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale 1997-09-05 0:00 ` Robert Dewar 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-09-02 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington @ 1997-09-03 0:00 ` Thomas Beale [not found] ` <EFxx8q.2sw@ecf.toronto.edu> 1997-09-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 562+ messages in thread From: Thomas Beale @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <EFxx8q.2sw@ecf.toronto.edu>]
* Re: Design by Contract [not found] ` <EFxx8q.2sw@ecf.toronto.edu> @ 1997-09-04 0:00 ` Thomas Beale 0 siblings, 0 replies; 562+ messages in thread From: Thomas Beale @ 1997-09-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale @ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract 1997-09-05 0:00 ` Robert Dewar @ 1997-09-05 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-09-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <340306E1.5FB64D70@XYZZYcalfp.com>]
* Re: Design by Contract [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> @ 1997-08-28 0:00 ` Mark Bennison 1997-08-28 0:00 ` Separation of IF and Imp: process issue? Jeff Kotula 0 siblings, 1 reply; 562+ messages in thread From: Mark Bennison @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Separation of IF and Imp: process issue? 1997-08-28 0:00 ` Mark Bennison @ 1997-08-28 0:00 ` Jeff Kotula [not found] ` <x7vd8myyrzx.fsf@pogner.demon.co.uk> [not found] ` <5u4941$9m1@gcsin3.geccs.gecm.com> 0 siblings, 2 replies; 562+ messages in thread From: Jeff Kotula @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <x7vd8myyrzx.fsf@pogner.demon.co.uk>]
* Re: Separation of IF and Imp: process issue? [not found] ` <x7vd8myyrzx.fsf@pogner.demon.co.uk> @ 1997-08-30 0:00 ` Patrick Doyle 1997-08-31 0:00 ` Jon S Anthony [not found] ` <x7vzppy250u.fsf@pogner.demon.co.uk> 0 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-08-30 0:00 ` Patrick Doyle @ 1997-08-31 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle [not found] ` <x7vzppy250u.fsf@pogner.demon.co.uk> 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-08-31 0:00 ` Jon S Anthony @ 1997-09-01 0:00 ` Patrick Doyle 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Jon S Anthony 0 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-01 0:00 ` Patrick Doyle @ 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Patrick Doyle 1997-09-02 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-01 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-01 0:00 ` Robert Dewar @ 1997-09-02 0:00 ` Patrick Doyle 1997-09-03 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Robert Dewar 0 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-02 0:00 ` Patrick Doyle @ 1997-09-03 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Robert Dewar 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-02 0:00 ` Patrick Doyle 1997-09-03 0:00 ` Jon S Anthony @ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-08 0:00 ` Erik Magnuson 1 sibling, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Robert Dewar @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-08 0:00 ` Erik Magnuson 1 sibling, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-08 0:00 ` Erik Magnuson 1 sibling, 0 replies; 562+ messages in thread From: Erik Magnuson @ 1997-09-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-01 0:00 ` Patrick Doyle 1997-09-01 0:00 ` Robert Dewar @ 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Patrick Doyle 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-02 0:00 ` Jon S Anthony @ 1997-09-03 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <x7vzppy250u.fsf@pogner.demon.co.uk>]
* Re: Separation of IF and Imp: process issue? [not found] ` <x7vzppy250u.fsf@pogner.demon.co.uk> @ 1997-09-01 0:00 ` Patrick Doyle [not found] ` <mheaney-ya023680000209972131260001@news.ni.net> 0 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <mheaney-ya023680000209972131260001@news.ni.net>]
* Re: Separation of IF and Imp: process issue? [not found] ` <mheaney-ya023680000209972131260001@news.ni.net> @ 1997-09-03 0:00 ` Patrick Doyle 1997-09-04 0:00 ` Matthew Heaney 1997-09-05 0:00 ` Jon S Anthony 0 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-03 0:00 ` Patrick Doyle @ 1997-09-04 0:00 ` Matthew Heaney 1997-09-05 0:00 ` Patrick Doyle ` (2 more replies) 1997-09-05 0:00 ` Jon S Anthony 1 sibling, 3 replies; 562+ messages in thread From: Matthew Heaney @ 1997-09-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-04 0:00 ` Matthew Heaney @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-08 0:00 ` John G. Volan 1997-09-05 0:00 ` Darren New 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` John G. Volan 1997-09-09 0:00 ` Nick Leaton 0 siblings, 1 reply; 562+ messages in thread From: John G. Volan @ 1997-09-08 0:00 UTC (permalink / raw) 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? :-) "); ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` John G. Volan @ 1997-09-09 0:00 ` Nick Leaton 0 siblings, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-04 0:00 ` Matthew Heaney 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-05 0:00 ` Darren New 1997-09-06 0:00 ` Matthew Heaney [not found] ` <dewar.873826268@merv> 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 2 replies; 562+ messages in thread From: Darren New @ 1997-09-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Darren New @ 1997-09-06 0:00 ` Matthew Heaney 1997-09-07 0:00 ` Darren New [not found] ` <dewar.873826268@merv> 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-09-06 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-06 0:00 ` Matthew Heaney @ 1997-09-07 0:00 ` Darren New 1997-09-08 0:00 ` Darren New ` (3 more replies) 0 siblings, 4 replies; 562+ messages in thread From: Darren New @ 1997-09-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-07 0:00 ` Darren New @ 1997-09-08 0:00 ` Darren New 1997-09-08 0:00 ` Matthew Heaney ` (2 more replies) 1997-09-08 0:00 ` W. Wesley Groleau x4923 ` (2 subsequent siblings) 3 siblings, 3 replies; 562+ messages in thread From: Darren New @ 1997-09-08 0:00 UTC (permalink / raw) >> 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` Darren New @ 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` John G. Volan 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Fergus Henderson 2 siblings, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-09-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` Matthew Heaney @ 1997-09-09 0:00 ` John G. Volan 0 siblings, 0 replies; 562+ messages in thread From: John G. Volan @ 1997-09-09 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` Darren New 1997-09-08 0:00 ` Matthew Heaney @ 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Darren New 1997-09-09 0:00 ` Fergus Henderson 2 siblings, 1 reply; 562+ messages in thread From: Robert S. White @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Robert S. White @ 1997-09-09 0:00 ` Darren New 1997-09-09 0:00 ` Jon S Anthony ` (4 more replies) 0 siblings, 5 replies; 562+ messages in thread From: Darren New @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Darren New @ 1997-09-09 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Mark A Biggar ` (3 subsequent siblings) 4 siblings, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Jon S Anthony @ 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` Brian Rogoff 1997-09-12 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Patrick Doyle 1 sibling, 2 replies; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 UTC (permalink / raw) : :> 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. * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 ` Brian Rogoff 1997-09-12 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` Brian Rogoff @ 1997-09-12 0:00 ` Jon S Anthony 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-12 0:00 ` Robert A Duff 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-12 0:00 ` Robert A Duff 1997-09-13 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Robert A Duff @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-12 0:00 ` Robert A Duff @ 1997-09-13 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Darren New 1997-09-09 0:00 ` Jon S Anthony @ 1997-09-09 0:00 ` Mark A Biggar 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Darren New 1997-09-09 0:00 ` Nick Leaton ` (2 subsequent siblings) 4 siblings, 2 replies; 562+ messages in thread From: Mark A Biggar @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Mark A Biggar @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Peter Hermann 1997-09-12 0:00 ` Robert Dewar 1997-09-10 0:00 ` Darren New 1 sibling, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-11 0:00 ` Peter Hermann 1997-09-12 0:00 ` Robert Dewar 1 sibling, 0 replies; 562+ messages in thread From: Peter Hermann @ 1997-09-11 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Peter Hermann @ 1997-09-12 0:00 ` Robert Dewar 1997-09-12 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-12 0:00 ` Robert Dewar @ 1997-09-12 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Mark A Biggar 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-10 0:00 ` Darren New 1997-09-11 0:00 ` Joerg Rodemann 1 sibling, 1 reply; 562+ messages in thread From: Darren New @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Darren New @ 1997-09-11 0:00 ` Joerg Rodemann 1997-09-11 0:00 ` Darren New 0 siblings, 1 reply; 562+ messages in thread From: Joerg Rodemann @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-11 0:00 ` Joerg Rodemann @ 1997-09-11 0:00 ` Darren New 1997-09-12 0:00 ` Joerg Rodemann 0 siblings, 1 reply; 562+ messages in thread From: Darren New @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-11 0:00 ` Darren New @ 1997-09-12 0:00 ` Joerg Rodemann 1997-09-12 0:00 ` Darren New 0 siblings, 1 reply; 562+ messages in thread From: Joerg Rodemann @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-12 0:00 ` Joerg Rodemann @ 1997-09-12 0:00 ` Darren New 0 siblings, 0 replies; 562+ messages in thread From: Darren New @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Darren New 1997-09-09 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Mark A Biggar @ 1997-09-09 0:00 ` Nick Leaton 1997-09-09 0:00 ` Jon S Anthony 1997-09-10 0:00 ` news_check.py 1997-09-11 0:00 ` Robert Dewar 4 siblings, 1 reply; 562+ messages in thread From: Nick Leaton @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Nick Leaton @ 1997-09-09 0:00 ` Jon S Anthony 1997-09-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Jon S Anthony @ 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-11 0:00 ` Robert Dewar @ 1997-09-12 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 562+ messages in thread From: Samuel T. Harris @ 1997-09-12 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Darren New ` (2 preceding siblings ...) 1997-09-09 0:00 ` Nick Leaton @ 1997-09-10 0:00 ` news_check.py 1997-09-11 0:00 ` Robert Dewar 4 siblings, 0 replies; 562+ messages in thread From: news_check.py @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Darren New ` (3 preceding siblings ...) 1997-09-10 0:00 ` news_check.py @ 1997-09-11 0:00 ` Robert Dewar 1997-09-16 0:00 ` Owen Fellows 4 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-11 0:00 ` Robert Dewar @ 1997-09-16 0:00 ` Owen Fellows 0 siblings, 0 replies; 562+ messages in thread From: Owen Fellows @ 1997-09-16 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` Darren New 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert S. White @ 1997-09-09 0:00 ` Fergus Henderson 1997-09-10 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 2 siblings, 2 replies; 562+ messages in thread From: Fergus Henderson @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Fergus Henderson @ 1997-09-10 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 1 sibling, 0 replies; 562+ messages in thread From: Paul Johnson @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Fergus Henderson 1997-09-10 0:00 ` Paul Johnson @ 1997-09-11 0:00 ` Robert Dewar 1 sibling, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-07 0:00 ` Darren New 1997-09-08 0:00 ` Darren New @ 1997-09-08 0:00 ` W. Wesley Groleau x4923 1997-09-09 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Robert Dewar 3 siblings, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-08 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` W. Wesley Groleau x4923 @ 1997-09-09 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-07 0:00 ` Darren New 1997-09-08 0:00 ` Darren New 1997-09-08 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` W. Wesley Groleau x4923 ` (2 more replies) 1997-09-10 0:00 ` Robert Dewar 3 siblings, 3 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Matthew Heaney 1997-09-10 0:00 ` Separation of IF and Imp: process issue? Nick Leaton 1997-09-18 0:00 ` Robert Dewar 2 siblings, 2 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-10 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Matthew Heaney 1 sibling, 0 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-10 0:00 ` Matthew Heaney 1997-09-12 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 1 sibling, 2 replies; 562+ messages in thread From: Matthew Heaney @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-10 0:00 ` Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Matthew Heaney @ 1997-09-12 0:00 ` Robert Dewar 1997-09-15 0:00 ` W. Wesley Groleau x4923 1997-09-16 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-12 0:00 ` Robert Dewar @ 1997-09-15 0:00 ` W. Wesley Groleau x4923 1997-09-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-15 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-15 0:00 ` W. Wesley Groleau x4923 @ 1997-09-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-10 0:00 ` Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Matthew Heaney 1997-09-12 0:00 ` Robert Dewar @ 1997-09-16 0:00 ` Don Harrison 1997-09-16 0:00 ` Joerg Rodemann 1997-09-20 0:00 ` Matthew Heaney 1 sibling, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Don Harrison @ 1997-09-16 0:00 ` Joerg Rodemann 1997-09-16 0:00 ` Owen Fellows ` (4 more replies) 1997-09-20 0:00 ` Matthew Heaney 1 sibling, 5 replies; 562+ messages in thread From: Joerg Rodemann @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Joerg Rodemann @ 1997-09-16 0:00 ` Owen Fellows 1997-09-16 0:00 ` Roger Browne ` (3 subsequent siblings) 4 siblings, 0 replies; 562+ messages in thread From: Owen Fellows @ 1997-09-16 0:00 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Joerg Rodemann 1997-09-16 0:00 ` Owen Fellows @ 1997-09-16 0:00 ` Roger Browne 1997-09-16 0:00 ` Robert A Duff 1997-09-16 0:00 ` Joachim Durchholz ` (2 subsequent siblings) 4 siblings, 1 reply; 562+ messages in thread From: Roger Browne @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Roger Browne @ 1997-09-16 0:00 ` Robert A Duff 1997-09-17 0:00 ` Franck Arnaud ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Robert A Duff @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Robert A Duff @ 1997-09-17 0:00 ` Franck Arnaud 1997-09-18 0:00 ` Don Harrison 1997-09-17 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Lee Webber 2 siblings, 1 reply; 562+ messages in thread From: Franck Arnaud @ 1997-09-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-17 0:00 ` Franck Arnaud @ 1997-09-18 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert A Duff 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-09-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-18 0:00 ` Don Harrison @ 1997-09-18 0:00 ` Robert A Duff 1997-09-18 0:00 ` Jon S Anthony ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Robert A Duff @ 1997-09-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-18 0:00 ` Robert A Duff @ 1997-09-18 0:00 ` Jon S Anthony 1997-09-18 0:00 ` Juergen Schlegelmilch 1997-09-20 0:00 ` Joachim Durchholz 2 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-18 0:00 ` Robert A Duff 1997-09-18 0:00 ` Jon S Anthony @ 1997-09-18 0:00 ` Juergen Schlegelmilch 1997-09-20 0:00 ` Joachim Durchholz 2 siblings, 0 replies; 562+ messages in thread From: Juergen Schlegelmilch @ 1997-09-18 0:00 UTC (permalink / raw) 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 +-----------------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-18 0:00 ` Robert A Duff 1997-09-18 0:00 ` Jon S Anthony 1997-09-18 0:00 ` Juergen Schlegelmilch @ 1997-09-20 0:00 ` Joachim Durchholz 2 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-09-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Robert A Duff 1997-09-17 0:00 ` Franck Arnaud @ 1997-09-17 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Lee Webber 2 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-09-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Robert A Duff 1997-09-17 0:00 ` Franck Arnaud 1997-09-17 0:00 ` Joachim Durchholz @ 1997-09-17 0:00 ` Lee Webber 2 siblings, 0 replies; 562+ messages in thread From: Lee Webber @ 1997-09-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Joerg Rodemann 1997-09-16 0:00 ` Owen Fellows 1997-09-16 0:00 ` Roger Browne @ 1997-09-16 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Paul Johnson 1997-09-17 0:00 ` Don Harrison 4 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-09-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Joerg Rodemann ` (2 preceding siblings ...) 1997-09-16 0:00 ` Joachim Durchholz @ 1997-09-17 0:00 ` Paul Johnson 1997-09-17 0:00 ` Don Harrison 4 siblings, 0 replies; 562+ messages in thread From: Paul Johnson @ 1997-09-17 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Joerg Rodemann ` (3 preceding siblings ...) 1997-09-17 0:00 ` Paul Johnson @ 1997-09-17 0:00 ` Don Harrison 4 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-16 0:00 ` Don Harrison 1997-09-16 0:00 ` Joerg Rodemann @ 1997-09-20 0:00 ` Matthew Heaney 1997-09-25 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-09-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-20 0:00 ` Matthew Heaney @ 1997-09-25 0:00 ` Don Harrison 1997-09-25 0:00 ` Matthew Heaney 1997-09-29 0:00 ` John G. Volan 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-09-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-25 0:00 ` Don Harrison @ 1997-09-25 0:00 ` Matthew Heaney 1997-09-26 0:00 ` Don Harrison 1997-09-29 0:00 ` John G. Volan 1 sibling, 1 reply; 562+ messages in thread From: Matthew Heaney @ 1997-09-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-25 0:00 ` Matthew Heaney @ 1997-09-26 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-09-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) 1997-09-25 0:00 ` Don Harrison 1997-09-25 0:00 ` Matthew Heaney @ 1997-09-29 0:00 ` John G. Volan 1 sibling, 0 replies; 562+ messages in thread From: John G. Volan @ 1997-09-29 0:00 UTC (permalink / raw) 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? :-) "); ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-18 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: Nick Leaton @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Separation of IF and Imp: process issue? Nick Leaton @ 1997-09-10 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-10 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Separation of IF and Imp: process issue? Nick Leaton @ 1997-09-18 0:00 ` Robert Dewar 2 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-07 0:00 ` Darren New ` (2 preceding siblings ...) 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Walter Mallory 1997-09-10 0:00 ` Darren New 3 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-10 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Robert Dewar @ 1997-09-10 0:00 ` Walter Mallory 1997-09-10 0:00 ` Darren New 1 sibling, 0 replies; 562+ messages in thread From: Walter Mallory @ 1997-09-10 0:00 UTC (permalink / raw) 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. -- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Walter Mallory @ 1997-09-10 0:00 ` Darren New 1 sibling, 0 replies; 562+ messages in thread From: Darren New @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <dewar.873826268@merv>]
* Re: Separation of IF and Imp: process issue? [not found] ` <dewar.873826268@merv> @ 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-11 0:00 ` Robert Dewar 0 siblings, 2 replies; 562+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Samuel Mize @ 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Scott Ingram 1997-09-11 0:00 ` Robert Dewar 1 sibling, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-10 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Scott Ingram 1997-09-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Scott Ingram @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Scott Ingram @ 1997-09-12 0:00 ` Robert Dewar 1997-09-12 0:00 ` Scott Ingram 0 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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 ... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-12 0:00 ` Robert Dewar @ 1997-09-12 0:00 ` Scott Ingram 0 siblings, 0 replies; 562+ messages in thread From: Scott Ingram @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` W. Wesley Groleau x4923 @ 1997-09-11 0:00 ` Robert Dewar 1 sibling, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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!) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-04 0:00 ` Matthew Heaney 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Darren New @ 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 0 replies; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-03 0:00 ` Patrick Doyle 1997-09-04 0:00 ` Matthew Heaney @ 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Samuel Mize ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-05 0:00 ` Samuel Mize 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 1 reply; 562+ messages in thread From: Samuel Mize @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Samuel Mize @ 1997-09-06 0:00 ` Patrick Doyle 0 siblings, 0 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Samuel Mize @ 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-06 0:00 ` Jon S Anthony 1997-09-07 0:00 ` Patrick Doyle 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-06 0:00 ` Jon S Anthony @ 1997-09-07 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Patrick Doyle @ 1997-09-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-07 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Patrick Doyle 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-09-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-08 0:00 ` Jon S Anthony @ 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Samuel Mize 1997-09-09 0:00 ` Matthew Heaney 0 siblings, 2 replies; 562+ messages in thread From: Patrick Doyle @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Samuel Mize 1997-09-09 0:00 ` Matthew Heaney 1 sibling, 0 replies; 562+ messages in thread From: Samuel Mize @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Samuel Mize @ 1997-09-09 0:00 ` Matthew Heaney 1 sibling, 0 replies; 562+ messages in thread From: Matthew Heaney @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Samuel Mize 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-06 0:00 ` Jon S Anthony 2 siblings, 1 reply; 562+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Separation of IF and Imp: process issue? 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <5u4941$9m1@gcsin3.geccs.gecm.com>]
* Re: Separation of IF and Imp: process issue? [not found] ` <5u4941$9m1@gcsin3.geccs.gecm.com> @ 1997-09-15 0:00 ` Michael Gacsaly 0 siblings, 0 replies; 562+ messages in thread From: Michael Gacsaly @ 1997-09-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <34026DE7.7D07@pseserv3.fw.hac.com>]
[parent not found: <3402C404.56812AFB@XYZZYcalfp.com>]
* Re: A DBC experience (was Re: Design by Contract) [not found] ` <3402C404.56812AFB@XYZZYcalfp.com> @ 1997-08-27 0:00 ` Simon Wright [not found] ` <5tvfdt$79g@inet-server.sit.fi> 1 sibling, 0 replies; 562+ messages in thread From: Simon Wright @ 1997-08-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <5tvfdt$79g@inet-server.sit.fi>]
[parent not found: <34050D8B.569F@deakin.edu.au>]
* Re: A DBC experience (was Re: Design by Contract) [not found] ` <34050D8B.569F@deakin.edu.au> @ 1997-08-28 0:00 ` Richie Bielak 1997-08-29 0:00 ` Peter Horan 0 siblings, 1 reply; 562+ messages in thread From: Richie Bielak @ 1997-08-28 0:00 UTC (permalink / raw) To: Peter Horan 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) * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: A DBC experience (was Re: Design by Contract) 1997-08-28 0:00 ` Richie Bielak @ 1997-08-29 0:00 ` Peter Horan 0 siblings, 0 replies; 562+ messages in thread From: Peter Horan @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <bengtk-2708972209500001@sl35.modempool.kth.se>]
* Re: Design by Contract [not found] ` <bengtk-2708972209500001@sl35.modempool.kth.se> @ 1997-08-28 0:00 ` Nick Leaton 0 siblings, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> ` (2 preceding siblings ...) 1997-08-25 0:00 ` Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 0 replies; 562+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ted Velkoff @ 1997-08-13 0:00 ` Don Harrison 1997-08-13 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Samuel Mize 1 sibling, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison @ 1997-08-13 0:00 ` Jon S Anthony 1997-08-15 0:00 ` Don Harrison 1997-08-13 0:00 ` Samuel Mize 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Jon S Anthony @ 1997-08-15 0:00 ` Don Harrison 1997-08-16 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Don Harrison @ 1997-08-16 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-08-13 0:00 ` Jon S Anthony @ 1997-08-13 0:00 ` Samuel Mize 1997-08-13 0:00 ` Robert A Duff 1 sibling, 1 reply; 562+ messages in thread From: Samuel Mize @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Samuel Mize @ 1997-08-13 0:00 ` Robert A Duff 1997-08-14 0:00 ` Jon S Anthony 1997-08-15 0:00 ` Don Harrison 0 siblings, 2 replies; 562+ messages in thread From: Robert A Duff @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Robert A Duff @ 1997-08-14 0:00 ` Jon S Anthony 1997-08-15 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Robert A Duff 1997-08-14 0:00 ` Jon S Anthony @ 1997-08-15 0:00 ` Don Harrison 1997-08-16 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Don Harrison @ 1997-08-16 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Ken Garlington 1997-08-12 0:00 ` Jon S Anthony @ 1997-08-23 0:00 ` W. Wesley Groleau x4923 1997-08-23 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-23 0:00 UTC (permalink / raw) > :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..... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-23 0:00 ` W. Wesley Groleau x4923 @ 1997-08-23 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-23 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington @ 1997-07-15 0:00 ` Wes Groleau 1997-07-15 0:00 ` Ken Garlington ` (2 more replies) 1997-07-16 0:00 ` Warwick Pulley 2 siblings, 3 replies; 562+ messages in thread From: Wes Groleau @ 1997-07-15 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Wes Groleau @ 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Don Harrison 1997-07-18 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-15 0:00 UTC (permalink / raw) 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! > ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Wes Groleau 1997-07-15 0:00 ` Ken Garlington @ 1997-07-16 0:00 ` Don Harrison 1997-07-16 0:00 ` Ken Garlington 1997-07-18 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Don Harrison @ 1997-07-16 0:00 ` Ken Garlington 1997-07-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Ken Garlington @ 1997-07-16 0:00 ` Robert Dewar 1997-07-17 0:00 ` Paul Johnson ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-16 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Robert Dewar @ 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Stuart Palin ` (2 more replies) 1997-07-18 0:00 ` Don Harrison 1997-07-20 0:00 ` Don Harrison 2 siblings, 3 replies; 562+ messages in thread From: Paul Johnson @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Paul Johnson @ 1997-07-17 0:00 ` Stuart Palin 1997-07-18 0:00 ` Ian Rae 1997-07-18 0:00 ` Paul Johnson 1997-07-17 0:00 ` Jon S Anthony 1997-07-18 0:00 ` Joachim Durchholz 2 siblings, 2 replies; 562+ messages in thread From: Stuart Palin @ 1997-07-17 0:00 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Stuart Palin @ 1997-07-18 0:00 ` Ian Rae 1997-07-18 0:00 ` Paul Johnson 1 sibling, 0 replies; 562+ messages in thread From: Ian Rae @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Stuart Palin 1997-07-18 0:00 ` Ian Rae @ 1997-07-18 0:00 ` Paul Johnson 1 sibling, 0 replies; 562+ messages in thread From: Paul Johnson @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Stuart Palin @ 1997-07-17 0:00 ` Jon S Anthony 1997-07-18 0:00 ` Joachim Durchholz 2 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Stuart Palin 1997-07-17 0:00 ` Jon S Anthony @ 1997-07-18 0:00 ` Joachim Durchholz 2 siblings, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Robert Dewar 1997-07-17 0:00 ` Paul Johnson @ 1997-07-18 0:00 ` Don Harrison 1997-07-20 0:00 ` Don Harrison 2 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Robert Dewar 1997-07-17 0:00 ` Paul Johnson 1997-07-18 0:00 ` Don Harrison @ 1997-07-20 0:00 ` Don Harrison 2 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Wes Groleau 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Don Harrison @ 1997-07-18 0:00 ` Robert I. Eachus 1997-07-21 0:00 ` W. Wesley Groleau x4923 2 siblings, 1 reply; 562+ messages in thread From: Robert I. Eachus @ 1997-07-18 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Robert I. Eachus @ 1997-07-21 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-21 0:00 UTC (permalink / raw) > > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 1997-07-15 0:00 ` Wes Groleau @ 1997-07-16 0:00 ` Warwick Pulley 1997-07-16 0:00 ` Nick Leaton 1997-07-17 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Warwick Pulley @ 1997-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Warwick Pulley @ 1997-07-16 0:00 ` Nick Leaton 1997-07-16 0:00 ` Robert Dewar 1997-07-17 0:00 ` Warwick Pulley 1997-07-17 0:00 ` Don Harrison 1 sibling, 2 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Nick Leaton @ 1997-07-16 0:00 ` Robert Dewar 1997-07-20 0:00 ` Joachim Durchholz 1997-07-21 0:00 ` Don Harrison 1997-07-17 0:00 ` Warwick Pulley 1 sibling, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-16 0:00 UTC (permalink / raw) <<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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Robert Dewar @ 1997-07-20 0:00 ` Joachim Durchholz 1997-07-24 0:00 ` Paul M Gover 1997-07-24 0:00 ` Joe Buck 1997-07-21 0:00 ` Don Harrison 1 sibling, 2 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-20 0:00 ` Joachim Durchholz @ 1997-07-24 0:00 ` Paul M Gover 1997-07-26 0:00 ` Joachim Durchholz 1997-07-24 0:00 ` Joe Buck 1 sibling, 1 reply; 562+ messages in thread From: Paul M Gover @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Paul M Gover @ 1997-07-26 0:00 ` Joachim Durchholz 1997-07-28 0:00 ` Robert S. White 1997-07-29 0:00 ` Don Harrison 0 siblings, 2 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-26 0:00 ` Joachim Durchholz @ 1997-07-28 0:00 ` Robert S. White 1997-08-09 0:00 ` Marinos J. Yannikos 1997-07-29 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Robert S. White @ 1997-07-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-28 0:00 ` Robert S. White @ 1997-08-09 0:00 ` Marinos J. Yannikos 1997-08-10 0:00 ` Robert S. White 1997-08-11 0:00 ` Peter Hamer 0 siblings, 2 replies; 562+ messages in thread From: Marinos J. Yannikos @ 1997-08-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-09 0:00 ` Marinos J. Yannikos @ 1997-08-10 0:00 ` Robert S. White 1997-08-11 0:00 ` Peter Hamer 1 sibling, 0 replies; 562+ messages in thread From: Robert S. White @ 1997-08-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-09 0:00 ` Marinos J. Yannikos 1997-08-10 0:00 ` Robert S. White @ 1997-08-11 0:00 ` Peter Hamer 1997-08-11 0:00 ` "Paul E. Bennett" 1 sibling, 1 reply; 562+ messages in thread From: Peter Hamer @ 1997-08-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-11 0:00 ` Peter Hamer @ 1997-08-11 0:00 ` "Paul E. Bennett" 0 siblings, 0 replies; 562+ messages in thread From: "Paul E. Bennett" @ 1997-08-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-26 0:00 ` Joachim Durchholz 1997-07-28 0:00 ` Robert S. White @ 1997-07-29 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-20 0:00 ` Joachim Durchholz 1997-07-24 0:00 ` Paul M Gover @ 1997-07-24 0:00 ` Joe Buck 1 sibling, 0 replies; 562+ messages in thread From: Joe Buck @ 1997-07-24 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Robert Dewar 1997-07-20 0:00 ` Joachim Durchholz @ 1997-07-21 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Nick Leaton 1997-07-16 0:00 ` Robert Dewar @ 1997-07-17 0:00 ` Warwick Pulley 1997-07-17 0:00 ` Nick Leaton 1997-07-17 0:00 ` Warwick Pulley 1 sibling, 2 replies; 562+ messages in thread From: Warwick Pulley @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Warwick Pulley @ 1997-07-17 0:00 ` Nick Leaton 1997-07-17 0:00 ` Ken Garlington ` (2 more replies) 1997-07-17 0:00 ` Warwick Pulley 1 sibling, 3 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Nick Leaton @ 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Richie Bielak [not found] ` <JSA.97Jul17174044@alexandria.organon.com> 2 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Nick Leaton 1997-07-17 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Richie Bielak 1997-07-17 0:00 ` Ken Garlington ` (3 more replies) [not found] ` <JSA.97Jul17174044@alexandria.organon.com> 2 siblings, 4 replies; 562+ messages in thread From: Richie Bielak @ 1997-07-17 0:00 UTC (permalink / raw) 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) * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Richie Bielak @ 1997-07-17 0:00 ` Ken Garlington 1997-07-23 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen ` (2 subsequent siblings) 3 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-17 0:00 UTC (permalink / raw) 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) * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison @ 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Ken Garlington @ 1997-07-25 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Richie Bielak 1997-07-17 0:00 ` Ken Garlington @ 1997-07-17 0:00 ` Karel Th�nissen 1997-07-17 0:00 ` Samuel Tardieu 1997-07-23 0:00 ` Don Harrison 3 siblings, 0 replies; 562+ messages in thread From: Karel Th�nissen @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Richie Bielak 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Karel Th�nissen @ 1997-07-17 0:00 ` Samuel Tardieu 1997-07-17 0:00 ` Richie Bielak 1997-07-23 0:00 ` Don Harrison 3 siblings, 1 reply; 562+ messages in thread From: Samuel Tardieu @ 1997-07-17 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Samuel Tardieu @ 1997-07-17 0:00 ` Richie Bielak 1997-07-23 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Richie Bielak @ 1997-07-17 0:00 UTC (permalink / raw) 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) * ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Richie Bielak @ 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison @ 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 1997-07-23 0:00 ` Jon S Anthony 1997-07-23 0:00 ` Karel Th�nissen 2 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Ken Garlington @ 1997-07-25 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington @ 1997-07-23 0:00 ` Jon S Anthony 1997-07-24 0:00 ` Don Harrison 1997-07-23 0:00 ` Karel Th�nissen 2 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Jon S Anthony @ 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Don Harrison @ 1997-07-24 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-23 0:00 ` Jon S Anthony @ 1997-07-23 0:00 ` Karel Th�nissen 1997-07-24 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Karel Th�nissen @ 1997-07-23 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Karel Th�nissen @ 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Ken Garlington 1997-07-24 0:00 ` Don Harrison 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-07-24 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Don Harrison @ 1997-07-24 0:00 ` Ken Garlington 1997-07-29 0:00 ` Don Harrison 1997-07-24 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Ken Garlington @ 1997-07-29 0:00 ` Don Harrison 1997-07-29 0:00 ` Ron Kohl 1997-07-31 0:00 ` Ken Garlington 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-07-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-29 0:00 ` Don Harrison @ 1997-07-29 0:00 ` Ron Kohl 1997-07-29 0:00 ` Don Harrison 1997-07-31 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Ron Kohl @ 1997-07-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-29 0:00 ` Ron Kohl @ 1997-07-29 0:00 ` Don Harrison 1997-07-30 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-29 0:00 ` Don Harrison @ 1997-07-30 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-29 0:00 ` Don Harrison 1997-07-29 0:00 ` Ron Kohl @ 1997-07-31 0:00 ` Ken Garlington 1997-08-07 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-31 0:00 UTC (permalink / raw) 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!) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-31 0:00 ` Ken Garlington @ 1997-08-07 0:00 ` Don Harrison 1997-08-07 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 ` Don Harrison @ 1997-08-07 0:00 ` Ken Garlington 1997-08-13 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 ` Ken Garlington @ 1997-08-13 0:00 ` Don Harrison 1997-08-13 0:00 ` Ken Garlington 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Don Harrison @ 1997-08-13 0:00 ` Ken Garlington 1997-08-14 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ken Garlington @ 1997-08-14 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-08-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Don Harrison @ 1997-08-15 0:00 ` Ken Garlington 1997-08-19 0:00 ` Don Harrison 1997-08-15 0:00 ` Lee Webber 1997-08-15 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Ken Garlington @ 1997-08-19 0:00 ` Don Harrison 1997-08-19 0:00 ` Lee Webber 1997-08-20 0:00 ` Ken Garlington 0 siblings, 2 replies; 562+ messages in thread From: Don Harrison @ 1997-08-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Don Harrison @ 1997-08-19 0:00 ` Lee Webber 1997-08-20 0:00 ` Ken Garlington 1 sibling, 0 replies; 562+ messages in thread From: Lee Webber @ 1997-08-19 0:00 UTC (permalink / raw) 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?) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Don Harrison 1997-08-19 0:00 ` Lee Webber @ 1997-08-20 0:00 ` Ken Garlington 1997-08-21 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-08-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-20 0:00 ` Ken Garlington @ 1997-08-21 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-08-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington @ 1997-08-15 0:00 ` Lee Webber 1997-08-19 0:00 ` Don Harrison 1997-08-15 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Lee Webber @ 1997-08-15 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Lee Webber @ 1997-08-19 0:00 ` Don Harrison 1997-08-19 0:00 ` Lee Webber 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Don Harrison @ 1997-08-19 0:00 ` Lee Webber 0 siblings, 0 replies; 562+ messages in thread From: Lee Webber @ 1997-08-19 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington 1997-08-15 0:00 ` Lee Webber @ 1997-08-15 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington 2 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Don Harrison @ 1997-08-15 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony 1997-08-19 0:00 ` Don Harrison 0 siblings, 2 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Ken Garlington @ 1997-08-16 0:00 ` Jon S Anthony 1997-08-19 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-08-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-15 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony @ 1997-08-19 0:00 ` Don Harrison 1997-08-20 0:00 ` Ken Garlington 1 sibling, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-08-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Don Harrison @ 1997-08-20 0:00 ` Ken Garlington 0 siblings, 0 replies; 562+ messages in thread From: Ken Garlington @ 1997-08-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Ken Garlington @ 1997-07-24 0:00 ` Don Harrison 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Richie Bielak ` (2 preceding siblings ...) 1997-07-17 0:00 ` Samuel Tardieu @ 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 3 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Don Harrison @ 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Ken Garlington @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Ken Garlington @ 1997-07-25 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <JSA.97Jul17174044@alexandria.organon.com>]
* Re: Safety-critical development in Ada and Eiffel [not found] ` <JSA.97Jul17174044@alexandria.organon.com> @ 1997-07-18 0:00 ` Joachim Durchholz 1997-07-18 0:00 ` Nick Leaton 1 sibling, 0 replies; 562+ messages in thread From: Joachim Durchholz @ 1997-07-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel [not found] ` <JSA.97Jul17174044@alexandria.organon.com> 1997-07-18 0:00 ` Joachim Durchholz @ 1997-07-18 0:00 ` Nick Leaton 1 sibling, 0 replies; 562+ messages in thread From: Nick Leaton @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Warwick Pulley 1997-07-17 0:00 ` Nick Leaton @ 1997-07-17 0:00 ` Warwick Pulley 1 sibling, 0 replies; 562+ messages in thread From: Warwick Pulley @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Warwick Pulley 1997-07-16 0:00 ` Nick Leaton @ 1997-07-17 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen ` (2 more replies) 1 sibling, 3 replies; 562+ messages in thread From: Don Harrison @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Don Harrison @ 1997-07-17 0:00 ` Karel Th�nissen 1997-07-21 0:00 ` Don Harrison 1997-07-17 0:00 ` Robert Dewar 1997-07-17 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: Karel Th�nissen @ 1997-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Karel Th�nissen @ 1997-07-21 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-21 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen @ 1997-07-17 0:00 ` Robert Dewar 1997-07-22 0:00 ` Don Harrison 1997-07-17 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-07-17 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Robert Dewar @ 1997-07-22 0:00 ` Don Harrison 0 siblings, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen 1997-07-17 0:00 ` Robert Dewar @ 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Don Harrison 2 siblings, 2 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-17 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Robert Dewar @ 1997-07-18 0:00 ` Jon S Anthony 1997-07-19 0:00 ` Robert A Duff 1997-07-21 0:00 ` Don Harrison 1 sibling, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Jon S Anthony @ 1997-07-19 0:00 ` Robert A Duff 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel W. Wesley Groleau x4923 0 siblings, 2 replies; 562+ messages in thread From: Robert A Duff @ 1997-07-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-19 0:00 ` Robert A Duff @ 1997-07-20 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Robert A Duff ` (2 more replies) 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel W. Wesley Groleau x4923 1 sibling, 3 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff @ 1997-07-21 0:00 ` Robert A Duff 1997-07-21 0:00 ` Brian Rogoff 1997-07-24 0:00 ` Morgan Palaeo Associates 1997-07-21 0:00 ` Robert Dewar 1997-07-21 0:00 ` Robert Dewar 2 siblings, 2 replies; 562+ messages in thread From: Robert A Duff @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-21 0:00 ` Robert A Duff @ 1997-07-21 0:00 ` Brian Rogoff 1997-07-24 0:00 ` Morgan Palaeo Associates 1 sibling, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-21 0:00 ` Robert A Duff 1997-07-21 0:00 ` Brian Rogoff @ 1997-07-24 0:00 ` Morgan Palaeo Associates 1997-07-24 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Morgan Palaeo Associates @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-24 0:00 ` Morgan Palaeo Associates @ 1997-07-24 0:00 ` Jon S Anthony [not found] ` <199707251337.PAA20933@basement.replay.com> 1997-08-01 0:00 ` J-P. Rosen 0 siblings, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <199707251337.PAA20933@basement.replay.com>]
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) [not found] ` <199707251337.PAA20933@basement.replay.com> @ 1997-07-26 0:00 ` Karel Th�nissen 0 siblings, 0 replies; 562+ messages in thread From: Karel Th�nissen @ 1997-07-26 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-24 0:00 ` Jon S Anthony [not found] ` <199707251337.PAA20933@basement.replay.com> @ 1997-08-01 0:00 ` J-P. Rosen 1997-08-01 0:00 ` Robert A Duff 1 sibling, 1 reply; 562+ messages in thread From: J-P. Rosen @ 1997-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-08-01 0:00 ` J-P. Rosen @ 1997-08-01 0:00 ` Robert A Duff 1997-08-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Robert A Duff @ 1997-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-08-01 0:00 ` Robert A Duff @ 1997-08-02 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-08-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff 1997-07-21 0:00 ` Robert A Duff @ 1997-07-21 0:00 ` Robert Dewar 1997-07-21 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Robert Dewar 2 siblings, 1 reply; 562+ messages in thread From: Robert Dewar @ 1997-07-21 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-21 0:00 ` Robert Dewar @ 1997-07-21 0:00 ` Brian Rogoff 1997-07-22 0:00 ` Robert Dewar 0 siblings, 1 reply; 562+ messages in thread From: Brian Rogoff @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-21 0:00 ` Brian Rogoff @ 1997-07-22 0:00 ` Robert Dewar 0 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Use use type? (Was Re: Safety-critical development in Ada and Eiffel) 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff 1997-07-21 0:00 ` Robert A Duff 1997-07-21 0:00 ` Robert Dewar @ 1997-07-21 0:00 ` Robert Dewar 2 siblings, 0 replies; 562+ messages in thread From: Robert Dewar @ 1997-07-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-19 0:00 ` Robert A Duff 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff @ 1997-07-21 0:00 ` W. Wesley Groleau x4923 1 sibling, 0 replies; 562+ messages in thread From: W. Wesley Groleau x4923 @ 1997-07-21 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Jon S Anthony @ 1997-07-21 0:00 ` Don Harrison 1997-07-21 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-21 0:00 ` Don Harrison @ 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Brian Rogoff 0 siblings, 1 reply; 562+ messages in thread From: Jon S Anthony @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-21 0:00 ` Jon S Anthony @ 1997-07-21 0:00 ` Brian Rogoff 0 siblings, 0 replies; 562+ messages in thread From: Brian Rogoff @ 1997-07-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` James Graves 1997-07-12 0:00 ` Ken Garlington @ 1997-07-16 0:00 ` Alan Brain 1997-07-18 0:00 ` Don Harrison 2 siblings, 1 reply; 562+ messages in thread From: Alan Brain @ 1997-07-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-16 0:00 ` Alan Brain @ 1997-07-18 0:00 ` Don Harrison 1997-07-22 0:00 ` Alan Brain 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-18 0:00 ` Don Harrison @ 1997-07-22 0:00 ` Alan Brain 1997-07-22 0:00 ` Don Harrison 0 siblings, 1 reply; 562+ messages in thread From: Alan Brain @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-22 0:00 ` Alan Brain @ 1997-07-22 0:00 ` Don Harrison 1997-07-23 0:00 ` Jon S Anthony 0 siblings, 1 reply; 562+ messages in thread From: Don Harrison @ 1997-07-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-22 0:00 ` Don Harrison @ 1997-07-23 0:00 ` Jon S Anthony 1997-07-24 0:00 ` Don Harrison 1997-07-25 0:00 ` Alan Brain 0 siblings, 2 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Jon S Anthony @ 1997-07-24 0:00 ` Don Harrison 1997-07-25 0:00 ` Alan Brain 1 sibling, 0 replies; 562+ messages in thread From: Don Harrison @ 1997-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-23 0:00 ` Jon S Anthony 1997-07-24 0:00 ` Don Harrison @ 1997-07-25 0:00 ` Alan Brain 1997-07-25 0:00 ` Jon S Anthony 1 sibling, 1 reply; 562+ messages in thread From: Alan Brain @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-07-25 0:00 ` Alan Brain @ 1997-07-25 0:00 ` Jon S Anthony 0 siblings, 0 replies; 562+ messages in thread From: Jon S Anthony @ 1997-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <slrn5rq1gc.che.abo@minkirri. <slrn5s1132.hf1.abo@minkirri.apana.org.au>]
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) [not found] ` <slrn5rq1gc.che.abo@minkirri. <slrn5s1132.hf1.abo@minkirri.apana.org.au> @ 1997-07-08 0:00 ` Richard Kenner 0 siblings, 0 replies; 562+ messages in thread From: Richard Kenner @ 1997-07-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 562+ messages in thread
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) 1997-07-02 0:00 ` Matthew Heaney 1997-07-03 0:00 ` Donovan Baarda @ 1997-07-08 0:00 ` Dale Pontius 1 sibling, 0 replies; 562+ messages in thread From: Dale Pontius @ 1997-07-08 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <33B16CBB.417A@gdesys <slrn5rn570.j6j.abo@minkirri.apana.org.au>]
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) [not found] ` <33B16CBB.417A@gdesys <slrn5rn570.j6j.abo@minkirri.apana.org.au> @ 1997-07-04 0:00 ` Samuel Mize 0 siblings, 0 replies; 562+ messages in thread From: Samuel Mize @ 1997-07-04 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 562+ messages in thread
[parent not found: <33B16CBB <slrn5rq1gc.che.abo@minkirri.apana.org.au>]
* Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) [not found] ` <33B16CBB <slrn5rq1gc.che.abo@minkirri.apana.org.au> @ 1997-07-05 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 562+ messages in thread From: Larry Kilgallen @ 1997-07-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 562+ messages in thread
end of thread, other threads:[~1997-09-29 0:00 UTC | newest] Thread overview: 562+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <33957A33.1C31AB44@oma.com> [not found] ` <865898351snz@nezumi.demon.co.uk> [not found] ` <339ED54C.215A5F85@oma.com> [not found] ` <5noc8u$a8m$3@miranda.gmrc.gecm.com> [not found] ` <33A032AC.2D8BA85C@oma.com> [not found] ` <5nrn86$cvo$3@miranda.gmrc.gecm.com> [not found] ` <33A1CBBB.B0602EC@oma.com> [not found] ` <5o2uls$ku3$2@miranda.gmrc.gecm.com> [not found] ` <33A6ADDA.2099EEB9@oma.com> [not found] ` <EBxM3y.8Eo@i2.COM> [not found] ` <33A7D2DE.545B@polaroid.com> [not found] ` <JSA.97Jun18155730@alexandria.organon.com> 1997-06-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Mukesh Prasad 1997-06-19 0:00 ` Is Ada " Jon S Anthony 1997-06-19 0:00 ` Is ADA " Steve Jones - JON 1997-06-19 0:00 ` Mukesh Prasad 1997-06-20 0:00 ` Robert Dewar 1997-06-22 0:00 ` Is ADA as good for graphics programming as C? (WAS: Jerry van Dijk 1997-06-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Tim Harrison 1997-06-23 0:00 ` Kaz Kylheku 1997-06-24 0:00 ` John Goodsen 1997-06-25 0:00 ` Michael Levasseur 1997-06-26 0:00 ` Chris Brand 1997-07-02 0:00 ` Matthew Heaney 1997-07-03 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Matthew Heaney 1997-07-04 0:00 ` Donovan Baarda 1997-07-04 0:00 ` Brian Rogoff 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Joachim Durchholz 1997-07-08 0:00 ` Brian Rogoff 1997-07-09 0:00 ` Don Harrison 1997-07-05 0:00 ` John Nagle 1997-07-05 0:00 ` Jon S Anthony 1997-07-07 0:00 ` Donovan Baarda 1997-07-08 0:00 ` Canada Bass 1997-07-08 0:00 ` Dale Pontius 1997-07-08 0:00 ` Martin Tom Brown 1997-07-09 0:00 ` Matthew Heaney 1997-07-10 0:00 ` Nick Leaton 1997-07-10 0:00 ` Matthew Heaney 1997-07-11 0:00 ` Nick Leaton 1997-07-14 0:00 ` Don Harrison 1997-07-15 0:00 ` Matthew Heaney 1997-07-15 0:00 ` Brian Rogoff 1997-07-16 0:00 ` Don Harrison 1997-07-17 0:00 ` Matthew Heaney 1997-07-18 0:00 ` Composition vs. Inheritance (was Re: Is ADA as good for graphics programming as C?) Robert I. Eachus 1997-07-19 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Nasser 1997-07-20 0:00 ` Brian Rogoff 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Andrew Dunstan 1997-07-21 0:00 ` Jon S Anthony [not found] ` <01bc94e1$46912100$53aa20cc@default> 1997-07-20 0:00 ` Is ADA as good for graphics programming as C? Matthew Heaney 1997-07-21 0:00 ` Dennis Weldy 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Robert C. Martin 1997-07-22 0:00 ` Relative complexity - Eiffel and Ada Don Harrison 1997-07-15 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Jon S Anthony 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Jon S Anthony 1997-07-15 0:00 ` Robert I. Eachus 1997-07-09 0:00 ` Don Harrison 1997-07-09 0:00 ` Tucker Taft 1997-07-10 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-07-10 0:00 ` Joe Gwinn 1997-07-11 0:00 ` Robert S. White 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Don Harrison 1997-07-10 0:00 ` Ken Garlington 1997-07-11 0:00 ` Ted Velkoff 1997-07-12 0:00 ` Ken Garlington 1997-07-13 0:00 ` Jon S Anthony 1997-07-14 0:00 ` Wes Groleau 1997-07-15 0:00 ` Jon S Anthony 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Paul Johnson 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Ken Garlington 1997-07-18 0:00 ` Paul Johnson 1997-07-18 0:00 ` Ken Garlington 1997-07-21 0:00 ` Paul Johnson 1997-07-18 0:00 ` Jon S Anthony 1997-07-17 0:00 ` Jon S Anthony [not found] ` <EDHqKo.K52@world.std.com> 1997-07-18 0:00 ` Jon S Anthony 1997-07-19 0:00 ` Robert A Duff 1997-07-20 0:00 ` Tucker Taft 1997-07-10 0:00 ` Mike Stark 1997-07-11 0:00 ` Donovan Baarda 1997-07-13 0:00 ` Steve Furlong 1997-07-16 0:00 ` Joachim Durchholz 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Jon S Anthony 1997-07-18 0:00 ` Nick Leaton 1997-07-18 0:00 ` Jon S Anthony 1997-07-18 0:00 ` John Nagle 1997-07-18 0:00 ` Jon S Anthony 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` Kazimir Majorinc 1997-07-12 0:00 ` Ken Garlington 1997-07-11 0:00 ` Don Harrison 1997-07-11 0:00 ` James Graves 1997-07-14 0:00 ` Don Harrison 1997-07-12 0:00 ` Ken Garlington 1997-07-15 0:00 ` Don Harrison 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Jean-Marc Jezequel 1997-07-16 0:00 ` Ken Garlington 1997-07-17 0:00 ` The stupidity of all the Ariane 5 analysts Thaddeus L. Olczyk [not found] ` <33CEAF05.6389@flash.net> 1997-07-20 0:00 ` Bertrand Meyer 1997-07-21 0:00 ` Ken Garlington 1997-07-31 0:00 ` Al Christians 1997-08-01 0:00 ` "Paul E. Bennett" 1997-08-01 0:00 ` Ken Garlington 1997-07-21 0:00 ` Ian Begg 1997-07-21 0:00 ` Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Jim Cochrane 1997-07-22 0:00 ` Jon S Anthony 1997-07-22 0:00 ` Ken Garlington 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert S. White 1997-07-21 0:00 ` Ken Garlington 1997-07-23 0:00 ` Robert S. White 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Robert S. White 1997-07-23 0:00 ` Robert Dewar 1997-07-24 0:00 ` Ken Garlington 1997-07-29 0:00 ` Shmuel (Seymour J.) Metz 1997-07-31 0:00 ` Robert Dewar 1997-08-01 0:00 ` Shmuel (Seymour J.) Metz 1997-08-04 0:00 ` Larry Kilgallen 1997-07-31 0:00 ` Warts was " Richard Irvine 1997-07-31 0:00 ` Robert Dewar 1997-08-05 0:00 ` Shmuel (Seymour J.) Metz [not found] ` <5scqlr$ju@news.sei.cmu.edu> 1997-08-07 0:00 ` Brian Rogoff 1997-08-08 0:00 ` Jon S Anthony 1997-08-08 0:00 ` Brian Rogoff 1997-08-10 0:00 ` Matthew Heaney 1997-08-10 0:00 ` Brian Rogoff 1997-08-19 0:00 ` Shmuel (Seymour J.) Metz [not found] ` <Pine.SGI.3.95.970807191944.13419A-100000@shellx <JSA.97Aug8161709@alexandria.organon.com> 1997-08-08 0:00 ` Robert A Duff 1997-08-11 0:00 ` Jon S Anthony 1997-08-08 0:00 ` Don Harrison 1997-08-11 0:00 ` Shmuel (Seymour J.) Metz 1997-07-25 0:00 ` Ariane 5,Eiffel, Ada Alan Brain 1997-07-21 0:00 ` The stupidity of all the Ariane 5 analysts Robert Dewar 1997-07-21 0:00 ` The presuppositions " Samuel Mize 1997-07-21 0:00 ` Ken Garlington 1997-07-22 0:00 ` Luther Hampton 1997-07-23 0:00 ` Samuel Mize 1997-07-23 0:00 ` Ken Garlington 1997-07-22 0:00 ` The stupidity " W. Wesley Groleau x4923 1997-07-23 0:00 ` Joerg Rodemann 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel "Paul E. Bennett" 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Safety-critical development in Ada and Eiffel - Ariane crash Joachim Durchholz 1997-07-18 0:00 ` Ken Garlington 1997-07-17 0:00 ` Safety-critical development in Ada and Eiffel Joachim Durchholz 1997-07-19 0:00 ` Ken Garlington 1997-07-21 0:00 ` Ada vs Eiffel (was: Safety-critical development in ...) W. Wesley Groleau x4923 1997-07-22 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel Robert S. White 1997-07-20 0:00 ` nabbasi 1997-07-21 0:00 ` W. Wesley Groleau x4923 1997-07-18 0:00 ` Don Harrison 1997-07-18 0:00 ` Ken Garlington 1997-07-22 0:00 ` Don Harrison 1997-07-21 0:00 ` Ken Garlington 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 1997-07-23 0:00 ` W. Wesley Groleau x4923 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Ken Garlington 1997-07-26 0:00 ` Joachim Durchholz 1997-07-31 0:00 ` Ken Garlington 1997-07-28 0:00 ` Nick Leaton 1997-07-28 0:00 ` Steve Jones - JON 1997-07-31 0:00 ` Ken Garlington 1997-07-29 0:00 ` Don Harrison 1997-07-31 0:00 ` Ken Garlington 1997-08-07 0:00 ` Don Harrison 1997-08-07 0:00 ` Ken Garlington 1997-08-09 0:00 ` Jim Cochrane 1997-08-11 0:00 ` Paul Johnson 1997-08-11 0:00 ` Ken Garlington 1997-08-12 0:00 ` Mark A Biggar 1997-08-19 0:00 ` Robert Dewar 1997-08-19 0:00 ` Bertrand Meyer 1997-08-19 0:00 ` Robert Dewar 1997-08-20 0:00 ` Lee Webber 1997-08-21 0:00 ` Don Harrison 1997-08-23 0:00 ` Ken Garlington 1997-08-20 0:00 ` Nick Leaton 1997-08-21 0:00 ` Joachim Durchholz 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Nick Leaton 1997-08-19 0:00 ` Nick Leaton 1997-08-20 0:00 ` Ken Garlington 1997-08-26 0:00 ` Richard A. O'Keefe 1997-08-13 0:00 ` Paul Johnson 1997-08-13 0:00 ` Ken Garlington 1997-08-15 0:00 ` Paul Johnson 1997-08-15 0:00 ` Ken Garlington 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 1997-08-20 0:00 ` Nick Leaton 1997-08-20 0:00 ` Nasser 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Nick Leaton 1997-08-23 0:00 ` Ken Garlington 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Ken Garlington 1997-08-12 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ken Garlington 1997-08-13 0:00 ` Ted Velkoff 1997-08-14 0:00 ` Matt Austern 1997-08-14 0:00 ` Ted Velkoff 1997-08-18 0:00 ` Matt Austern 1997-08-20 0:00 ` Joachim Durchholz 1997-08-21 0:00 ` Jon S Anthony 1997-08-22 0:00 ` Joachim Durchholz 1997-08-15 0:00 ` Ken Garlington 1997-08-16 0:00 ` Ted Velkoff 1997-08-16 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony 1997-08-16 0:00 ` Ken Garlington 1997-08-18 0:00 ` Ted Velkoff 1997-08-18 0:00 ` Ted Velkoff 1997-08-19 0:00 ` Ken Garlington 1997-08-14 0:00 ` Nick Leaton 1997-08-16 0:00 ` Robert Dewar 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington [not found] ` <JSA.97Aug25181856@alexandria.organon.com> [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer [not found] ` <JSA.97Aug26151833@alexandria.organon.com> 1997-08-27 0:00 ` Patrick Doyle 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> [not found] ` <3402E8C9.3384D976@calfp.co.uk> [not found] ` <dewar.872631036@merv> [not found] ` <3403F668.F6B57D97@calfp.co.uk> [not found] ` <34041331.0@news.uni-ulm.de> [not found] ` <3404696D.4487EB71@eiffel.com> 1997-08-27 0:00 ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Patrick Doyle 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> [not found] ` <JSA.97Aug29191413@alexandria.organon.com> [not found] ` <EFqDAG.2zn@ecf.toronto.edu> 1997-08-30 0:00 ` Jon S Anthony 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1997-09-04 0:00 ` Don Harrison 1997-09-05 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-10 0:00 ` Samuel Mize 1997-09-12 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Brian Rogoff 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1997-09-06 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 1997-09-14 0:00 ` Ken Garlington 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` John Viega 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Franck Arnaud 1997-08-28 0:00 ` Tucker Taft 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> 1997-08-29 0:00 ` Jon S Anthony 1997-08-30 0:00 ` Patrick Doyle 1997-08-30 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle 1997-08-29 0:00 ` Suzanne Zampella 1997-08-29 0:00 ` Jon S Anthony [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> 1997-09-07 0:00 ` Robert Dewar [not found] ` <3406A707.787D@dmu.ac.uk> 1997-08-29 0:00 ` a fairy tale (was: Re: Interface/Implementation ) Fred Long 1997-08-29 0:00 ` Interface/Implementation (was Re: Design by Contract) Joerg Rodemann 1997-08-29 0:00 ` Ralph Paul 1997-09-01 0:00 ` In defence of plain ascii files ( was " Chris RL Morgan 1997-09-01 0:00 ` Don Harrison 1997-08-27 0:00 ` Design by Contract Matt Kennel (Remove 'NOSPAM' to reply) 1997-08-27 0:00 ` Ted Velkoff [not found] ` <34050F3C.5A3A@invest.amp.com.au> 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Paul Johnson 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-01 0:00 ` John F. Bell III 1997-09-02 0:00 ` Ken Garlington 1997-09-05 0:00 ` Robert Dewar [not found] ` <dewar.872887402@merv> 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale [not found] ` <EFxx8q.2sw@ecf.toronto.edu> 1997-09-04 0:00 ` Thomas Beale 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Ken Garlington [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> 1997-08-28 0:00 ` Mark Bennison 1997-08-28 0:00 ` Separation of IF and Imp: process issue? Jeff Kotula [not found] ` <x7vd8myyrzx.fsf@pogner.demon.co.uk> 1997-08-30 0:00 ` Patrick Doyle 1997-08-31 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Patrick Doyle 1997-09-03 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-08 0:00 ` Erik Magnuson 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Patrick Doyle [not found] ` <x7vzppy250u.fsf@pogner.demon.co.uk> 1997-09-01 0:00 ` Patrick Doyle [not found] ` <mheaney-ya023680000209972131260001@news.ni.net> 1997-09-03 0:00 ` Patrick Doyle 1997-09-04 0:00 ` Matthew Heaney 1997-09-05 0:00 ` Patrick Doyle 1997-09-08 0:00 ` John G. Volan 1997-09-09 0:00 ` Nick Leaton 1997-09-05 0:00 ` Darren New 1997-09-06 0:00 ` Matthew Heaney 1997-09-07 0:00 ` Darren New 1997-09-08 0:00 ` Darren New 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` John G. Volan 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Darren New 1997-09-09 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` Brian Rogoff 1997-09-12 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Jon S Anthony 1997-09-12 0:00 ` Robert A Duff 1997-09-13 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Mark A Biggar 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Peter Hermann 1997-09-12 0:00 ` Robert Dewar 1997-09-12 0:00 ` Jon S Anthony 1997-09-10 0:00 ` Darren New 1997-09-11 0:00 ` Joerg Rodemann 1997-09-11 0:00 ` Darren New 1997-09-12 0:00 ` Joerg Rodemann 1997-09-12 0:00 ` Darren New 1997-09-09 0:00 ` Nick Leaton 1997-09-09 0:00 ` Jon S Anthony 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris 1997-09-10 0:00 ` news_check.py 1997-09-11 0:00 ` Robert Dewar 1997-09-16 0:00 ` Owen Fellows 1997-09-09 0:00 ` Fergus Henderson 1997-09-10 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 1997-09-08 0:00 ` W. Wesley Groleau x4923 1997-09-09 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Matthew Heaney 1997-09-12 0:00 ` Robert Dewar 1997-09-15 0:00 ` W. Wesley Groleau x4923 1997-09-16 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 1997-09-16 0:00 ` Joerg Rodemann 1997-09-16 0:00 ` Owen Fellows 1997-09-16 0:00 ` Roger Browne 1997-09-16 0:00 ` Robert A Duff 1997-09-17 0:00 ` Franck Arnaud 1997-09-18 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert A Duff 1997-09-18 0:00 ` Jon S Anthony 1997-09-18 0:00 ` Juergen Schlegelmilch 1997-09-20 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Lee Webber 1997-09-16 0:00 ` Joachim Durchholz 1997-09-17 0:00 ` Paul Johnson 1997-09-17 0:00 ` Don Harrison 1997-09-20 0:00 ` Matthew Heaney 1997-09-25 0:00 ` Don Harrison 1997-09-25 0:00 ` Matthew Heaney 1997-09-26 0:00 ` Don Harrison 1997-09-29 0:00 ` John G. Volan 1997-09-10 0:00 ` Separation of IF and Imp: process issue? Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-18 0:00 ` Robert Dewar 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Walter Mallory 1997-09-10 0:00 ` Darren New [not found] ` <dewar.873826268@merv> 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Scott Ingram 1997-09-12 0:00 ` Robert Dewar 1997-09-12 0:00 ` Scott Ingram 1997-09-11 0:00 ` Robert Dewar 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Samuel Mize 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Jon S Anthony 1997-09-07 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Samuel Mize 1997-09-09 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-06 0:00 ` Jon S Anthony [not found] ` <5u4941$9m1@gcsin3.geccs.gecm.com> 1997-09-15 0:00 ` Michael Gacsaly [not found] ` <34026DE7.7D07@pseserv3.fw.hac.com> [not found] ` <3402C404.56812AFB@XYZZYcalfp.com> 1997-08-27 0:00 ` A DBC experience (was Re: Design by Contract) Simon Wright [not found] ` <5tvfdt$79g@inet-server.sit.fi> [not found] ` <34050D8B.569F@deakin.edu.au> 1997-08-28 0:00 ` Richie Bielak 1997-08-29 0:00 ` Peter Horan [not found] ` <bengtk-2708972209500001@sl35.modempool.kth.se> 1997-08-28 0:00 ` Design by Contract Nick Leaton 1997-08-25 0:00 ` Bertrand Meyer 1997-08-13 0:00 ` Safety-critical development in Ada and Eiffel Don Harrison 1997-08-13 0:00 ` Jon S Anthony 1997-08-15 0:00 ` Don Harrison 1997-08-16 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Samuel Mize 1997-08-13 0:00 ` Robert A Duff 1997-08-14 0:00 ` Jon S Anthony 1997-08-15 0:00 ` Don Harrison 1997-08-16 0:00 ` Ken Garlington 1997-08-23 0:00 ` W. Wesley Groleau x4923 1997-08-23 0:00 ` Robert Dewar 1997-07-15 0:00 ` Wes Groleau 1997-07-15 0:00 ` Ken Garlington 1997-07-16 0:00 ` Don Harrison 1997-07-16 0:00 ` Ken Garlington 1997-07-16 0:00 ` Robert Dewar 1997-07-17 0:00 ` Paul Johnson 1997-07-17 0:00 ` Stuart Palin 1997-07-18 0:00 ` Ian Rae 1997-07-18 0:00 ` Paul Johnson 1997-07-17 0:00 ` Jon S Anthony 1997-07-18 0:00 ` Joachim Durchholz 1997-07-18 0:00 ` Don Harrison 1997-07-20 0:00 ` Don Harrison 1997-07-18 0:00 ` Robert I. Eachus 1997-07-21 0:00 ` W. Wesley Groleau x4923 1997-07-16 0:00 ` Warwick Pulley 1997-07-16 0:00 ` Nick Leaton 1997-07-16 0:00 ` Robert Dewar 1997-07-20 0:00 ` Joachim Durchholz 1997-07-24 0:00 ` Paul M Gover 1997-07-26 0:00 ` Joachim Durchholz 1997-07-28 0:00 ` Robert S. White 1997-08-09 0:00 ` Marinos J. Yannikos 1997-08-10 0:00 ` Robert S. White 1997-08-11 0:00 ` Peter Hamer 1997-08-11 0:00 ` "Paul E. Bennett" 1997-07-29 0:00 ` Don Harrison 1997-07-24 0:00 ` Joe Buck 1997-07-21 0:00 ` Don Harrison 1997-07-17 0:00 ` Warwick Pulley 1997-07-17 0:00 ` Nick Leaton 1997-07-17 0:00 ` Ken Garlington 1997-07-17 0:00 ` Richie Bielak 1997-07-17 0:00 ` Ken Garlington 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen 1997-07-17 0:00 ` Samuel Tardieu 1997-07-17 0:00 ` Richie Bielak 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison 1997-07-23 0:00 ` Jon S Anthony 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Jon S Anthony 1997-07-23 0:00 ` Karel Th�nissen 1997-07-24 0:00 ` Don Harrison 1997-07-24 0:00 ` Ken Garlington 1997-07-29 0:00 ` Don Harrison 1997-07-29 0:00 ` Ron Kohl 1997-07-29 0:00 ` Don Harrison 1997-07-30 0:00 ` Don Harrison 1997-07-31 0:00 ` Ken Garlington 1997-08-07 0:00 ` Don Harrison 1997-08-07 0:00 ` Ken Garlington 1997-08-13 0:00 ` Don Harrison 1997-08-13 0:00 ` Ken Garlington 1997-08-14 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington 1997-08-19 0:00 ` Don Harrison 1997-08-19 0:00 ` Lee Webber 1997-08-20 0:00 ` Ken Garlington 1997-08-21 0:00 ` Don Harrison 1997-08-15 0:00 ` Lee Webber 1997-08-19 0:00 ` Don Harrison 1997-08-19 0:00 ` Lee Webber 1997-08-15 0:00 ` Don Harrison 1997-08-15 0:00 ` Ken Garlington 1997-08-16 0:00 ` Jon S Anthony 1997-08-19 0:00 ` Don Harrison 1997-08-20 0:00 ` Ken Garlington 1997-07-24 0:00 ` Don Harrison 1997-07-23 0:00 ` Don Harrison 1997-07-23 0:00 ` Ken Garlington 1997-07-25 0:00 ` Don Harrison [not found] ` <JSA.97Jul17174044@alexandria.organon.com> 1997-07-18 0:00 ` Joachim Durchholz 1997-07-18 0:00 ` Nick Leaton 1997-07-17 0:00 ` Warwick Pulley 1997-07-17 0:00 ` Don Harrison 1997-07-17 0:00 ` Karel Th�nissen 1997-07-21 0:00 ` Don Harrison 1997-07-17 0:00 ` Robert Dewar 1997-07-22 0:00 ` Don Harrison 1997-07-17 0:00 ` Robert Dewar 1997-07-18 0:00 ` Jon S Anthony 1997-07-19 0:00 ` Robert A Duff 1997-07-20 0:00 ` Use use type? (Was Re: Safety-critical development in Ada and Eiffel) Brian Rogoff 1997-07-21 0:00 ` Robert A Duff 1997-07-21 0:00 ` Brian Rogoff 1997-07-24 0:00 ` Morgan Palaeo Associates 1997-07-24 0:00 ` Jon S Anthony [not found] ` <199707251337.PAA20933@basement.replay.com> 1997-07-26 0:00 ` Karel Th�nissen 1997-08-01 0:00 ` J-P. Rosen 1997-08-01 0:00 ` Robert A Duff 1997-08-02 0:00 ` Robert Dewar 1997-07-21 0:00 ` Robert Dewar 1997-07-21 0:00 ` Brian Rogoff 1997-07-22 0:00 ` Robert Dewar 1997-07-21 0:00 ` Robert Dewar 1997-07-21 0:00 ` Safety-critical development in Ada and Eiffel W. Wesley Groleau x4923 1997-07-21 0:00 ` Don Harrison 1997-07-21 0:00 ` Jon S Anthony 1997-07-21 0:00 ` Brian Rogoff 1997-07-16 0:00 ` Alan Brain 1997-07-18 0:00 ` Don Harrison 1997-07-22 0:00 ` Alan Brain 1997-07-22 0:00 ` Don Harrison 1997-07-23 0:00 ` Jon S Anthony 1997-07-24 0:00 ` Don Harrison 1997-07-25 0:00 ` Alan Brain 1997-07-25 0:00 ` Jon S Anthony [not found] ` <slrn5rq1gc.che.abo@minkirri. <slrn5s1132.hf1.abo@minkirri.apana.org.au> 1997-07-08 0:00 ` Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Richard Kenner 1997-07-08 0:00 ` Dale Pontius [not found] ` <33B16CBB.417A@gdesys <slrn5rn570.j6j.abo@minkirri.apana.org.au> 1997-07-04 0:00 ` Samuel Mize [not found] ` <33B16CBB <slrn5rq1gc.che.abo@minkirri.apana.org.au> 1997-07-05 0:00 ` Larry Kilgallen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox