Xref: utzoo comp.object:516 comp.lang.c++:5693 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!snorkelwacker!think!think.com!barmar From: barmar@think.com Newsgroups: comp.object,comp.lang.c++ Subject: Re: Continuations Message-ID: <31794@news.Think.COM> Date: 29 Nov 89 04:18:25 GMT References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <1623@odin.SGI.COM> <128489@sun.Eng.Sun.COM> Sender: news@Think.COM Followup-To: comp.object Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 22 In article <128489@sun.Eng.Sun.COM> grover@sun.UUCP (Vinod Grover) writes: >I do not know if you are talking about first-class continuations or not, but >in languages which are stack-based first-class continuations are not trivial >to add. (By stack-based I mean that the procedure entry exit sequance >behaves in a stack-like fashion) This is a circular argument. It's the very existence of first-class continuations in Scheme-like languages that causes them not to be stack-based. If Scheme didn't have continuations then it would be stack-based, according to your definition. Scheme is simply the result of adding continuations to Lisp. Of course, when you add them you have to redesign implementations to handle them properly. This means that you can't always use a linear stack to implement activation records -- you may have to allocate activations in the heap and garbage collect them. Upward closures also require similar support. First-class continuations are simply an extension of upward closures to include control information as well as variable bindings. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar Brought to you by Super Global Mega Corp .com