Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[kaz@ashi.footprints.net (Kaz Kylheku)]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<qDTra.23221$xw4.9186@nwrdny01.gnilink.net>...
> "Kaz Kylheku" <kaz@ashi.footprints.net> 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.