Xref: utzoo comp.object:595 comp.lang.c++:5825
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!orc!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Continuations
Message-ID: <48758@ricerca.UUCP>
Date: 8 Dec 89 01:28:23 GMT
References: <1713@odin.SGI.COM> <11049@goofy.megatest.UUCP> <5369@rice-chex.ai.mit.edu>
Sender: news@orc.Olivetti.Com
Reply-To: chase@Ozona.UUCP (David Chase)
Followup-To: comp.object
Organization: Olivetti Research California, Menlo Park, CA
Lines: 19

In article <5369@rice-chex.ai.mit.edu> nn@rice-chex.WISC.EDU (Nick Nussbaum) writes:
>	Those interested in continuations in C might want to look
>at a paper by Thomas Bruel which I believe was presented at the
>Usenix 88 conference. He proposed implementing closures by
>generating pointer to some automatically generated code which sets
>up the environment and then jumps into the function. Thus closures
>can be used in the same way as vanilla function pointers.

It's a neat trick (Stallman put me in touch with Thomas Breuel, who
described it to me), and I even used it for a while in a Modula-3
compiler.  Most unfortunately, life gets much more complicated on
architectures/OSes that separate instructions and data (by page
protection, or in potentially inconsistent caches).  Some calling
conventions also make this difficult -- it's dead easy on a Sun 1, 2,
or 3, less easy on a SPARC, and I'm not sure that it's tractable at
all on a MIPS, i860, or 88000.  Bummer, that.  It was great fun while
it lasted.

David