Xref: utzoo comp.object:557 comp.lang.c++:5741 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Continuations Message-ID: <1989Dec1.231007.24598@odi.com> Date: 1 Dec 89 23:10:07 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> <10008@june.cs.washington.edu> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 43 In-Reply-To: peterd@cs.washington.edu's message of 30 Nov 89 18:41:17 GMT In article <10008@june.cs.washington.edu> peterd@cs.washington.edu (Peter C. Damron) writes: 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. Well, I admit that this is all rather hard to articulate. I see continuations as a control structure concept. It is part of the way you tell your computer program what to do next, how the locus of control should move throughout the lines of code. As such, it is really orthogonal to the important concepts of object-oriented programming: you can have loops in OOPS, and you can have recursion in OOPS, so why not coroutines and continuations? In this specific case, no, I don't think it creates a new "entrypoint", although this statement is based on a concept of "entrypoint" that I'm having trouble articulating. Part of the important point is that encapsulation is not violated, because only a method of a class can create a continuation that continues within that class. I hope that explains what I mean; sorry I can't do better. Let's get this straight. Yes, I used the terminology in an inexact (wrong) way, as I said in recent postings. I apologize. I meant to say that C and C++ do not have first-class nested functions that are block structured with respect to their containing functions. 3. Continuations are orthogonal to first-class functions (e.g. languages that allow both upward and downward funargs) and are orthogonal to block structure. Hmm. The only continuation-passing-style programs that I've ever seen certainly spent a lot of time dealing with first-class objects that were upward and downward funargs. Perhaps you could sketch out an extension to C that would provide continuations, without providing such functional objects, and then I'd see what you're getting at. Brought to you by Super Global Mega Corp .com