Message from discussion Common Lisp vs Scheme
From: han...@schlund.de (Hannah Schroeter)
Subject: Re: Common Lisp vs Scheme
Date: 13 Aug 2002 09:31:51 GMT
Organization: Schlund + Partner AG
References: <email@example.com> <firstname.lastname@example.org> <p5Z39.22111$sA3.email@example.com> <firstname.lastname@example.org>
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)
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)
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.