* Help Me Please :) @ 2000-02-29 0:00 Will Mann 2000-03-01 0:00 ` Robert Dewar 0 siblings, 1 reply; 54+ messages in thread From: Will Mann @ 2000-02-29 0:00 UTC (permalink / raw) Can some one help me with my Ada.. my lecturer has given me code that doesn't work... the compiler says that it can't handle "A".."Z" the error message is : Inappropriate operands for "DOT_DOT" operation, continuing Thanks -- :\ / | | ALL DONE BYE BYE! : \ /\ / * | | : \/ \/ | |__ |__ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 Help Me Please :) Will Mann @ 2000-03-01 0:00 ` Robert Dewar 2000-03-03 0:00 ` Florian Weimer 0 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 2000-03-01 0:00 UTC (permalink / raw) In article <38BC4EAF.209AE20C@port.ac.uk>, Will Mann <csm90231@port.ac.uk> wrote: > Can some one help me with my Ada.. my lecturer has given me code that > doesn't work... the compiler says that it can't handle "A".."Z" the > error message is : > > Inappropriate operands for "DOT_DOT" operation, continuing Well here is how you might be able to find that out for yourself. Obviously the compiler does not like the operands for your .. expression, so look up in your Ada book the rules for .. and you will find that discrete types are required. Now look up discrete types, and you will find that they include integer and enumeration types, including particular character types. Clearly you are trying for the latter here, so go look up what character literals should look like, and you will find that they use single quotes, so you should have written 'a' .. 'z' I think you might have had an easier type finding the error for yourself with GNAT: g.adb:3:17: expected a discrete type g.adb:3:17: found a string type In general I think the error messages from GNAT are likely to be clearer for a beginner (or anyone else for that matter), since huge effort has gone into making the messages clear. You might consider getting hold of a copy of GNAT (which is available for free download -- go to the ftp directories at cs.nyu.edu, directory /pub/gnat). At the very least, if you get another message you don't understand, you can try and see what GNAT says :-) Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-01 0:00 ` Robert Dewar @ 2000-03-03 0:00 ` Florian Weimer 2000-03-03 0:00 ` tmoran [not found] ` <2000Mar3.183321.69279@ludens> 0 siblings, 2 replies; 54+ messages in thread From: Florian Weimer @ 2000-03-03 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In general I think the error messages from GNAT are likely to > be clearer for a beginner (or anyone else for that matter), > since huge effort has gone into making the messages clear. The GNAT compiler error messages are remarkably clear, but the GNARL (i.e. runtime) "messages" (i.e. text messages associated with an exception) are mostly non-existent. For example, I think it would be very nice to get the information that a certain Program_Error exception was caused by a failed Accessibility_Check. Are other compilers different in this regard? -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE RUS-CERT, Univ. Stuttgart http://cert.uni-stuttgart.de/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-03 0:00 ` Florian Weimer @ 2000-03-03 0:00 ` tmoran 2000-03-04 0:00 ` Richard D Riehle [not found] ` <2000Mar3.183321.69279@ludens> 1 sibling, 1 reply; 54+ messages in thread From: tmoran @ 2000-03-03 0:00 UTC (permalink / raw) >For example, I think it would be >very nice to get the information that a certain Program_Error >exception was caused by a failed Accessibility_Check. > >Are other compilers different in this regard? Yes. Compiler differ a lot in what you get from Ada.Exceptions.Exception_Information. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-03 0:00 ` tmoran @ 2000-03-04 0:00 ` Richard D Riehle 2000-03-05 0:00 ` Steve Arnold 2000-03-17 0:00 ` Robert A Duff 0 siblings, 2 replies; 54+ messages in thread From: Richard D Riehle @ 2000-03-04 0:00 UTC (permalink / raw) In article <lJSv4.1648$im1.34999@news.pacbell.net>, tmoran@bix.com wrote: >>For example, I think it would be >>very nice to get the information that a certain Program_Error >>exception was caused by a failed Accessibility_Check. >> >>Are other compilers different in this regard? > Yes. Compiler differ a lot in what you get from >Ada.Exceptions.Exception_Information. It has often been noted, by those in the embedded software community, that the features of Ada.Exceptions are not very useful. "Who wants to be passing all those strings around all the time?" In other environments, especially command and control systems, this package is turning out to be useful. I have taken to describing the exception handling event in terms of electrical design. We can overload a circuit and burn down the house. We can install a fuse and prevent the overload from doing its damage. We can design the exception handler as a software circuit-breaker that detects the problem, corrects it, resets itself, and continues on with normal processing. The non-stop characteristics of a command and control system dictate that the exception handling often be designed as a software circuit-breaker rather than a fuse. We see this in many software designs, regardless of language. The problem with Ada is its designation of exceptions as something slightly apart from a typical data type. In some languages, exceptions are first class objects. Ada exceptions are not first class objects for very good reasons. However, it is sometimes useful to promote them to first class objects and benefit from whatever information one can get when the software circuit-breaker is triggered. One way to promote an Ada exception to a first class object is to declare it as an Ada.Exceptions.Exception_Occurrence. A compiler, such as that from Aonix or RR Software, that returns detailed information in a call to the function, Ada.Exceptions.Exception_Information, permits the developer to design a logging module for later review of software circuit-breaker events. In fact, the package is designed to permit an access to an exception occurrence, thereby implying some capabilities one could find very useful in a CCC3I/CCC4I environment. I have decided to include an entire chapter on this topic in the book I have been writing about Object Technology in Ada. It is taking longer to finish this book than I expected because I keep coming up with ideas. I guess we call this "feature creep" in software development. As soon as some publisher says they want to take it "as is" I'll stop and turn it over to them as a first edition. Meanwhile, working on it keeps me out of trouble. Richard Riehle ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-04 0:00 ` Richard D Riehle @ 2000-03-05 0:00 ` Steve Arnold 2000-03-17 0:00 ` Robert A Duff 1 sibling, 0 replies; 54+ messages in thread From: Steve Arnold @ 2000-03-05 0:00 UTC (permalink / raw) Richard D Riehle wrote: > I have decided to include an entire chapter on this topic in the book I have been > writing about Object Technology in Ada. It is taking longer to finish this book > than I expected because I keep coming up with ideas. I guess we call this "feature > creep" in software development. As soon as some publisher says they want to take > it "as is" I'll stop and turn it over to them as a first edition. Meanwhile, working > on it keeps me out of trouble. Come on Richard, I've been waiting long enough (and Jeff's class is getting obtuse). When can we expect to take a look at this book? ********************************************************************** Steve Arnold sarnold@earthling.net "We'll chase them like rats across the tundra!" -unknown ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-04 0:00 ` Richard D Riehle 2000-03-05 0:00 ` Steve Arnold @ 2000-03-17 0:00 ` Robert A Duff 2000-03-18 0:00 ` James S. Rogers ` (3 more replies) 1 sibling, 4 replies; 54+ messages in thread From: Robert A Duff @ 2000-03-17 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > In some languages, exceptions are first class objects. Ada exceptions are > not first class objects for very good reasons. ^^^^^^^^^^^^^^^^^ I beg to differ. I think this is one of the few cases where those other languages got it right, and Ada got it wrong. If you want strings, Ada.Exceptions works OK (although it's annoying to have "exceptions" and "Exception_Ids", which are both essentially representations of the same concept). If you want to attach some other type of data to an exception, you're stuck with several poor alternatives: You could encode that data as a String, but then you lose type checking -- the declaration of an exception ought to declare the type of attached data, forming a compile-time-checkable contract between the raise point and the handler point. Or you could store the information in a global, but then you lose task safety, and there are issues of exactly when that global data is valid. Etc. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-17 0:00 ` Robert A Duff @ 2000-03-18 0:00 ` James S. Rogers 2000-03-19 0:00 ` Robert A Duff 2000-03-18 0:00 ` Richard D Riehle ` (2 subsequent siblings) 3 siblings, 1 reply; 54+ messages in thread From: James S. Rogers @ 2000-03-18 0:00 UTC (permalink / raw) Robert A Duff wrote in message ... >Richard D Riehle <laoXhai@ix.netcom.com> writes: > >> In some languages, exceptions are first class objects. Ada exceptions are >> not first class objects for very good reasons. > ^^^^^^^^^^^^^^^^^ > >I beg to differ. I think this is one of the few cases where those other >languages got it right, and Ada got it wrong. Have you ever used exceptions in C++? Very few people do. The problem arises from the fact that exceptions are first class objects. In C++ you cannot "catch" an exception without knowing its type. This means that you must have exquisite coupling with all your dependent compilation units to use exceptions reliably. This coupling requirement works strongly against encapsulation and modularity. The only way around this is to declare a single exception type for all exceptions generated by an application. This leaves you in the same position as you are in Ada. Of course, the problem with this solution for C++ is that you will probably use class libraries, which, if they use exceptions at all, will probably not conform to the exception class chosen by your team. If this is the case, then you are in a much worse situation than if you used Ada. Jim Rogers Colorado Springs, Colorado ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-18 0:00 ` James S. Rogers @ 2000-03-19 0:00 ` Robert A Duff 2000-03-20 0:00 ` Brian Rogoff 0 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 2000-03-19 0:00 UTC (permalink / raw) "James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes: > Have you ever used exceptions in C++? No. The last time I used C++ (some years ago), most compilers did not support exceptions. The closest I could get was reading about them in Stroustrup's book. But I have used exceptions in other languages that define exceptions as first-class objects. >...Very few people do. > The problem arises from the fact that exceptions are first class objects. I don't understand this problem. Perhaps you could give an example? Is the problem you're talking about C++-specific, or are you claiming it's a fundamental problem with the idea of exceptions-as-objects? One problem I see with C++ exceptions is that anything can be an exception -- you can throw a string or an int or whatever. I would prefer to have a distinguished exception class, and then you could define new exceptions by subclassing that. Several other languages that have first-class exceptions do exactly that. But this seems like a minor issue. > In C++ you cannot "catch" an exception without knowing its type. This means > that you must have exquisite coupling with all your dependent compilation > units > to use exceptions reliably. This coupling requirement works strongly against > encapsulation and modularity. Again, I don't get it. Of course you can't catch an exception without knowing its type. Just like in Ada you can't handle an exception without knowing its name. I don't see how that breaks encapsulation and modularity. > The only way around this is to declare a single exception type for all > exceptions > generated by an application. This leaves you in the same position as you are > in Ada. Of course, the problem with this solution for C++ is that you will > probably use > class libraries, which, if they use exceptions at all, will probably not > conform to the > exception class chosen by your team. If this is the case, then you are in a > much > worse situation than if you used Ada. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-19 0:00 ` Robert A Duff @ 2000-03-20 0:00 ` Brian Rogoff 2000-03-20 0:00 ` Tucker Taft 0 siblings, 1 reply; 54+ messages in thread From: Brian Rogoff @ 2000-03-20 0:00 UTC (permalink / raw) On Sun, 19 Mar 2000, Robert A Duff wrote: > "James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes: > > > Have you ever used exceptions in C++? > > No. The last time I used C++ (some years ago), most compilers did not > support exceptions. The closest I could get was reading about them in > Stroustrup's book. But I have used exceptions in other languages that > define exceptions as first-class objects. > > >...Very few people do. > > The problem arises from the fact that exceptions are first class objects. > > I don't understand this problem. Perhaps you could give an example? Is > the problem you're talking about C++-specific, or are you claiming it's > a fundamental problem with the idea of exceptions-as-objects? I agree with Bob Duff here, in that I don't understand. When I was hacking Java, my complaint about the exception mechanism wasn't that you could throw objects, it was that you had to declare or catch all exceptions, which causes lots of people to subclass from RuntimeException to avoid this. But that's not the issue at hand. I think exception types would be a good thing, but its way too late to fix that now, and it was probably too late for Ada 95. A future Ada-inspired language could fix this. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-20 0:00 ` Brian Rogoff @ 2000-03-20 0:00 ` Tucker Taft 0 siblings, 0 replies; 54+ messages in thread From: Tucker Taft @ 2000-03-20 0:00 UTC (permalink / raw) Brian Rogoff wrote: > ... > I think exception types would be a good thing, but its way too late to fix > that now, and it was probably too late for Ada 95. In fact, early in the Ada 9X process we proposed the equivalent of parameterized exceptions that formed a hierarchy. All quite elegant. It could still be done in my view. It was just beyond what the reviewers were ready for at the time. An alternative simpler addition is to add a package "Ada.Exceptions.Objects" or equivalent, which allows one to "Raise_With_Object" where you could pass in an object of any type extended from, say, Exception_Object_Root, and be able to retrieve it given an Exception_Occurrence, in the same way one can pass in a string, and retrieve it. We might set some arbitrary upper limit on the 'Size of the object passed in that must be supported by an implementation, e.g. 1500 bits (analogous to the 200 character limit for exception messages). > ... A future Ada-inspired > language could fix this. It's really not that far fetched. E.g.: Out_Of_Space : Exception(X : Integer; Y : access Blob) is new Storage_Error; ... raise Out_Of_Space(X => 5, Y => Blurfo'Access); ... when OOS : Out_Of_Space => Put_Line("Out of space, needed: " & Integer'Image(OOS.X)); > -- Brian -Tuck -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-17 0:00 ` Robert A Duff 2000-03-18 0:00 ` James S. Rogers @ 2000-03-18 0:00 ` Richard D Riehle 2000-03-20 0:00 ` Florian Weimer 2000-03-22 0:00 ` Mats Weber 3 siblings, 0 replies; 54+ messages in thread From: Richard D Riehle @ 2000-03-18 0:00 UTC (permalink / raw) In article <wccog8dqvk6.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >Richard D Riehle <laoXhai@ix.netcom.com> writes: > >> In some languages, exceptions are first class objects. >> Ada exceptions are not first class objects for very good reasons. > ^^^^^^^^^^^^^^^^^ >>I beg to differ. I think this is one of the few cases where those other >languages got it right, and Ada got it wrong. Delighted to have this response from you. I have been spending some time with C++ lately and find the exception model to be confusing, error-prone, and more complicated than necessary. One reason I like the Ada model is its simplicity compared to other languages. We can agree to disagree on this. >If you want strings, Ada.Exceptions works OK (although it's annoying to >have "exceptions" and "Exception_Ids", which are both essentially >representations of the same concept). If you want to attach some other >type of data to an exception, you're stuck with several poor >alternatives: You could encode that data as a String, but then you lose >type checking -- the declaration of an exception ought to declare the >type of attached data, forming a compile-time-checkable contract between >the raise point and the handler point. Or you could store the >information in a global, but then you lose task safety, and there are >issues of exactly when that global data is valid. Etc. For embedded systems, one does not want to be, in the words of Dr. Tokar of DDC-I, ..."passing strings all over the place." Also, for non-embedded systems, not all compilers adequately support the facilities of Ada.Exceptions, especially. Janus and ObjectAda have pretty good support for the function, Exception_Information, but some others do not. The reason for promoting an exception to a typed value has to be compelling. Consequently, it is rarely necessary. In an application such as a non-stop command and control system, one could find compelling reasons for wrapping an exception_occurrence in a tagged type and referring to it during some lull in activity as part of a logging operation. There are other circumstances when promoting an exception to a first-class object might be compelling. In the absence of such compelling circumstances, insisting that an exception be a first-class object simply complicates the entire exception handling process. The Ada solution, which provides the option of promoting it to a first-class object, seems to me the optimal solution. Thanks for you insight on this. I beleive it is an important thread of discussion about Ada, one we do not visit often enough. Richard Riehle richard@adaworks.com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-17 0:00 ` Robert A Duff 2000-03-18 0:00 ` James S. Rogers 2000-03-18 0:00 ` Richard D Riehle @ 2000-03-20 0:00 ` Florian Weimer 2000-03-22 0:00 ` Mats Weber 3 siblings, 0 replies; 54+ messages in thread From: Florian Weimer @ 2000-03-20 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > Richard D Riehle <laoXhai@ix.netcom.com> writes: > > > In some languages, exceptions are first class objects. Ada exceptions are > > not first class objects for very good reasons. > ^^^^^^^^^^^^^^^^^ > > I beg to differ. I think this is one of the few cases where those other > languages got it right, and Ada got it wrong. Yes, that's my impression as well. Although the Ada approach makes it much easier to write general purpose exception handlers (which only log unexpected exceptions), some things are quite difficult to handle. For example, look at the POSIX.5 binding. There's a single POSIX_Error exception and a task-specific variable to tell one kind of error from the other. The other possibility would have been to use one exception per error, but this would make exception handlers very elaborated (they would have to handle quite a lot of them). I wish I could create a hierarchy of exceptions in Ada (so that, for example, handling POSIX_Error catches Broken_Pipe_Error, too)... ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-17 0:00 ` Robert A Duff ` (2 preceding siblings ...) 2000-03-20 0:00 ` Florian Weimer @ 2000-03-22 0:00 ` Mats Weber 2000-03-27 0:00 ` Robert A Duff 3 siblings, 1 reply; 54+ messages in thread From: Mats Weber @ 2000-03-22 0:00 UTC (permalink / raw) Robert A Duff wrote: > > Richard D Riehle <laoXhai@ix.netcom.com> writes: > > > In some languages, exceptions are first class objects. Ada exceptions are > > not first class objects for very good reasons. > ^^^^^^^^^^^^^^^^^ > > I beg to differ. I think this is one of the few cases where those other > languages got it right, and Ada got it wrong. I think the designers of Modula-3 got it just right. You can have a look at http://www.m3.org/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-22 0:00 ` Mats Weber @ 2000-03-27 0:00 ` Robert A Duff 2000-03-27 0:00 ` Hyman Rosen ` (5 more replies) 0 siblings, 6 replies; 54+ messages in thread From: Robert A Duff @ 2000-03-27 0:00 UTC (permalink / raw) Mats Weber <matsw@mail.com> writes: > Robert A Duff wrote: > > > > Richard D Riehle <laoXhai@ix.netcom.com> writes: > > > > > In some languages, exceptions are first class objects. Ada exceptions are > > > not first class objects for very good reasons. > > ^^^^^^^^^^^^^^^^^ > > > > I beg to differ. I think this is one of the few cases where those other > > languages got it right, and Ada got it wrong. > > I think the designers of Modula-3 got it just right. You can have a look > at http://www.m3.org/ I beg to differ, again. ;-) I see several problems with Modula-3's exception mechanism, some of which are shared by Ada. (My knowledge of the language comes from Harbison's book, "Modula-3". I've never written a Modula-3 program.) There's no hierarchy of exceptions. This means that the designer of some code that raises exceptions must decide on the granularity of exception handling; it would be better for the handler to make that decision. For example, one handler might want to handle all "I/O errors", whereas another handler might want to handle just "disk-full error". Making exceptions first-class objects (which they are not, in Ada and Modula-3) would solve this problem, at no cost in language complexity. An exception takes just one parameter. Why not two or three or however many I like? Again, making exceptions extensible object types would solve the problem. The behavior in the presense of "checked run-time errors" (things like divide by zero, arithmetic overflow, array index out of bounds) is not defined by the language. So an array index out of bounds might raise Array_Index_Error on one implementation, and Constraint_Error on another implementation, and simply stop the program dead in its tracks on a third implementation. I don't like that non-portability. (On the other hand, Ada *pretends* that it's OK to raise and handle Constraint_Error, but if you read RM-11.6, you'll find that's not quite true -- and I doubt if any Ada programmer other than Tucker Taft actually *understands* 11.6. So in practise, 11.6 says, "Do not handle predefined exceptions.") The "raises set" of a procedure defines what exceptions it can raise. The problem is that this rule is checked at run time. Java is closer to the right solution -- it checks that rule at compile time. However, Java suffers from the "cry wolf" problem. I think it's possible to avoid the "cry wolf" problem, and still do most of that checking at compile time. The parameter of an exception occurrence (in Ada terms) is a variable. Why not a constant? There is no re-raise statement (spelled "raise;" in Ada), so a "when others" handler (Ada spelling again) can't propagate the same exception. You can't raise the same exception occurrence, because the thing available in the handler is not the occurrence, but just its parameter, and then only if you named a particular exception. Return and exit statements are defined in terms of raising a RETURN or EXIT exception. That seems kludgy to me, because exceptions are for cases where the target of the jump is determined dynamically, whereas return and exit are jumping to a statically-known place. So it's sort of overkill. In practical terms, it means that a "when others" will handle a RETURN or EXIT, and you can't re-raise it, so the return doesn't actually return, and the exit doesn't actually exit the loop. All exceptions must be declared at top level. This solves the kludginess of Ada, where they can be declared anywhere, but act *as if* they were declared at top level. But I think there are better solutions to that problem, based on the "procedure declares what exceptions it can raise" idea of Modula-3, Java, etc. There's nothing like Eiffel's preconditions, postconditions, and invariants, which tie exceptions to the conditions that cause them. In Modula-3, you can say "this thing might raise Stack_Full", whereas in Eiffel you can say, "this thing will raise Stack_Full if Full(S) is True." So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all have better ideas about exceptions than Modula-3 (or Ada). - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff @ 2000-03-27 0:00 ` Hyman Rosen 2000-03-28 0:00 ` reason67 ` (4 subsequent siblings) 5 siblings, 0 replies; 54+ messages in thread From: Hyman Rosen @ 2000-03-27 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > The "raises set" of a procedure defines what exceptions it can raise. > The problem is that this rule is checked at run time. Java is closer to > the right solution -- it checks that rule at compile time. However, > Java suffers from the "cry wolf" problem. I think it's possible to > avoid the "cry wolf" problem, and still do most of that checking at > compile time. Most people on comp.lang.c++.moderated have concluded that C++ throw specifications are useless, except for the throw() spec which says that a function will throw no exceptions at all. It would be interesting to see a design which works well. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff 2000-03-27 0:00 ` Hyman Rosen @ 2000-03-28 0:00 ` reason67 2000-03-28 0:00 ` Robert Dewar 2000-03-28 0:00 ` Robert Dewar ` (3 subsequent siblings) 5 siblings, 1 reply; 54+ messages in thread From: reason67 @ 2000-03-28 0:00 UTC (permalink / raw) In article <wccya74m18e.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > (On the other hand, Ada *pretends* that it's OK to raise and handle > Constraint_Error, but if you read RM-11.6, you'll find that's not quite > true -- and I doubt if any Ada programmer other than Tucker Taft > actually *understands* 11.6. So in practise, 11.6 says, "Do not handle > predefined exceptions.") "Ladies and Gentlemen, Thank you for flying on the Boeing 777 Flight 633. Unfortunately, due to a minor bug in the flight control software raising a predefined exception and Ada RM section 11.6, the flight control software has crashed. We are now heading towards the ground at 700 miles per hour. Estimated time of arrival 10 seconds. Have a nice day." --- Jeffrey S. Blatt "If the truth will kill them, let them die." -- Immanuel Kant Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-28 0:00 ` reason67 @ 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw) In article <8bqcu2$s0p$1@nnrp1.deja.com>, reason67@my-deja.com wrote: > In article <wccya74m18e.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > > (On the other hand, Ada *pretends* that it's OK to raise and handle > > Constraint_Error, but if you read RM-11.6, you'll find that's not > quite > > true -- and I doubt if any Ada programmer other than Tucker Taft > > actually *understands* 11.6. So in practise, 11.6 says, "Do not handle > > predefined exceptions.") > > "Ladies and Gentlemen, Thank you for flying on the Boeing 777 Flight > 633. Unfortunately, due to a minor bug in the flight control software > raising a predefined exception and Ada RM section 11.6, the flight > control software has crashed. We are now heading towards the ground at > 700 miles per hour. Estimated time of arrival 10 seconds. Have a nice > day." Well there was no smiley there, so let's assume the (rather hard to believe) point is being made seriously. In that case it is way way off base. Any safety critical software is validated and verified at the object level. You never depend on the correctness of the compiler, or the correctness of understanding of the high level language semantics. Furthermore, in most safety critical software, one would never have such a handler? Why not because it might typically be the case that the handler code is deactivated, and deactivated code is not permitted in many SC protocols. Finally, 11.6 is about optimization, it is almost always the case that you want *no* optimization for SC code. Why? Because you want the best possible correspondence between source code and object code. So in short, the scenario above is triply unlikely! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-28 0:00 ` Robert Dewar @ 2000-03-29 0:00 ` Simon Wright 2000-03-29 0:00 ` reason67 2000-04-06 0:00 ` Simon Pilgrim 2 siblings, 0 replies; 54+ messages in thread From: Simon Wright @ 2000-03-29 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In that case it is way way off base. Any safety critical > software is validated and verified at the object level. You > never depend on the correctness of the compiler, or the > correctness of understanding of the high level language > semantics. That may well be true of SIL4 software, but I believe not normally so for SIL(n<4). In any case it all depends on the safety case and the independent safety authority .. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Simon Wright @ 2000-03-29 0:00 ` reason67 2000-04-06 0:00 ` Simon Pilgrim 2 siblings, 0 replies; 54+ messages in thread From: reason67 @ 2000-03-29 0:00 UTC (permalink / raw) In article <8brgcd$5kp$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > Well there was no smiley there, so let's assume the (rather > hard to believe) point is being made seriously. > > In that case it is way way off base. Any safety critical > software is validated and verified at the object level. You > never depend on the correctness of the compiler, or the > correctness of understanding of the high level language > semantics. Not the point I was making and also not always the case. I have seen safty critical systems that wrote their SRS's such that they did not have to do V&V on the Object level. And they did not. I agree that they should, but should and do are not always the same. > Furthermore, in most safety critical software, one would never > have such a handler? Why not because it might typically be the > case that the handler code is deactivated, and deactivated code > is not permitted in many SC protocols. Since I have worked in Safty Critical software for 11 years with several Aerospace Companies (I am a contract engineer), I can safely say that while you may have reason to think that what you are saying is true, in reality, it is not the way the code is delivered. In fact, one aircraft that I worked on required that all exceptions be caught at the lowest levels and propagated out of subprograms as status. I expect you can quote more reasons why this is an incorrect way to do Safty Critical software. I can state that your discription is inaccurate for code I have seen and the code I have written for several aircraft (military and otherwise). Now where I have seen the kind of thing you are talking about is when doing hard real-time embedded stuff (Greater that 256 MHz cycle time with limited memory with no OS, but where I did that was in a simulator which is definitely not safty critical). > Finally, 11.6 is about optimization, it is almost always the > case that you want *no* optimization for SC code. Why? Because > you want the best possible correspondence between source code > and object code. That I agree with. The same is true with hard real-time (which on first glace seems backwards). --- Jeffrey S. Blatt Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Simon Wright 2000-03-29 0:00 ` reason67 @ 2000-04-06 0:00 ` Simon Pilgrim 2000-04-07 0:00 ` Robert Dewar 2 siblings, 1 reply; 54+ messages in thread From: Simon Pilgrim @ 2000-04-06 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <8bqcu2$s0p$1@nnrp1.deja.com>, > reason67@my-deja.com wrote: > > "Ladies and Gentlemen, Thank you for flying on the Boeing 777 > Flight > > 633. Unfortunately, due to a minor bug in the flight control > software > > raising a predefined exception and Ada RM section 11.6, the > flight > > control software has crashed. We are now heading towards the > ground at > > 700 miles per hour. Estimated time of arrival 10 seconds. Have > a nice > > day." As one of the many engineers who have worked on the Boeing 777 Primary Flight Computer, I'd like to respond to that. > Well there was no smiley there, so let's assume the (rather > hard to believe) point is being made seriously. > > In that case it is way way off base. Any safety critical > software is validated and verified at the object level. You > never depend on the correctness of the compiler, or the > correctness of understanding of the high level language > semantics. Correct. The PFC code was module tested at object level. > Furthermore, in most safety critical software, one would never > have such a handler? Why not because it might typically be the > case that the handler code is deactivated, and deactivated code > is not permitted in many SC protocols. Right again. > Finally, 11.6 is about optimization, it is almost always the > case that you want *no* optimization for SC code. Why? Because > you want the best possible correspondence between source code > and object code. Not true for the PFC. We have a lot of code to squeeze into that frame. > So in short, the scenario above is triply unlikely! More than that. We have a triple redundant system, with three PFCs per airplane. Within each PFC are three lanes each with a different type of processor. The same source code is compiled to the three different targets with three different compilers. -- Regards, Simon Pilgrim Senior Systems Engineer Avionic Systems Division BAE SYSTEMS, Rochester, UK Views expressed above are not necessarily shared by my employer. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-04-06 0:00 ` Simon Pilgrim @ 2000-04-07 0:00 ` Robert Dewar 2000-04-10 0:00 ` r_c_chapman 0 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 2000-04-07 0:00 UTC (permalink / raw) In article <38ECEB56.8FD7596E@gecm.com>, Simon Pilgrim <simon.pilgrim@gecm.com> wrote: > > Finally, 11.6 is about optimization, it is almost always the > > case that you want *no* optimization for SC code. Why? > > Because > > you want the best possible correspondence between source > > code and object code. > > Not true for the PFC. We have a lot of code to squeeze into > that frame. Well "no optimization" is a relative term here, none of the compilers you used had particularly strong optimizers by modern standards. Certainly none of them took full advantage of 11.6, which was the specific point of this discussion. Actually when the safety-critical crowd asks for no optimization, they are making the usual mistake of specifying a solution to their problem, rather than stating the problem. The problem is to make the examination of the object code as easy as possible. Certain types of optimization assist in this goal. For example, with gnat, we usually find that -O1 assembly code is far easier to follow than -O0 code, simply because there is so much less of it. On the other hand, if you have really fierce optimization, involving high level algorithm substitution, propagation of information all around the place, including erroneous situations, massive restructuring of code, etc, then the resulting object code can become quite complex to read. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-04-07 0:00 ` Robert Dewar @ 2000-04-10 0:00 ` r_c_chapman 0 siblings, 0 replies; 54+ messages in thread From: r_c_chapman @ 2000-04-10 0:00 UTC (permalink / raw) > Certain types of optimization assist in this goal. For example, > with gnat, we usually find that -O1 assembly code is far easier > to follow than -O0 code, simply because there is so much less > of it. I concur - results from our paper in Ada Europe 99 confirm this. Brief summary: On the original SHOLIS project, we had SPARK83 targetting 68040, and we found the optimizer made very little difference to run-time and/or object-code understandability, but the Alsys compiler has hand-written code selection which makes the "unoptimized" code quite reasonable in those terms. I ported SHOLIS to SPARK95, and used GNAT/68k to recompile. At -O0, GNAT produces more code than Alsys, and it's actually harder to understand, since there are so many redundant loads and stored littered about the place. At -O1, the GNAT code is far smaller and easier reading. This is no surprise, since GCC's code selection is table-driven. Interestingly, we did not do full-scale object-code verification (OCV) on SHOLIS, owing to the long track-record and stability of the Alsys compiler. (well..and the simplicity of SPARK...) On more recent targets (e.g. PowerPC), it's really important to have _some_ optimizations on (particularly decent register allocation) since the difference between a register, a cache hit, and a main-memory access is so much more pronounced on these targets. We tried running code from VADSCross/PowerPC with -O0 on another project - the results were disappointing, so we reverted to the _default_ level of -O4 for that compiler, which proved fine (this was also a SIL4 project.) High-level optimization that perform large-scale reorganisation of code are definitely a no-no, but I can live with local improvements. Overall, I recommend you simply avoid having to do full-on OCV - it's very hard work! - Rod Chapman Praxis Critical Systems rod@praxis-cs.co.uk Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff 2000-03-27 0:00 ` Hyman Rosen 2000-03-28 0:00 ` reason67 @ 2000-03-28 0:00 ` Robert Dewar 2000-03-30 0:00 ` Mats Weber 2000-03-29 0:00 ` Richard D Riehle ` (2 subsequent siblings) 5 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw) In article <wccya74m18e.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > There's no hierarchy of exceptions. I dislike complexification of exception handling. Many Ada programmers greatly overuse exceptions, and in particular define far too many separate exceptions. When it comes to exception handling, the rule should be keep it very simple. > (On the other hand, Ada *pretends* that it's OK to raise and > handle Constraint_Error, but if you read RM-11.6, you'll find > that's not quite true -- and I doubt if any Ada programmer > other than Tucker Taft actually *understands* 11.6. So in > practise, 11.6 says, "Do not handle predefined exceptions.") Now now, that's completely disconnected from the real world :-) "In practice", 11.6 says nothing of the sort at all. It is often useful to be able to handle constraint error. For example here is the implementation of one of the plus operators in Calendar in GNAT: function "+" (Left : Time; Right : Duration) return Time is pragma Unsuppress (Overflow_Check); begin return (Left + Time (Right)); exception when Constraint_Error => raise Time_Error; end "+"; If you don't understand 11.6, at least don't make claims about it that are excessive :-) Sure, the formulation of 11.6 is complex, but you have to approach this with a pragmatist's hat on, not a theoretician's viewpoint. In practice many many Ada 95 programs have CE handlers and are in practice perfectly portable. Even if in some cases a theoretician could prove that it was possible to have an implementation of Ada 95 that conformed to the RM under which the handler is "wrong", that is irrelevant if no such implementations exist or are likely to exist. In other cases, even the theoretician's will not find any fault with the CE handler :-) Yes, Bob, I know you like to have the hope that the Ada RM is a formal definition which precisely defines what you can and cannot do. It is nowhere near that for many reasons, and a pragmatic viewpoint always has to be in effect. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-28 0:00 ` Robert Dewar @ 2000-03-30 0:00 ` Mats Weber 2000-04-06 0:00 ` Exceptions (was: " Wes Groleau 0 siblings, 1 reply; 54+ messages in thread From: Mats Weber @ 2000-03-30 0:00 UTC (permalink / raw) Robert Dewar wrote: > I dislike complexification of exception handling. Many Ada > programmers greatly overuse exceptions, and in particular > define far too many separate exceptions. When it comes to > exception handling, the rule should be keep it very simple. Maybe the ability to pass a paramter when raising an exception would make programmers define less exceptions ? ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Exceptions (was: Help Me Please :) 2000-03-30 0:00 ` Mats Weber @ 2000-04-06 0:00 ` Wes Groleau 2000-04-07 0:00 ` Mats Weber 0 siblings, 1 reply; 54+ messages in thread From: Wes Groleau @ 2000-04-06 0:00 UTC (permalink / raw) Maybe the ability to pass a parameter when raising an exception would make programmers define less exceptions ? You mean you wish it were possible to do something like: Ada.Exceptions.Raise_Exception (E => Constraint_Error'Identity, Message => "Array Index Out Of Bounds" ); ?? -- Wes Groleau http://freepages.genealogy.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Exceptions (was: Help Me Please :) 2000-04-06 0:00 ` Exceptions (was: " Wes Groleau @ 2000-04-07 0:00 ` Mats Weber 0 siblings, 0 replies; 54+ messages in thread From: Mats Weber @ 2000-04-07 0:00 UTC (permalink / raw) Wes Groleau wrote: > You mean you wish it were possible to do something like: > > Ada.Exceptions.Raise_Exception > (E => Constraint_Error'Identity, > Message => "Array Index Out Of Bounds" ); No. I would like something like this: http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC99 I do not want a single string parameter, but parameters of types I choose, and I want the mechanism to be strongly typed. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff ` (2 preceding siblings ...) 2000-03-28 0:00 ` Robert Dewar @ 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar ` (2 more replies) 2000-03-30 0:00 ` Tucker Taft 2000-03-30 0:00 ` Mats Weber 5 siblings, 3 replies; 54+ messages in thread From: Richard D Riehle @ 2000-03-29 0:00 UTC (permalink / raw) In article <wccya74m18e.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >Mats Weber <matsw@mail.com> writes: > >> I think the designers of Modula-3 got it just right. You can have a look >> at http://www.m3.org/ > >I beg to differ, again. ;-) > >I see several problems with Modula-3's exception mechanism, some of >which are shared by Ada. (My knowledge of the language comes from >Harbison's book, "Modula-3". I've never written a Modula-3 program.) I agree with you about the Modula-3 problems. Do not entirely agree with you about Ada. There could be some benefits to the paramterized exception, but these would be small and are already adequately covered by the features of Ada.Exceptions. Dr. Dewar and I do not usually agree on the benefits of the functions in Ada.Exceptions, but we do agree that exceptions are overused in most applications. >There's no hierarchy of exceptions. This means that the designer of >some code that raises exceptions must decide on the granularity of >exception handling; it would be better for the handler to make that >decision. For example, one handler might want to handle all "I/O >errors", whereas another handler might want to handle just "disk-full >error". Making exceptions first-class objects (which they are not, in >Ada and Modula-3) would solve this problem, at no cost in language >complexity. There would certainly be an increase in complexity in the creation of hierarchical exceptions. >An exception takes just one parameter. Why not two or three or however >many I like? Again, making exceptions extensible object types would >solve the problem. And what would be the parameter type(s)? Are you suggesting an exception defined with parameters in the same way one defines subprograms? That would seem to increase complexity of both the compiler design and the resulting applications. It is an increase in complexity that seems unnecessary under any but the most unusual circumstances. >The behavior in the presense of "checked run-time errors" (things like >divide by zero, arithmetic overflow, array index out of bounds) is not >defined by the language. So an array index out of bounds might raise >Array_Index_Error on one implementation, and Constraint_Error on another >implementation, and simply stop the program dead in its tracks on a >third implementation. I don't like that non-portability. I agree it is useful to track such things. That is why I like the addition of Exception_Occurrence to the language in Ada.Exceptions. when Some_Nasty_Error : Constraint_Error => Error_Manager.Log(Ada.Exceptions. Exception_Information(Some_Nasty_Error)); This is where Dr. Dewar and I differ. I see this feature as important for applications such as command and control systems. He sees it, as of our last discussion of the subject, as less important than I. >(On the other hand, Ada *pretends* that it's OK to raise and handle >Constraint_Error, but if you read RM-11.6, you'll find that's not quite >true -- and I doubt if any Ada programmer other than Tucker Taft >actually *understands* 11.6. So in practise, 11.6 says, "Do not handle >predefined exceptions.") ALRM 11.6 rarely presents a problem to the applications programmer. It behaves according to a set of rules that has no deleterious effect on the underlying application. It is, as I read it, as set of permissions, not a license to destroy source code intent. >The "raises set" of a procedure defines what exceptions it can raise. >The problem is that this rule is checked at run time. Java is closer to >the right solution -- it checks that rule at compile time. However, >Java suffers from the "cry wolf" problem. I think it's possible to >avoid the "cry wolf" problem, and still do most of that checking at >compile time. The entire C-family of languages, especially C++, is somewhat problematic when examining exception handling. This is another of the "devil is in the details" issues. I don't think Java exception handling measures up in those circumstances that Ada does well. Ada is simpler to understand and probably a little more efficient. Also, Java exception handling seems to lead people to depend too much on exception handling when they ought to be writing programs to check conditions instead. Ada 95 has added the 'Valid attribute for such checking and it can be used nicely in circumstances where one might otherwise raise an exception. I am reminded of C.A.R. Hoare's Turing Award Lecture in which he criticized Ada for having exception as part of the language. Now every language has some kind of exception handling. Ada looks downright conservative when compared to more recent offerings for exception management. >There is no re-raise statement (spelled "raise;" in Ada), so a "when >others" handler (Ada spelling again) can't propagate the same exception. >You can't raise the same exception occurrence, because the thing >available in the handler is not the occurrence, but just its parameter, >and then only if you named a particular exception. A Reraise_Occurrence is included in Ada.Exceptions. It is not very difficult to invoke this routine when one declares a limited type of Exception_Occurrence and attaches it to some Exception_ID. In fact, one may save an Exception_Occurrence and raise it again at some other point in the program. >Return and exit statements are defined in terms of raising a RETURN or >EXIT exception. That seems kludgy to me, because exceptions are for >cases where the target of the jump is determined dynamically, whereas >return and exit are jumping to a statically-known place. So it's sort >of overkill. In practical terms, it means that a "when others" will >handle a RETURN or EXIT, and you can't re-raise it, so the return >doesn't actually return, and the exit doesn't actually exit the loop. As mentioned above, it is possible to save and Exception_Occurrence and ReRaise it. As to return types, it is also useful to use a 'Base value for certain return types and check those on return. Of course, you know this feature better than I. You also understand the excellent arguments against doing it this way. >All exceptions must be declared at top level. This solves the >kludginess of Ada, where they can be declared anywhere, but act *as if* >they were declared at top level. But I think there are better solutions >to that problem, based on the "procedure declares what exceptions it can >raise" idea of Modula-3, Java, etc. Agree that exceptions should be declared at a very high ("top") level. This is done quite nicely using child library units where the top level of a hierarchy is the declaration of the exceptions one will use throughout that hierarchy. In this case, they are also in scope for any clients. >There's nothing like Eiffel's preconditions, postconditions, and >invariants, which tie exceptions to the conditions that cause them. In >Modula-3, you can say "this thing might raise Stack_Full", whereas in >Eiffel you can say, "this thing will raise Stack_Full if Full(S) is >True." No argument with your ideas about Eiffel. I would like to have some model for pre-, post-, and invariants in the next version of Ada. At that time, it would be appropriate to revisit some of the capabilities of exception handling. That being said, as you know, most safety-critical software will avoid exceptions entirely. Another reason why the new 'Valid attribute is becoming useful. >So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all >have better ideas about exceptions than Modula-3 (or Ada). Agree about Eiffel. Not sure about CLOS or Clu. Definitely disagree about C++. The exception handling in C++ can only be described as scary. Richard Riehle ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-29 0:00 ` Richard D Riehle @ 2000-03-29 0:00 ` Robert Dewar 2000-03-31 0:00 ` Richard D Riehle 2000-03-30 0:00 ` Mats Weber 2000-04-06 0:00 ` Wes Groleau 2 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 2000-03-29 0:00 UTC (permalink / raw) In article <8brm79$jm3$1@slb6.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > I agree it is useful to track such things. That is why I like > the addition of Exception_Occurrence to the language in > Ada.Exceptions. > > when Some_Nasty_Error : Constraint_Error => > Error_Manager.Log(Ada.Exceptions. > Exception_Information(Some_Nasty_Error)); > > This is where Dr. Dewar and I differ. I see this feature as > important for applications such as command and control > systems. He sees it, as of our last discussion of the > subject, as less important than I. Well I am not quite sure what the disagreement is, but let me make a couple of comments on the above code. It is highly implementation dependent, on some implementations it may give a useful symbolic traceback, on another, no output at all, and on a third, may generate a complete core dump. The output is "implementation defined", which means you know absolutely nothing about what the above code does from a portable point of view. On a given compiler it may do something useful to you, but you have to examine any such logging code wrt the implementation you are using, and adjust the code accordingly. But in practice most Ada 83 implementations provided facilities like this in any case (actually many Ada 83 implementations provided much more extensive capabilities, and the Ada 95 facilities are not sufficient, we have had to add quite a bit to GNAT here, see for example, GNAT.Exceptions. Also, you hope that compilers have extended capabilities like dumping the results of an exception EVEN if there are dependent tasks that prevent propagation. Or dump exceptions that otherwise terminate tasks silently. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-29 0:00 ` Robert Dewar @ 2000-03-31 0:00 ` Richard D Riehle 2000-03-31 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 54+ messages in thread From: Richard D Riehle @ 2000-03-31 0:00 UTC (permalink / raw) In article <8brs96$ikp$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >In article <8brm79$jm3$1@slb6.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: >> I agree it is useful to track such things. That is why I like >> the addition of Exception_Occurrence to the language in >> Ada.Exceptions. >> >> when Some_Nasty_Error : Constraint_Error => >> Error_Manager.Log(Ada.Exceptions. >> Exception_Information(Some_Nasty_Error)); >> >> This is where Dr. Dewar and I differ. I see this feature as >> important for applications such as command and control >> systems. He sees it, as of our last discussion of the >> subject, as less important than I. > >Well I am not quite sure what the disagreement is, but let >me make a couple of comments on the above code. You and I have had a discussion about this and we see its value for applications a little differently, as reflected in your note, below. >It is highly implementation dependent, on some implementations >it may give a useful symbolic traceback, on another, no output >at all, and on a third, may generate a complete core dump. The >output is "implementation defined", which means you know >absolutely nothing about what the above code does from a >portable point of view. It is certainly implementation dependent. It is also not very useful for for what Joyce Tokar calls, "deeply embedded" software since we do not want to be passing strings all over the place. That being said, if Exceptions.Exception_Information does return useful information for a given compiler when used in something such as a command and control application, this could be a nice feature of the implementation. >On a given compiler it may do something useful to you, but you >have to examine any such logging code wrt the implementation >you are using, and adjust the code accordingly. But in practice >most Ada 83 implementations provided facilities like this in >any case (actually many Ada 83 implementations provided much >more extensive capabilities, and the Ada 95 facilities are not >sufficient, we have had to add quite a bit to GNAT here, see >for example, GNAT.Exceptions. Certainly one has the issue of implementation dependency. However, I am not sure I like the idea of parameterizing the exception itself. I do like the Ada 95 addition of, optionally, adding an exception occurrence for certain exceptions. Also, we can provide a parameter in the form of a message for given exceptions. That allows us to call the Exception_Message function where this is deemed useful. That feature is not implementation dependent since we raise the exception with a clear message. A when others becomes problematic. That is one place where the exception occurrence becomes important. Of course we can either Raise a new exception at the place of a _when others_ or label it with an exception occurrence. In either case, we have preserved the efficiency of the exception model while allowing some kind of parameter or access to other useful information. >Also, you hope that compilers have extended capabilities like >dumping the results of an exception EVEN if there are dependent >tasks that prevent propagation. Or dump exceptions that >otherwise terminate tasks silently. Well, yes, that would be nice. On the other hand, if we can target our exception messages with message parameters, these can be quite useful as part of the overall design. Also, the string message could be designed to permit conversion to some other data type using the features of Ada.Text_IO. This is up to the designer, but it does imply a fairly high level of flexibility when one really needs this sort of thing. In this case, there is no dependency on the underlying implementation. We get the general capability of the parameterized exception when we need it. I think the Ada.Exceptions package is greatly underrated by a lot of people. As mentioned above, it is not appropriate for every kind of system, but is quite useful when one applies some creativity to its usages. Richard Riehle ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-31 0:00 ` Richard D Riehle @ 2000-03-31 0:00 ` Jean-Pierre Rosen 2000-03-31 0:00 ` Pascal Obry 0 siblings, 1 reply; 54+ messages in thread From: Jean-Pierre Rosen @ 2000-03-31 0:00 UTC (permalink / raw) [long discussions about the value of parameterized exceptions snipped] My 2 Euro-cents: Exceptions are a programming tool, not a high level error-handling mechanism. In any project, you must define a policy for handling errors. Exceptions are a powerful tool for unwinding the call stack, and without them, there are many error handling policies that you could not define. They do NOT free you from defining the policy for a project! If you need to store more information when an error occurs, call some Error procedure, and define it the way you like; there you can store the context in a global variable, or if you need to make it tasking safe, in a task attribute. For those who can read french, there is a chapter in my book detailing these issues (shameless plug: http://pro.wanadoo.fr/adalog/livrejpr.htm). -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-31 0:00 ` Jean-Pierre Rosen @ 2000-03-31 0:00 ` Pascal Obry 0 siblings, 0 replies; 54+ messages in thread From: Pascal Obry @ 2000-03-31 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 776 bytes --] Jean-Pierre Rosen a �crit dans le message <8c20ps$995$1@wanadoo.fr>... >[long discussions about the value of parameterized exceptions snipped] > >For those who can read french, there is a chapter in my book detailing these >issues (shameless plug: http://pro.wanadoo.fr/adalog/livrejpr.htm). > I would even add that you should learn french to at least be able to read this book :) It is definitly a very good one! Pascal. --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar @ 2000-03-30 0:00 ` Mats Weber 2000-03-31 0:00 ` Richard D Riehle 2000-04-06 0:00 ` Wes Groleau 2 siblings, 1 reply; 54+ messages in thread From: Mats Weber @ 2000-03-30 0:00 UTC (permalink / raw) Richard D Riehle wrote: > And what would be the parameter type(s)? Are you suggesting an > exception defined with parameters in the same way one defines > subprograms? That would seem to increase complexity of both the > compiler design and the resulting applications. It is an increase > in complexity that seems unnecessary under any but the most unusual > circumstances. I think the increase in complexity is already present in Ada.Exceptions. Implementations have to reserve space for and pass that string around, so I don't see why one could not pass other types. I made a proposal for this in my thesis, you can have a look at it at: http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC99 it's really not that complicated. Without this mechanism, it is quite hard to interface systems like POSIX in a clean way, where there is a single exception + an error code. With parameterized exceptions, it is very easy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-30 0:00 ` Mats Weber @ 2000-03-31 0:00 ` Richard D Riehle 0 siblings, 0 replies; 54+ messages in thread From: Richard D Riehle @ 2000-03-31 0:00 UTC (permalink / raw) In article <38E389D7.5CD82114@mail.com>, Mats Weber <matsw@mail.com> wrote: >I think the increase in complexity is already present in Ada.Exceptions. >Implementations have to reserve space for and pass that string around, >so I don't see why one could not pass other types. As I mentioned in my earlier reply to Robert Dewar, one can Raise and exception with the procedure in Ada.Exceptions where the string variable is nothing more than some numeric value(s) in string format. Strings are rather portable across many different platforms. These can be decomposed into their constituent numeric values and used for communicating with various operating systems. >Without this mechanism, it is quite hard to interface systems like POSIX >in a clean way, where there is a single exception + an error code. With >parameterized exceptions, it is very easy. As mentioned above, the Ada.Exceptions.Raise_Exception procedure allows us to link an exception identity to a message in the form of a string and Ada.Text_IO allows us to convert that string into an integer value for those exceptions where that might be appropriate. This is not implementation dependent and provides the very capability we are discussing. Richard Riehle ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Mats Weber @ 2000-04-06 0:00 ` Wes Groleau 2 siblings, 0 replies; 54+ messages in thread From: Wes Groleau @ 2000-04-06 0:00 UTC (permalink / raw) > when Some_Nasty_Error : Constraint_Error => > Error_Manager.Log(Ada.Exceptions. > Exception_Information(Some_Nasty_Error)); > > This is where Dr. Dewar and I differ. I see this feature as important > for applications such as command and control systems. He sees it, as > of our last discussion of the subject, as less important than I. I see it as valuable for debugging when you have a million SLOC you didn't write! Unfortunately, some compiler vendors do not see its value and hence take advantage of the laxity of the RM in that area. -- Wes Groleau http://freepages.genealogy.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff ` (3 preceding siblings ...) 2000-03-29 0:00 ` Richard D Riehle @ 2000-03-30 0:00 ` Tucker Taft 2000-03-30 0:00 ` Mats Weber 5 siblings, 0 replies; 54+ messages in thread From: Tucker Taft @ 2000-03-30 0:00 UTC (permalink / raw) Robert A Duff wrote: > ... > (On the other hand, Ada *pretends* that it's OK to raise and handle > Constraint_Error, but if you read RM-11.6, you'll find that's not quite > true -- and I doubt if any Ada programmer other than Tucker Taft > actually *understands* 11.6. So in practise, 11.6 says, "Do not handle > predefined exceptions.") This sounds like a request for a quick tutorial on 11.6 ;-). Here is my nickel tour: RM95 11.6(5) says, effectively, that you can remove dead code, even if it might raise an exception due to failing a language-defined check. RM95 11.6(6) says that the compiler (or hardware) can do instruction scheduling (i.e. reordering) even if there are language-defined checks among the instructions, meaning that if you handle an exception raised by the failure of a language-defined check, it might be "imprecise." However, it won't be so imprecise as to disrupt some separately compiled "abstraction" in the middle of an operation, presuming the check failed outside of the abstraction. Or for the one-cent summary: dead code removal and instruction reordering can be performed without worrying too much about language-defined checks, so long as you don't use any "undefined" results (i.e., the result of an operation that failed a language-defined check) and you don't screw up external abstractions. > ... > - Bob -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-27 0:00 ` Robert A Duff ` (4 preceding siblings ...) 2000-03-30 0:00 ` Tucker Taft @ 2000-03-30 0:00 ` Mats Weber 5 siblings, 0 replies; 54+ messages in thread From: Mats Weber @ 2000-03-30 0:00 UTC (permalink / raw) Robert A Duff wrote: > > Mats Weber <matsw@mail.com> writes: > > I think the designers of Modula-3 got it just right. > I beg to differ, again. ;-) I agree with you on most points. What I meant is that the idea of being able to pass a parameter (even if only one) when raising an exception is much better than Ada's current approach where the only thing you can pass is a string. This would have been a very simple change to the language (almost as simple as including a string parameter in an exception occurence), and the mechanism can be used to simulate a hierarchy of exceptions, using a single exception with a tagged type as a paramter. ^ permalink raw reply [flat|nested] 54+ messages in thread
[parent not found: <2000Mar3.183321.69279@ludens>]
* Re: Help Me Please :) [not found] ` <2000Mar3.183321.69279@ludens> @ 2000-03-03 0:00 ` Larry Kilgallen 2000-03-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 54+ messages in thread From: Larry Kilgallen @ 2000-03-03 0:00 UTC (permalink / raw) In article <2000Mar3.183321.69279@ludens>, gazso@ludens.elte.hu (Erdelyi Gaspar) writes: > I think that GNAT is not comparable to DEC Ada (for OpenVMS) which provides > very useful error messages. DEC Ada is Ada83 only and the prices are not > comoparable, too... > > Gaspar Erdelyi > university student DEC Ada is Ada83 only, but for a university student the VMS Hobbyist License gives you DEC Ada for free (restricting it to personal use that is not commercial). Thus in your situation I would say prices are quite comparable. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) [not found] ` <2000Mar3.183321.69279@ludens> 2000-03-03 0:00 ` Larry Kilgallen @ 2000-03-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 54+ messages in thread From: Robert Dewar @ 2000-03-04 0:00 UTC (permalink / raw) In article <2000Mar3.183321.69279@ludens>, gazso@ludens.elte.hu (Erdelyi Gaspar) wrote: > I think that GNAT is not comparable to DEC Ada (for OpenVMS) > which provides very useful error messages. DEC Ada is Ada83 > only and the prices are not comoparable, too... Well the prices are not that far from comparable, but that's another issue anyway. With regard to error messages there are four cases of interest: 1. Cases where DEC Ada 83 simply gets confused, and GNAT does not. There are quite a few of these, one notable example is the GNAT circuit for dealing with the semicolon/IS confusion. All other compilers I know can get confused by this, including DEC Ada 83. 2. Cases where GNAT gets confused, and DEC Ada 83 does not. I don't currently know of any such cases, but that does not mean they do not exist. If you know of such cases, it is always useful to submit them to report@gnat.com, we are always working to tune the error message circuit (indeed giving good messages is a hobby of mine :-) 3. Cases where neither compiler gets confused and the error messages are comparable. Having worked through the entire DEC test suite, which contains thousands of examples of error situations, I would say this is probably the most common case. 4. Cases where neither compiler gets confused and the error messages are substantially different. These are interesting cases to look at. Sometimes there is simply a difference in style. GNAT aims at trying to keep error messages short and informative, whereas DEC Ada 83 often gives rather voluminous messages. In GNAT, you can more nearly approximate this verbose mode by using the -gnatf switch. But there will still be differences, some of these might just be a matter of taste, some may be cases where real improvements are possible (there are certainly cases in the DEC test suite where the GNAT message is more useful, I don't know of any cases left where I consider the DEC Ada 83 message significantly better in this test suite, because we used the suite to tune up such cases in GNAT :-) Here again, in case 4, it is very useful if you send in cases where you think an error message can be improved. This actually is a much more general request than just comparing these two compilers. Any time you get a compile time message that you think could be clearer, send it along. We may well agree, and we may well be able to do something about it. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
[parent not found: <df481109.0106140310.5d923746@posting.google.com>]
[parent not found: <9gb1uu$87u7o$1@ID-52877.news.dfncis.de>]
* Re: help me please! [not found] ` <9gb1uu$87u7o$1@ID-52877.news.dfncis.de> @ 2001-06-19 2:59 ` Ken Garlington 2001-06-16 10:20 ` C.D.Damron 2001-06-20 6:06 ` John Keeney 0 siblings, 2 replies; 54+ messages in thread From: Ken Garlington @ 2001-06-19 2:59 UTC (permalink / raw) [cross-posted to comp.lang.ada] "Emmanuel Gustin" <Emmanuel.Gustin@skynet.be> wrote in message news:9gb1uu$87u7o$1@ID-52877.news.dfncis.de... : "Jamal Bengeloun" <jakb@caramail.com> wrote in message : news:df481109.0106140310.5d923746@posting.google.com... : : > I am doing a graduate end of term research on the use of java in : > avionics systems, on the certification issues regarding those systems : > and finally on the viability of java in avionics (well why not Ada by : > the way? From what I've read here java is regarded as cooler, but is : > it safe?). First, on the current use of Java in avionics: I haven't personally seen any "safety-critical" (Level A, or SIL 4 if you prefer) real-time embedded avionics projects announced to date that use the Java language. I suspect this is due to a combination of issues: the complexity of certifying the system (including the JVM), the potential impact of garbage collection on run-time schedulability analysis, efficiency issues, and availability on certain platforms. However, particularly since not all avionics applications are necessarily safety-critical, this doesn't rule out Java implementations for lower criticality levels. With respect to certification issues, it depends on the certification scheme. Trying to certify a Java implementation against MoD 00-55, for example, would probably be much more difficult than with DO-178, which in turn would be probably more difficult than MIL-STD-882 (although in practice, it also depends a lot on the specific people granting the certification). Part of the problem is defining what is really meant by a "Java" implementation. If you're referring to Java targeted to the JVM, that's going to be significantly more difficult than Java compiled as "native" code. Conversely, using Ada as the source language, but with JVM as the target (such compilers do exist), might also be easier than Java + JVM. Again, it depends upon the certification criteria. For the sake of discussion, let's assume we're taking about a "traditional" Java implementation using a JVM, certified along the lines described in DO-178. I would suspect the only way this could be certified is through the use of some (probably all) of the following approaches: -- The Java/JVM vendor would need to provide sufficient data to certify both the Java toolset and the JVM implementation, including configuration management and verification records. For a Level A implementation, this would be significantly more information than you would normally expect a commercial vendor to generate, although some embedded OS vendors (Aonix, WindRiver, etc.) have such packages. As others have noted, the license agreements normally included with Java products don't encourage me that many Java vendors are working on this, but it's possible. - The avionics developer (or a third party) would have to generate a sufficiently robust verification scheme for both the toolset and JVM to independently show that both components are acceptable when integrated into the total system. AFAIK, RTCA has not yet bought off on the idea of independently certifying individual software components, so such integrated proof would be important. - Some use of product service history (i.e., the lack of defects attributable to the toolset/JVM when used in other applications) could be helpful; however, RTCA's position as I understand it places a number of limitations on how much faith can be placed on past experience. (Some DERs, on the other hand, seem to put a lot of faith in it.) Bottom line? I wouldn't want to be the first guy to go through this process. However, it might be technically feasible. It wouldn't seem to be economically desirable vs. other languages at this time, though. In terms of the general viability/safety of Java (and Ada) vs. C++, a recent column by Peter Coffee may be of some interest: http://www.zdnet.com/eweek/stories/general/0,11011,2769111,00.html I don't know if anyone has generated a specific guide for application of Java to safety-critical systems, as exists for C and Ada. I'd be surprised if one exists. One brief analysis is available at http://www.adaic.com/docs/reports/lawlis/p.htm It appears that the J Consortium's High Integrity Profile Task Group is working on a better analysis; more information is available at http://www.j-consortium.org and http://www.aonix.com/content/news/pr_9.28.99_2.html. There's a presentation on the first site that outlines some of the issues. Moving on to the side-issue of Ada: : Ada is widely regarded as a language designed by a committee, : on a par with FORTRAN-99, and handicapped by an excessive : number of features. I don't know; I never used it. As someone who _has_ actually used Ada in avionics applications (unlike Mr. Gustin, who was honest about his own lack of experience, and Mr. Tarver, who failed to note that he is unqualified to give an educated opinion), I believe this is an extremely inaccurate characterization of Ada. It continues to be used in a number of areas, e.g. for MoD 00-55 SIL 4 applications. There are non-technical factors that adversely affect its use, particularly in the U.S. marketplace. See the National Academy of Sciences study "Ada and Beyond: Software Policies for the Department of Defense," available at http://www.nap.edu/catalog/5463.html for more information on this subject. General information on Ada is available at http://www.acm.org/sigada and other sources. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: help me please! 2001-06-19 2:59 ` help me please! Ken Garlington @ 2001-06-16 10:20 ` C.D.Damron 2001-06-20 6:06 ` John Keeney 1 sibling, 0 replies; 54+ messages in thread From: C.D.Damron @ 2001-06-16 10:20 UTC (permalink / raw) Wow, thanks for such an effort! Ken Garlington wrote in message <3ezX6.311 ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: help me please! 2001-06-19 2:59 ` help me please! Ken Garlington 2001-06-16 10:20 ` C.D.Damron @ 2001-06-20 6:06 ` John Keeney 1 sibling, 0 replies; 54+ messages in thread From: John Keeney @ 2001-06-20 6:06 UTC (permalink / raw) Ken Garlington <Ken.Garlington@computer.org> wrote in message news:3ezX6.311$kV6.181850212@newssvr17.news.prodigy.com... > [cross-posted to comp.lang.ada] > > "Emmanuel Gustin" <Emmanuel.Gustin@skynet.be> wrote in message > : Ada is widely regarded as a language designed by a committee, > : on a par with FORTRAN-99, and handicapped by an excessive > : number of features. I don't know; I never used it. > > As someone who _has_ actually used Ada in avionics applications (unlike Mr. > Gustin, who was honest about his own lack of experience, and Mr. Tarver, who > failed to note that he is unqualified to give an educated opinion), I > believe this is an extremely inaccurate characterization of Ada. It > continues to be used in a number of areas, e.g. for MoD 00-55 SIL 4 > applications. There are non-technical factors that adversely affect its use, > particularly in the U.S. marketplace. See the National Academy of Sciences > study "Ada and Beyond: Software Policies for the Department of Defense," > available at http://www.nap.edu/catalog/5463.html for more information on > this subject. General information on Ada is available at > http://www.acm.org/sigada and other sources. While I've never "used" Ada I did attend a class (while teaching others) where it and C++ were two of the four languages "introduced" during the semester. While I was already an active C programmer I found Ada much more to my liking than C++. Ada was coherent while C++ -in trying to be an advanced C- lost C's wonderfull one man design singularity of style. C++ seems to me to be well on its way to joining the Lots of Insidiously Stupid Parenthesis crowd of computer languages. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Help Me Please :) @ 2000-02-29 0:00 Will Mann 2000-02-29 0:00 ` Stanley R. Allen ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Will Mann @ 2000-02-29 0:00 UTC (permalink / raw) Can some one help me with my Ada.. my lecturer has given me code that doesn't work... the compiler says that it can't handle "A".."Z" the error message is : Inappropriate operands for "DOT_DOT" operation, continuing Thanks -- :\ / | | ALL DONE BYE BYE! : \ /\ / * | | : \/ \/ | |__ |__ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 Help Me Please :) Will Mann @ 2000-02-29 0:00 ` Stanley R. Allen 2000-02-29 0:00 ` Al Johnston 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` James Bean 2 siblings, 1 reply; 54+ messages in thread From: Stanley R. Allen @ 2000-02-29 0:00 UTC (permalink / raw) Will Mann wrote: > > Can some one help me with my Ada.. my lecturer has given me code that > doesn't work... the compiler says that it can't handle "A".."Z" the > error message is : > > Inappropriate operands for "DOT_DOT" operation, continuing What hourly rates do you offer? -- Stanley Allen mailto:Stanley_R_Allen@raytheon.com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 ` Stanley R. Allen @ 2000-02-29 0:00 ` Al Johnston 2000-03-01 0:00 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 54+ messages in thread From: Al Johnston @ 2000-02-29 0:00 UTC (permalink / raw) > What hourly rates do you offer? boy... that was not nice... I am new to this stuff too, and i cant run my compiler and do email at the same time... so i am not sure... but those '"' look funny to me. I beleive double quotes denote ada strings, while single quotes refer to characters so you were asking (i think) ada to use a RANGE of strings from the string A to the string. I think it should be 'A'..'Z' then again, I said I was new to this stuff... I want my c back! ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 ` Al Johnston @ 2000-03-01 0:00 ` Robert Dewar 2000-03-01 0:00 ` tmoran ` (2 subsequent siblings) 3 siblings, 0 replies; 54+ messages in thread From: Robert Dewar @ 2000-03-01 0:00 UTC (permalink / raw) In article <38BC7A6E.EC5DE68B@mindspring.com>, Al Johnston <sofeise@mindspring.com> wrote: > I think it should be > 'A'..'Z' > then again, I said I was new to this stuff... I want my c > back! Well if you are so narrow in your exposure to languages that you know only C, it will be *really* good experience to learn another language. Any competent programmer should be able to acquire the *syntax* of another programming language almost immediately. Ironically, this particular point is one where Ada and C are identical, and if you used "x" instead of 'x' in C you would get equally mysterious (actually probably more mysterious messages, something like: warning: comparison between pointer and integer (at least that's what gcc gives for the equivalent C mistake: if ("a" <= q && q <= "z") ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 ` Al Johnston 2000-03-01 0:00 ` Robert Dewar @ 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` Al Johnston 2000-03-02 0:00 ` Aidan Skinner 2000-03-01 0:00 ` Stanley R. Allen 2000-03-01 0:00 ` Robert Dewar 3 siblings, 2 replies; 54+ messages in thread From: tmoran @ 2000-03-01 0:00 UTC (permalink / raw) In <38BC7A6E.EC5DE68B@mindspring.com> Al Johnston said: >to use a RANGE of strings from the string A to the string. I think it >should be >'A'..'Z' Correct. >then again, I said I was new to this stuff... I want my c back! Would you really prefer a language in which for(i="A";i<"Z";i++)printf("%c",i); is not caught at compile time, but instead gives you exciting debugging opportunities? ;) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-01 0:00 ` tmoran @ 2000-03-01 0:00 ` Al Johnston 2000-03-02 0:00 ` Aidan Skinner 1 sibling, 0 replies; 54+ messages in thread From: Al Johnston @ 2000-03-01 0:00 UTC (permalink / raw) > Would you really prefer a language in which > for(i="A";i<"Z";i++)printf("%c",i); > is not caught at compile time, but instead gives you exciting debugging > opportunities? ;) Hey, its call job security! And yes I would... I am a libertarian... or maybe that should be sadist... I get those confused. (g) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` Al Johnston @ 2000-03-02 0:00 ` Aidan Skinner 1 sibling, 0 replies; 54+ messages in thread From: Aidan Skinner @ 2000-03-02 0:00 UTC (permalink / raw) tmoran@bix.com writes: > Would you really prefer a language in which > for(i="A";i<"Z";i++)printf("%c",i); > is not caught at compile time, but instead gives you exciting debugging > opportunities? ;) #define EVIL 1; #define NOT_EVIL 0; C int; if (C = EVIL) { printf ("C is Evil"); } else { printf ("C isn't Evil"); } - Aidan -- http://www.skinner.demon.co.uk/aidan/ Currently looking for work: CV available on request. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 ` Al Johnston 2000-03-01 0:00 ` Robert Dewar 2000-03-01 0:00 ` tmoran @ 2000-03-01 0:00 ` Stanley R. Allen 2000-03-01 0:00 ` Robert Dewar 3 siblings, 0 replies; 54+ messages in thread From: Stanley R. Allen @ 2000-03-01 0:00 UTC (permalink / raw) Al Johnston wrote: > > > What hourly rates do you offer? > > boy... that was not nice... Can e-mail & newsgroup humor be dry? -- Stanley Allen mailto:Stanley_R_Allen@raytheon.com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 ` Al Johnston ` (2 preceding siblings ...) 2000-03-01 0:00 ` Stanley R. Allen @ 2000-03-01 0:00 ` Robert Dewar 2000-03-01 0:00 ` Al Johnston 3 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 2000-03-01 0:00 UTC (permalink / raw) In article <38BC7A6E.EC5DE68B@mindspring.com>, Al Johnston <sofeise@mindspring.com> wrote: > I think it should be > 'A'..'Z' > then again, I said I was new to this stuff... I want my c > back! Well if you are so narrow in your exposure to languages that you know only C, it will be *really* good experience to learn another language. Any competent programmer should be able to acquire the *syntax* of another programming language almost immediately. Ironically, this particular point is one where Ada and C are identical, and if you used "x" instead of 'x' in C you would get equally mysterious (actually probably more mysterious messages, something like: warning: comparison between pointer and integer (at least that's what gcc gives for the equivalent C mistake: if ("a" <= q && q <= "z") ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-03-01 0:00 ` Robert Dewar @ 2000-03-01 0:00 ` Al Johnston 0 siblings, 0 replies; 54+ messages in thread From: Al Johnston @ 2000-03-01 0:00 UTC (permalink / raw) > Well if you are so narrow in your exposure to languages that > you know only C, it will be *really* good experience to learn Well, there he goes again... (g)... but you did post a very helpful reply to the originator of this thread... so we will think nice thoughts about you for a while... My first language was fortran 4. back in 76. My first love was pascal (I know you will have fun with that one); I have been doing c for the last 5 years, although most of my time has been spent debugging c/ada83 interfaces... You would think I would like ada. I dont. > another language. Any competent programmer should be able to > acquire the *syntax* of another programming language almost Although stated in an unkind way, I have to agree with you. But I guess I am just getting old. I have spent to many hrs in the RM and cohen's book the last two weeks for it to be laziness. > Ironically, this particular point is one where Ada and C are > identical, and if you used "x" instead of 'x' in C you would Very ironic. I did not catch this... at first glance I thought it would work okay... but i didn't pay enough attention... ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 Help Me Please :) Will Mann 2000-02-29 0:00 ` Stanley R. Allen @ 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` James Bean 2 siblings, 0 replies; 54+ messages in thread From: tmoran @ 2000-03-01 0:00 UTC (permalink / raw) > doesn't work... the compiler says that it can't handle "A".."Z" the The doublequote " is for a string, use the singlequote ' for a character. ie 'A' .. 'Z' > my lecturer has given me code that doesn't work Perhaps you should help him - after taking Stanley Allen's advice to ask "What hourly rates do you offer?" ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Help Me Please :) 2000-02-29 0:00 Help Me Please :) Will Mann 2000-02-29 0:00 ` Stanley R. Allen 2000-03-01 0:00 ` tmoran @ 2000-03-01 0:00 ` James Bean 2 siblings, 0 replies; 54+ messages in thread From: James Bean @ 2000-03-01 0:00 UTC (permalink / raw) Will Mann wrote: > > Can some one help me with my Ada.. my lecturer has given me code that > doesn't work... the compiler says that it can't handle "A".."Z" the > error message is : > > Inappropriate operands for "DOT_DOT" operation, continuing > > Thanks > > -- > > :\ / | | ALL DONE BYE BYE! > : \ /\ / * | | > : \/ \/ | |__ |__ "A" is a sring. 'A' is a character. Dot_dot's can't separate strings. Jim Bean ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2001-06-20 6:06 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-02-29 0:00 Help Me Please :) Will Mann 2000-03-01 0:00 ` Robert Dewar 2000-03-03 0:00 ` Florian Weimer 2000-03-03 0:00 ` tmoran 2000-03-04 0:00 ` Richard D Riehle 2000-03-05 0:00 ` Steve Arnold 2000-03-17 0:00 ` Robert A Duff 2000-03-18 0:00 ` James S. Rogers 2000-03-19 0:00 ` Robert A Duff 2000-03-20 0:00 ` Brian Rogoff 2000-03-20 0:00 ` Tucker Taft 2000-03-18 0:00 ` Richard D Riehle 2000-03-20 0:00 ` Florian Weimer 2000-03-22 0:00 ` Mats Weber 2000-03-27 0:00 ` Robert A Duff 2000-03-27 0:00 ` Hyman Rosen 2000-03-28 0:00 ` reason67 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Simon Wright 2000-03-29 0:00 ` reason67 2000-04-06 0:00 ` Simon Pilgrim 2000-04-07 0:00 ` Robert Dewar 2000-04-10 0:00 ` r_c_chapman 2000-03-28 0:00 ` Robert Dewar 2000-03-30 0:00 ` Mats Weber 2000-04-06 0:00 ` Exceptions (was: " Wes Groleau 2000-04-07 0:00 ` Mats Weber 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar 2000-03-31 0:00 ` Richard D Riehle 2000-03-31 0:00 ` Jean-Pierre Rosen 2000-03-31 0:00 ` Pascal Obry 2000-03-30 0:00 ` Mats Weber 2000-03-31 0:00 ` Richard D Riehle 2000-04-06 0:00 ` Wes Groleau 2000-03-30 0:00 ` Tucker Taft 2000-03-30 0:00 ` Mats Weber [not found] ` <2000Mar3.183321.69279@ludens> 2000-03-03 0:00 ` Larry Kilgallen 2000-03-04 0:00 ` Robert Dewar [not found] <df481109.0106140310.5d923746@posting.google.com> [not found] ` <9gb1uu$87u7o$1@ID-52877.news.dfncis.de> 2001-06-19 2:59 ` help me please! Ken Garlington 2001-06-16 10:20 ` C.D.Damron 2001-06-20 6:06 ` John Keeney -- strict thread matches above, loose matches on Subject: below -- 2000-02-29 0:00 Help Me Please :) Will Mann 2000-02-29 0:00 ` Stanley R. Allen 2000-02-29 0:00 ` Al Johnston 2000-03-01 0:00 ` Robert Dewar 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` Al Johnston 2000-03-02 0:00 ` Aidan Skinner 2000-03-01 0:00 ` Stanley R. Allen 2000-03-01 0:00 ` Robert Dewar 2000-03-01 0:00 ` Al Johnston 2000-03-01 0:00 ` tmoran 2000-03-01 0:00 ` James Bean
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox