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

George Neuner <gneuner2@comcast.net>
Fri, 28 Mar 2014 03:52:41 -0400

          From comp.compilers

Related articles
Is multi-level function return possible? noitalmost@cox.net (noitalmost) (2014-03-10)
Re: Is multi-level function return possible? gneuner2@comcast.net (George Neuner) (2014-03-11)
Re: Is multi-level function return possible? federation2005@netzero.com (2014-03-26)
Re: catch and throw, was Is multi-level function return possible? rpw3@rpw3.org (2014-03-27)
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)
[1 later articles]
| List of all articles for this month |
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Fri, 28 Mar 2014 03:52:41 -0400
Organization: A noiseless patient Spider
References: 14-03-020 14-03-023 14-03-065
Keywords: errors, history
Posted-Date: 28 Mar 2014 11:05:05 EDT

On Wed, 26 Mar 2014 17:39:25 -0700 (PDT), federation2005@netzero.com
wrote:


>On Tuesday, March 11, 2014 12:56:01 PM UTC-5, George Neuner wrote:
>
>> The modern term is "exception". See also "non-local" control
>> transfer, exit and/or return, and "escape" or "backtracking"
>> continuation.
>
>Right, the contemporary (not "modern") [Note 1] notion is the
>catch-throw paradigm.


TouchC). However, the date of writing is part of the context of a
missive, and I think people reading - and particularly responding to -
anything found on the Internet needs to be aware of the post date.


But this is off-topic here in comp.compilers.
[Only sort of. I get mail from googlegroups users arguing
with a message posted 20 years ago. -John]


>I like to think of it as the "cap and trap" mechanism.
>
>I believe it originates with Prolog in the 1970's, since (a) catch and
>throw are part of Prolog's library of built-in functions, and (b) the
>multi-level breakout has always been an integral part of its run-time
>system.


My understanding was that CATCH/THROW originated with MacLisp, though
IIRC it was roughly the same time (1971-72) as Prolog was introduced,
so there may have been some cross-pollenization WRT syntax.


In fact, MacLisp already had a non-local error exit form: ERRSET/ERR.
CATCH/THROW was introduced as an alternative syntax specifically for
non-error situations because programmers were abusing ERRSET/ERR for
all kinds of non-local returns.




>The idea may also be motivated, in part, by the Curry-Howard
>isomorphism, which relates the "AND", "OR" and "IF-THEN" connectives
>of Intuitionist logic respectively to the product, union and function
>types. When the scope of the correspondence is extended to classical
>logic, it connects Pierce's Rule to the catch-throw mechanism. Look
>under the Wikipedia entry, for instance, which also points to the
>call/cc mechanism of Scheme and to the related notion of continuation
>passing.


Very interesting! Thanks for the pointer.


George


Post a followup to this message

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