From: han...@schlund.de (Hannah Schroeter)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp vs Scheme
Date: 13 Aug 2002 09:31:51 GMT
Organization: Schlund + Partner AG
Lines: 51
Message-ID: <ajajm7$3ih$2@c3po.schlund.de>
References: <a6789134.0208042138.75167e34@posting.google.com> <aipdlv$tuu$4@c3po.schlund.de> <p5Z39.22111$sA3.7134@rwcrnsc52.ops.asp.att.net> <m3it2njwpt.fsf@dino.dnsalias.com>
NNTP-Posting-Host: c3po.schlund.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: news.schlund.de 1029233160 29607 172.17.0.51 (13 Aug 2002 10:06:00 GMT)
X-Complaints-To: usenet@schlund.de
NNTP-Posting-Date: 13 Aug 2002 10:06:00 GMT
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Originator: han...@schlund.de (Hannah Schroeter)
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!mango.news.easynet.net!easynet.net!feed.news.nacamar.de!news.belwue.de!news.uni-ulm.de!rz.uni-karlsruhe.de!schlund.de!c3po.schlund.de!not-for-mail

Hello!

Stephen J. Bevan <step...@dino.dnsalias.com> wrote:
>[...]

>I agree, but it can be used to implement an event driven system which
>is is based around select/poll/queue listening on non-blocking
>file-descriptors.  Using call/cc is is possible to write much of the
>code as if it is executing in separate "threads" as long as you are
>careful to implement any I/O calls using non-blocking I/O and call/cc
>to hook a continuation into the event distribution mechanism.

That's actually what I intended, too.

>You can of course do this without call/cc but not without writing much
>of the application code in a continuation-passing style.  I don't mind
>that too much myself but it certainly isn't going to win any clarity
>contests compared to the direct version (that uses call/cc underneath).

That's what I've done even in C++ many times. Of course,
in C++ it's much more icky than it'd be in Lisp or even
any modern statically typed functional language, regardless
of whether it's Haskell or some ML.

>One thing I've yet to determine is which of the the call/cc or CPS
>version actually performs better for various implementations.  If it
>turns out CPS is significantly better (enough to make up for the code
>contortions) then it would put an end to the only practical use I've
>ever made of call/cc.

It probably depends on the implementation. If the implementation
does full CPS transform, performance will probably be nearly
equal between both approaches: call/cc will be comparatively
cheap. If there's significant stack copying or so involved for
call/cc, your manual CPS transform will turn out better.

Of course, I'd have not too much problem with a de-facto standard
for cheap enough concurrency (meaning: no thread preemption
required, but threads should cost less than the memory for a
separate stack per thread) either. Things like Concurrent
Haskell (in GHC's implementation, it costs about 1 to 2 kb
of fixed overhead per thread, WITH thread-preemption),
Concurrent ML in SML/NJ's implementation (SML/NJ does
a full CPS transform, offers a call/cc equivalent but
also thread primitives which are implemented by continuation
switching plus a preemption mechanism), or Erlang (thread
costs significantly below 1 kB of memory) come to mind.

Kind regards,

Hannah.