Xref: utzoo comp.object:530 comp.lang.c++:5713 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!rochester!rit!mjl From: mjl@cs.rit.edu Newsgroups: comp.object,comp.lang.c++ Subject: Re: Continuations Message-ID: <1419@cs.rit.edu> Date: 30 Nov 89 13:49:07 GMT References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <1623@odin.SGI.COM> <1663@odin.SGI.COM> Sender: news@cs.rit.edu Reply-To: mjl@prague.UUCP (Michael Lutz) Followup-To: comp.object Organization: Rochester Institute of Technology, Rochester, NY Lines: 41 In article <1663@odin.SGI.COM> shap@delrey.sgi.com (Jonathan Shapiro) writes: > >... What is interesting about continuations is that >they freeze an execution context into an object whose internals are >not exposed to the programmer, but which can be invoked at a later >time and passed a single value which is the value to return. Since >the object can be saved outside of the scope in which it was defined, >the continuation can be returned from multiple times. > >The reason messaging a static data area isn't enough is that you need >to preserve the stack, and portions of the stack can be shared between >the captured continuation and the main program thread. What is the essential difference between a continuation in Scheme and the classic notion of a coroutine? Coroutines have been around for years (Conway's paper describing them came out in the '60s), and can be found in Simula-67 (where they are used with the object metaphor to represent the semi-independent entities in a simulation). The "processes" of Modula-2 are also ccoroutines. There are several packages for C that implement "light weight processes", and these are essentially ccoroutines (I have one available if anyone is interested). Finally, Stroustrup has a tasking package for C++ which captures this concept. This is not to deny that Scheme may have a more elegant, general,and formal (and thus less ad-hoc) approach, but I think we have to be alert enough to recognize essential similarities buried under surface differences. Have I found such a similarity here? On a side note, aren't lexical scoping and continuations independent concepts? Why I couldn't define a consistent language with continuations where the meaning of a variable depends on the dynamic invocation sequence rather than static nesting? I might not want to *use* such a language (dynamic scoping makes it almost impossible to understand a module/function in isolation) but that's an engineering issue, not one of feasibility. Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu Brought to you by Super Global Mega Corp .com