Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!adobe!macb022.mv.us.adobe.com!user
From: mhamburg@mv.us.adobe.com (Mark Hamburg)
Subject: Re: The expense of call/cc (was R4RS)
Message-ID: <mhamburg-051094101457@macb022.mv.us.adobe.com>
Followup-To: comp.lang.scheme
Sender: usenet@adobe.com (USENET NEWS)
Organization: Adobe Systems, Inc.
References: <19941003T142911Z.enag@gyda.ifi.uio.no> <hbakerCx3zM5.FKn@netcom.com> <19941004T194114Z.enag@hnoss.ifi.uio.no>
Date: Wed, 5 Oct 1994 18:14:57 GMT
Lines: 23

blume@beth.cs.princeton.edu (Matthias Blume) writes:

> Why does this argument keep popping up again and again?!  I mean the
> one about call/cc.  There is still no clear evidence that call/cc
> hinders efficient compilation.  In fact, SML/NJ shows that such an
> implementation can be both simple and efficient.
> 
> Zhong Shao just recently finished his thesis describing many of the
> techniques use in the SML/NJ optimizer.  He devotes an extra section
> -Matthias

When I heard about Shao and Appel's papers on heap allocation being as
cheap as stack allocation, I eagerly pursued them.  Unfortunately, what it
really boils down to is that heap allocation is as cheap as stack
allocation if we have to implement general call/cc.  This assertion is
interesting but is not necessarily relevant when worrying about whether to
include generalized call/cc in a LISP implementation.

- Mark

P.S. I have not actually used SML/NJ but the reports I've received from
people who have indicate that it is still relatively big and slow.  Just
not as big and slow as some other implementations.
