Xref: utzoo comp.object:537 comp.lang.c++:5717 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!uw-june!peterd From: peterd@cs.washington.edu (Peter C. Damron) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Continuations Summary: scoping vs. functions vs. continuations Message-ID: <10008@june.cs.washington.edu> Date: 30 Nov 89 18:41:17 GMT References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <1623@odin.SGI.COM> <1989Nov28.183816.15252@odi.com> <9964@june.cs.washington.edu> <1989Nov29.225826.19483@odi.com> Reply-To: peterd@june.cs.washington.edu (Peter C. Damron) Organization: University of Washington, Computer Science, Seattle Lines: 86 In article <1989Nov29.225826.19483@odi.com> dlw@odi.com writes: >In article <9964@june.cs.washington.edu> peterd@cs.washington.edu (Peter C. Damron) writes: >>In article <1989Nov28.183816.15252@odi.com> dlw@odi.com writes: >>>In article <1623@odin.SGI.COM> shap@delrey.sgi.com (Jonathan Shapiro) writes: >>>>I do not believe that it is feasible to add continuations to C++ for >>>>any number of reasons, but I would be interested to hear the reactions >>>>in this community regarding their utility in object-oriented programming. >>> >>>They are just as useful in object-oriented programming as in straight >>>Lisp or Scheme. >> >>How can you make this claim? >Easy, I just press the keys, and... Seriously, I have used >continuations in an object-oriented programming language (Lisp with >Flavors), for years, as have several of my former colleagues. So I >feel pretty qualified to claim that they're useful. Do you have any >more specific rebuttal than amazement that I could even say such a >thing? The problem I have with including continuations into an object oriented language is a philisophical one. Objects should be self-contained and hide information. All interactions with objects should be through the well defined methods of the object. Now, if you add continuations, there is the potential to pass the continuation outside of the object, thus creating another entry point into the object that is not a member function. I see this as an information hiding problem for continuations in OO languages. Perhaps you can relate why this is not a problem in CLOS. >>>However, continuations in the Scheme style are only >>>useful if full support is provided for lexical scoping. C and C++ >>>have no lexical scoping whatsoever. >> >>I just had to reply when I saw this. C and C++ are definitely "lexically >>scoped" (I would prefer to call it statically scoped). >In a sense, C and C++ are lexically scoped, but only in a trivial >sense, since there are no internal procedures and no block structure. >So, you are technically right, and I should revise my statement to say >that continuations are only useful if the continuation can reference >variables of lexically enclosing blocks, and classic >"continuation-passing style" in the Sussman and Steele sense requires >further that they should be able to refer to such variables even if >the enclosing block is no longer being executed (what is traditionally >known in the Lisp/Scheme community as "supporting upward funargs"). >Few languages support upward funargs; Common Lisp and Scheme are two >that do. Many languages support downward funargs; Algol-60, Pascal, >and PL/I come to mind. In C, you can pass a function around as an >argument, but there is no "lexical link" allowing it to reference >variables in its parent block; in fact, there are no parent blocks in C. >(It can refer to static and extern, but that's not the same thing.) Let's get this straight. 1. Lexical (static) scoping is orthogonal to both continuations and first-class functions. C and C++ are fully lexically scoped langauges. Scoping has to do with naming -- which value does a name refer to. 2. C and C++ do not allow nested functions, but they do support block structure. Thus the lexical scoping is not "trivial". 3. Continuations are orthogonal to first-class functions (e.g. languages that allow both upward and downward funargs) and are orthogonal to block structure. It is not apparent to me that continuations are any less useful without block structure (though C and C++ have it anyway). It is also not apparent to me that continuations are any less useful without nested functions (though maybe more cumbersome). 4. C and C++ have first class functions. Functions can be passed as parameters, returned as function values, and assigned to variables. The reason that C and C++ do not allow nested functions is precisely so that they can have first-class functions implemented on a stack (e.g. no closure required). The "parent block" of a function is simply the global variables. Hope this helps to clear up any mis-understandings, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd Brought to you by Super Global Mega Corp .com