[Gnu-arch-users] Re: Nit

[Miles Bader]

Tom Lord <address@hidden> writes:
> Say, does clu have continuations?

I don't think so.

BTW, here's a quote from `A History of CLU'* about exception handling:

   3.9. Exception Handling

   I have already discussed the fact that the main goal of the work on
   CLU was to support programming methodology.  We had a strong belief
   that some kind of exception mechanism was needed for this.  We wanted
   to support "`robust' or `fault-tolerant' programs, i.e., programs
   that are prepared to cope with the presence of errors by attempting
   various error recovery techniques [Liskov, 1975b, p. 9]." This means
   they must be prepared to check for "exceptional" conditions and to
   cope with them when they occur; a majority of the code is often
   dedicated to this.  Without a good mechanism this code is both hard
   to write and difficult to read.  Also, we believed that support for
   exceptions strengthens the abstraction power of the language.  Each
   procedure is expected to be defined over all possible values of its
   input parameters and all possible actions of the procedures it calls.
   However, it is not expected to behave in the same way in all cases.
   Instead, it may respond appropriately in each case [Liskov, 1975b,
   p. 11].

   Therefore, we decided that CLU ought to have an exception mechanism.
   Support for such a mechanism was already a goal in early l974
   [Zilles, 1974b].  In doing the design, we were aware of mechanisms in
   PL/I, Mesa [Mitchell, 1978; Lampson, 1974], and also Roy Levin's
   thesis [Levin, 1977] and the paper by John Goodenough [Goodenough,
   1975].

   CLU provides an exception mechanism based on the termination model of
   exceptions: A procedure call terminates in one of a number of
   conditions; one is the "normal" return and the others are
   "exceptional" terminations.  We considered and rejected the
   resumption model present in both PL/I and Mesa because it was complex
   and also because we believed that most of the time, termination was
   what was wanted.  Furthermore, if resumption were wanted, it could be
   simulated by passing a procedure as an argument (although closures
   would be useful here).

   CLU's mechanism is unusual in its treatment of unhandled exceptions.
   Most mechanisms pass these through: if the caller does not handle an
   exception raised by a called procedure, the exception is propagated
   to its caller, and so on.  We rejected this approach because it did
   not fit our ideas about modular program construction.  We wanted to
   be able to call a procedure knowing just its specification, not its
   implementation.  However, if exceptions are propagated automatically,
   a procedure may raise an exception not described in its
   specification.

   Although we did not want to propagate exceptions automatically, we
   also did not want to require that the calling procedure handle all
   exceptions raised by the called procedure, since often these
   represented situations in which there was nothing the caller could
   do.  For example, it would be a nuisance to have to provide handlers
   for exceptions that ought not to occur, such as a bounds exception
   for an array access when you have just checked that the index is
   legal.  Therefore, we decided to turn all unhandled exceptions into a
   special exception called "failure" and propagate it.  This mechanism
   seems to work well in practice.

-Miles

* http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."