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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: lgmayka@sprynet.com (Lawrence G. Mayka) Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/01/30 Message-ID: <32f7fe48.174476787@news.sprynet.com>#1/1 X-Deja-AN: 213130622 references: <5acjtn$5uj@news3.digex.net> <32e9e445.163056932@library.airnews.net> content-type: text/plain; charset=us-ascii organization: Sprynet News Service mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-30T00:00:00+00:00 List-Id: piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote: >It is much better to provide the two things separatley, for this allows >for example ``exception handling'' _without_ forcing control transfers, >and control transfers without necessarily involving dynamically scoped >identifiers. And then runtime parametrization via dynamically scoped >variables... Ironically, though, your first posting in this thread was a response to =my= posting, pointing out to Mr. Stroustrup that his design for exception handling was implemented years earlier in Common Lisp. As you may know, Common Lisp has long had both nonlocal control transfers (THROW and CATCH--perhaps Bjarne even borrowed his keywords from Lisp!) and dynamically scoped variables (as an option, along with the default behavior of lexical scoping). Indeed, some implementations of ANSI Common Lisp exception handling do indeed employ these earlier constructs. Just as you suggest, dynamically scoped functions are easily simulated via dynamically scoped variables whose values are function objects, or via syntax extension (the Common Lisp macroization system). But what your scheme lacks is a classification or "matching" mechanism. Common Lisp was well-prepared to provide this because, even before the standardization of CLOS, it offered the single-inheritance capability of DEFSTRUCT and the type-testing operator TYPEP; and so the Pittman Condition System was implementable entirely on top of 1985-vintage Common Lisp constructs, yet easily extendible to CLOS later. One other very useful element both your scheme and that of C++ lacks is that of closures as handlers. Very often, an exception handler is more comfortably and easily written as a lexically scoped function that manipulates the variables of an outer function. Again, Common Lisp already had full-power lexical closures by 1985, whereas C++ still doesn't. You may ask, if a language such as Common Lisp already has all the necessary base capabilities, why provide the "syntactic sugar" of exception handling constructs? To clarify, standardize, and perhaps optimize conventional usages. Since Common Lisp supports syntax extension (a powerful macroization system), programmers would probably be writing such syntactic encapsulations anyway; we may as well standardize them to enhance portability of programs, skills, knowledge, etc. Lawrence G. Mayka lgmayka@sprynet.com