Re: catch and throw, was Is multi-level function return possible?

Kaz Kylheku <kaz@kylheku.com>
Sat, 29 Mar 2014 02:07:08 +0000 (UTC)

          From comp.compilers

Related articles
[2 earlier articles]
Re: catch and throw, was Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-27)
Re: catch and throw, was Is multi-level function return possible? usenet@bitblocks.com (Bakul Shah) (2014-03-26)
Re: catch and throw, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-27)
Re: catch and throw, was Is multi-level function return possible? gneuner2@comcast.net (George Neuner) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? acolvin@efunct.com (mac) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? ivan@ootbcomp.com (Ivan Godard) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? ivan@ootbcomp.com (Ivan Godard) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? alan@scooby-doo.csail.mit.edu (Alan Bawden) (2014-03-29)
| List of all articles for this month |
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Date: Sat, 29 Mar 2014 02:07:08 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 14-03-065 14-03-068 14-03-070 14-03-076
Keywords: PL/I, errors
Posted-Date: 28 Mar 2014 23:08:58 EDT

On 2014-03-28, mac <acolvin@efunct.com> wrote:
>> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
>> ON would catch it. REVERT to cancel the effect of ON. Web search
>> indicates it was defined in 1964 but implemented later. May be the
>> PL/I designered borrowed it from an earlier
>
>
> Not quite the same. ON defined a handler invoked at the signal site. It
> could attempt repair and return. more like an interrupt. However, the
> typical handler did a non-local GOTO to bail out, clearing any calls
> between the signal and the gone-to label.
>
> I still think that the ability to resume can be useful.


PL/I seems to have been influential in the design of Common Lisp conditions,
right down to the terminology such as "conditions" being "signaled".


    (defun func ()
        (signal 'error))


    (tagbody
        (handler-bind ((error (lambda (cond) ;; Like PL/I "ON unit"
                                                        (format t "condition ~s signaled~%" cond)
                                                        (go :out)))
            (func))


        ;; "ON unit" is REVERT-ed, in PL/I terms, out of the scope
        ;; of the handler-bind form.
    :out
        (write-line "out"))


Under CLISP I get the output:


    condition #<ERROR #x20D8F216> signaled
    out


If the handler lambda returns instead of executing the (go :out) form, then the
system continues the search for the next matching handler and if one is not
found, or all the ones that are fond and executed simply bail out, then
control returns to the (signal 'error), causing it to return nil.


I.e. the transfer of control to the handler isn't a non-local transfer;
the (go :out) is!


Differences from PL/I are obvious: the strict nested scoping of the binding
constructs (no REVERT statement equivalent), and the use of a class hierarchy
for searching for the best handler for a given condition's type.


When a condition is handled in Lisp, the non-local control transfer is
not usually a GO, but rather the invocation of a restart.


Code which signals a condition can provide restarts which inform the handlers
about possible ways of continuing. For instance, a "file doesn't exist"
type condition could have a restart whose semantics is "continue processing
the rest of the file list" and another one for "abort the whole operation",
a third one for "try that file again", or yet another for the action
"supply a different file name in place of the nonexistent one, and
continue from that file on."


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.