Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!think.com!barmar
From: barmar@think.com
Newsgroups: comp.object
Subject: Re: Continuations
Message-ID: <31833@news.Think.COM>
Date: 30 Nov 89 18:18:06 GMT
References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <31794@news.Think.COM> <1623@odin.SGI.COM> <99894@ti-csl.csc.ti.com> <4286@pegasus.ATT.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 43

In article <4286@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes:
>Remember, many C++ implementations generate C code.  If C++ provides a
>feature that can't be implemented in C, that whole method (which has
>made it much easier and faster to get object-oriented programming
>methods into the hands of programmers) goes down the tubes.

Anything can be implemented in C (it's Turing complete, or whatever the
term is).  The C code may not look like the corresponding C++ code, but who
cares?  There are Lisp compilers that generate C code, and they have no
problem dealing with the fact that C doesn't have complex and
infinite-precision numbers or a garbage collector.  And on Symbolics Lisp
Machines, the C compiler generates Lisp code.  In both directions, there is
no rule that similar concepts must be implemented using the corresponding
features of each language; for instance, C++ activation records don't have
to map directly to C activation records.

>So you're saying that C++ (and by implication, C) would have to abandon
>their simple stacks in order to have first-class continuations?
>
>Efficiency (that is, allowing for the straightforward implementation of
>translators that produce efficient code) is one of the goals of the C++
>programming languages.  Even with inline functions, a C++ program will
>have lots of subroutine calls.  A simple stack helps minimize the
>overhead of those calls.

It's a common fallacy that continuations impose excessive overhead.  First
of all, the overhead is generally only imposed when continuations are
actually used.  A program that obeys pure stack discipline should not be
affected.  Only when the compiler sees that a continuation is being used
might it have to generate extra code to deal with it.  Other people have
pointed out the literature on "segmented stacks", which are alternatives to
heap-allocated activation records.  I'm not extremely familiar with Scheme
implementation, but implementors I've talked to have convinced me that the
availability of continuations doesn't prevent efficiency.  Many of the
languages that provide continuations and/or upward closures also provide a
garbage-collected heap, so heap-allocation of activation records (when
necessary) is the simplest, and hence frequently initial, technique used by
implementors of such languages; such implementations should not be used as
a benchmark to indict continuations in general.
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar


Brought to you by Super Global Mega Corp .com