From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-05-01 12:03:04 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died) Date: 1 May 2003 12:03:04 -0700 Organization: http://groups.google.com/ Message-ID: References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0304240446.493ca906@posting.google.com> <3EA7E0E3.8020407@crs4.it> <9fa75d42.0304240950.45114a39@posting.google.com> <4a885870.0304291909.300765f@posting.google.com> <416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net> NNTP-Posting-Host: 64.114.87.129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1051815784 22694 127.0.0.1 (1 May 2003 19:03:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 May 2003 19:03:04 GMT Xref: archiver1.google.com comp.lang.java.advocacy:62993 comp.object:62487 comp.lang.ada:36817 misc.misc:13868 Date: 2003-05-01T19:03:04+00:00 List-Id: "Frank J. Lhota" wrote in message news:... > "Kaz Kylheku" wrote in message > news:cf333042.0304300835.4800e03e@posting.google.com... > > If you don't think so, it's only > > because you are too absorbed in the arcane details that separate your > > favorite high level assembly language from the next one. > > ??? A language with generics, exceptions and dispatching is still a > high-level assembly language??? Ada exceptions are a laughably low-level mechanism, that is about as powerful as some of the feeble C macro packages that wrap up setjmp and longjmp. Some of those packages are more powerful because they can subclass errors into categories. Modern languages represent errors using class hierarchies, allowing handlers to express more or less specific matches. Ada's exception system is not useful for much more than containing errors. It pales in comparison to Common Lisp's conditions and restarts. The correct design for error handling is to unwind to an outer dynamic context *as a the very last step*, after an analysis is performed and the proper place to unwind to has been chosen. Ada's exception system is more like that of C++; when an exception is raised, it starts discarding dynamic frames until a handler is found. An error handler should preserve the full dynamic context of the situation---this is how exception vectors in processor architectures work. When an interrupt happens, the currently running thread is not unwound all the way back to the operating system! No, the exception pushes new information onto the stack, and can later restart the task exactly where it left off. For example, you hit a page fault, the operating system's handler makes the page available, and then restarts the process, so the access instuction is tried again and succeeds this time. Unwinding on error is the stupidest possible thing to do; it allows for containment, but not recovery. I would be tempted to hack up my own error system based on registering handler *functions*, and using the exceptions as the final step in error handling, to unwind to a restart point. The Ada exception handlers resemble Common Lisp's restarts in some ways, most notably that they are points in the dynamic context identified by symbols. But, sadly, there is no way to introspect over them; in other words, to compute a list or otherwise enumerate or iterate over the handlers that are visible in a given dynamic context. So you can't implement logic like ``if there is a handler for Foo exception, then raise it'' which would represent the idea ``if a Foo way of continuing is available at this point, let's choose it''. A WHEN clause in the exception block also has no way of returning back to the raise point to show that it's declining to handle the error. Nevertheless, with this approach, one could perhaps implement some rudimentary error recovery protocols. For example, suppose that we agree on a very simple convention that we will have two ways of continuing after an error: an Abort and Retry. When I call your module and it encounters a problem, it calls a handler callback in my module. No unwinding takes place yet. In my module I then decide (perhaps with the help of a user) whether to retry the operation or abort, and raise the appropriate exception, which passes back to your code. If I raise Retry, then the operation which failed will be tried again. Of course, I can raise some third exception that your module doesn't know about, to obtain a non-local exit that bypasses your module entirely. In other words, exceptions are really restart choices; the last step in the protocol for recovering from an error situation, based on making some sort of informed decision at a higher layer combined with advice at the lower layer. I would want this formalized into a language feature which supports the dynamic registration and automatic deregistration of handlers, association of handlers with some symbols or whatnot to support exact or inexact searching and so on. A decent macro system would go a long way. Oops! Interestingly, I see in Ada's exception system an attempt to reinvent the idea of a symbolic data type. When you write Foo : exception; to introduce a new exception symbol, this is very much like symbol interning, except that it's conflated into a subcomponent of the language rather than standing alone. From Ada95 we have: Each distinct exception is represented by a distinct value of type Exception_Id. Null_Id does not represent any exception, and is the default initial value of type Exception_Id. Each occurrence of an exception is represented by a value of type Exception_Occurrence. Null_Occurrence does not represent any exception occurrence, and is the default initial value of type Exception_Occurrence. And of Common Lisp we could write: Each identifier scanned by the reader is interned in the current package; distinct names give rise to distinct symbols, which are objects that are useful for their unique identity, and various properties that can be associated with them. The symbol NIL (in the "COMMON-LISP" package) is not equal to any other symbol. Funny to see Greenspun's Tenth Rule of Programming at work in Ada also! I'm warmly entertained, by the way, by how the string returned by Exception_Message may be truncated to 200 characters. Ah, assembly language and its fixed buffers.