Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!ames!lll-winken.llnl.gov!venus.sun.com!wnoc-sfc-news!sfc-keio-news!mad
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: CALL/CC (was Re: ISO/IEC CD 13816 -- ISLisp)
In-Reply-To: mad@math.keio.ac.jp's message of Thu, 14 Dec 1995 05:35:51 GMT
Message-ID: <MAD.95Dec21180213@tanzanite.math.keio.ac.jp>
Sender: news@sfc.keio.ac.jp
Nntp-Posting-Host: tanzanite.nak.math.keio.ac.jp
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
References: <49u965$948@goanna.cs.rmit.EDU.AU>
	<MAD.95Dec14143551@tanzanite.math.keio.ac.jp>
	<4as2be$ckp@camelot.ccs.neu.edu>
	<19951215T014159Z@arcana.naggum.no>
	<4b35de$ilh@goanna.cs.rmit.EDU.AU>
Date: Thu, 21 Dec 1995 09:02:13 GMT
Lines: 102

>>>>>> "mad" == MAEDA Atusi Kmad@math.keio.ac.jp> writes:
    mad> * UNWIND-PROTECT no longer works with it.  The following code:
    mad> (UNWIND-PROTECT
    mad>    <some file processing>
    mad>    (CLOSE FILE))
    mad> looks okay.  But what will happen if someone captured continuation
    mad> inside <some file processing> and try to resume processing later?

>>>>> "will" == William D Clinger <will@ccs.neu.edu> writes:

    will> UNWIND-PROTECT is a special case of DYNAMIC-WIND.  It is true that
    will> UNWIND-PROTECT is not powerful enough to protect against all uses
    will> of CALL-WITH-CURRENT-CONTINUATION.  That's why Scheme programmers
    will> use DYNAMIC-WIND instead.

>>>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:

    ok> Funny, I thought that problem had been solved by the introduction of
    ok> 	(DYNAMIC-WIND before-thunk result-thunk after-thunk)
    ok> It is widely available, and does deal with the issue of CALL/CC exits
    ok> (after-thunk is called) and reentrances (before-thunk is recalled).

I think DYNAMIC-WIND won't help in this particular case, unless the
language provide a way to reopen and reset the state of closed file.
One possible solution is to make before-thunk flag an error when
invoked twice, preventing reentrances.

Now, should ISLisp include CALL/CC and define CATCH, THROW, and
UNWIND-PROTECT in terms of CALL/CC?  I'd like to hear from people who
are using CALL/CC heavily.  Is CATCH/THROW insufficient in many cases?
(I write programs in mainly Common Lisp).

    mad> * CALL/CC defeats some compiler optimizations.
    mad> (LET ((A ..))
    mad>   ..
    mad>   (LET ((X A))
    mad>     (FOO)
    mad>     (SETQ X (+ X 1)))
    mad>   ..)
    mad> cannot be transformed into:
    mad> (LET ((A ..))
    mad>   ..
    mad>   (PROGN
    mad>     (FOO)
    mad>     (+ A 1))
    mad>   ..)
    mad> in the presence of CALL/CC.

    ok> Yes.  IF it is used.  Most escape handling methods in most programming
    ok> languages defeat some compiler optimisations, when they are used.

Actually, my example illustrates that CALL/CC disables some
optimizations even if it isn't really used.  The problem is the
*possibility* of captured continuation.

    will> (let ((a ...))
    will>   ...
    will>   (let ((x a))
    will>     (foo #'(lambda (v)
    will>              (setq x (+ x 1)))))
    will>   ...)

    will> cannot be transformed into

    will> (let ((a ...))
    will>   ...
    will>   (let ((x a))
    will>     (foo #'(lambda (v)
    will>              (+ a 1))))
    will>   ...)

    will> either, even in a language without CALL/CC.  My example is, of
    will> course, equivalent to MAEDA's.

This CPS version is equivalent to mine only when the language provides
first-class continuations.

My point is that, in the presence of CALL/CC, compiler can't prove
that a form after (unknown) function call is evaluated just once.
Hence, compiler can't move any side-effecting forms across (unknown)
function call, and can't remove some side effect.

>>>>> "erik" == Erik Naggum <erik@naggum.no> writes:

    erik> is it meaningful to restrict a continuation to be the continuation of a
    erik> currently active activation?  i.e., not allow re-entry to a continuation
    erik> and no separate life of a continuation apart form the activation records?
    erik> this would once again make co-routines harder to implement, but that could
    erik> perhaps be another (related) conce000000012
    ok> the usage_ of call/cc to the "structured" case WITHOUT LOSING SCHEME
    ok> COMPATIBILITY.  It's called Elk.  (Whether you get full call/cc or cheap
    ok> call/cc depends on how much work the person did who ported Elk to your
    ok> machine.)  The result is that you can write code using call/cc in a
    ok> "structured" way in Elk, and run the _same_ code in another Scheme.

EuLisp also has continuations with dynamic extent.

;;;  Keio University
;;;    Faculty of Science and Technology
;;;      Department of Math
;;;		MAEDA Atusi (MAEDA is my family name)
;;;		mad@math.keio.ac.jp
