Hi,
The subject line should be telling.
Background: The recent thread about web applications vs. continuations
has nearly convinced me that call/cc is probably not very essential for
web applications, contrary to popular belief in some circles. (I still
have to absorb the related information.)
I recall hearing the argument that there are no good real-world examples
of useful applications of call/cc. However, I have skipped through the
Screamer sources and documentation, and from that one can get the
impression that call/cc might have helped a lot in this case.
I have googled for "continuations screamer" and "call/cc screamer", but
haven't found any good arguments pro or against call/cc based on
Screamer's implementation.
I mean, it's clear that Screamer is implemented on top of Common Lisp,
_without_ call/cc, but only by simulating call/cc via a transformation
into CPS which is relatively complicated, and doesn't cover all of
Common Lisp. Wouldn't call/cc have considerably reduced the complexity
of Screamer's implementation? Or am I missing something?
Pascal
> I mean, it's clear that Screamer is implemented on top of Common Lisp,
> _without_ call/cc, but only by simulating call/cc via a transformation
> into CPS which is relatively complicated, and doesn't cover all of
> Common Lisp. Wouldn't call/cc have considerably reduced the complexity
> of Screamer's implementation? Or am I missing something?
It's not that continuations do not have applications. But they do come with
a complexity to the compiler and runtime. Also, a lot of those applications
are simply advanced control structures where the control structure itself is
simply more important to most users than the technique (in this case
continuations) used to implement them. And, as has been mentioned before, CL
has many of those control structures already.
Now it can, perhaps, be argued that while there are higher level
applications for continuations, that they are rare and thus not worth the
overhead and complexities to add to the language implentation for the
marginal value they may bring to selected applications.
Would Screamer have been easier to implement in a system with continuations?
Probably. But it can be argued that Screamer is an example where it pretty
clear that CL DOESN'T need native continuations, simply because it was able
to implemented for this case.
Now the next question is what performance impact would native continuations
have on something like Screamer compared to the version that they
implemented on top of CL. This I have no answer for.
But I bring it up because one of the curses against Scheme is that it
doesn't have a built in object system, but the counter is that they have
implmentations of object systems x, y, and z on top of stock Scheme.
(Therefore, it's perhaps pot-kettle-black to say CL doesn't need
continuations as demonstrated by Screamer and Scheme doesn't need an object
system as demonstrated by meroon, or yasos or whatever).
However, with CLOS being part of the standard, implementors are able to
assume its existence and even optimize certain aspects of it within the
compiler (for example, slot access). So, while one could implement any
object system one wanted on top of CL (for example, see Garnets), today it
may well be better to simply stick with CLOS because it could be more
performant for a given implementation.
Simply put, while you can write CLOS on top of CL, you can write a better
CLOS if the compiler knows about it.
So, while Scheme is required to implement continuations solely for the sake
of particular control structures (rather than specifying the control
structures themselves to be implemented is whatever appropriate way), Scheme
does not require an object system that could be optimized and used by all,
even though odds are today an object system is more valuable and applicable
to a wide range of applications than native continuations.
Of course, some Schemes do implement their own object system native to the
compiler, but it's not a "standard", nor necessarily portable object system.
I don't know Screamer at all, only anecdotaly. I'm sure native continuations
would have had some effect on the design. But I think if I had my choice
between native continuations to make Screamer-like programs easier vs native
CLOS to make most everything else (including, perhaps, Screamer like
programs), I'd rather have the native CLOS.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> I don't know Screamer at all, only anecdotaly. I'm sure native continuations
> would have had some effect on the design. But I think if I had my choice
> between native continuations to make Screamer-like programs easier vs native
> CLOS to make most everything else (including, perhaps, Screamer like
> programs), I'd rather have the native CLOS.
I strongly prefer Common Lisp over Scheme for many reasons, including
those that you mention. I am just trying to sift through the reasons why
one wouldn't want to have call/cc in a language.
Thanks to you and the other ones who responded to my question!
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Brian Mastenbrook
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <BBDCEC49.59F%bmastenb@indiana.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/15/03 10:16 AM, in article
············@newsreader3.netcologne.de, "Pascal Costanza"
<········@web.de> wrote:
>
> I strongly prefer Common Lisp over Scheme for many reasons, including
> those that you mention. I am just trying to sift through the reasons why
> one wouldn't want to have call/cc in a language.
>
> Thanks to you and the other ones who responded to my question!
>
>
> Pascal
I am not sure you really understand what call/cc is giving you, if you
don't understand how Screamer transforms your code into CPS. So I'll
give you a quick runthrough:
In Continuation-Passing Style, every time you would ordinarily return
a value, you instead call a continuation (lambda of one value) with
your value. These continuations are passed to your function as an
extra argument. Any time which you would expect a return value from a
potentially non-simple function, instead you pass a continuation that
waits for its return value and continues the computation accordingly
(hence the name). These continuations end up capturing the explicit
control-flow of the program, so Schemers decided to let you obtain
your current continuation even when you aren't writing CPS code. This
really handy when building a language-in-a-language.
However, I would quite simply not ever want to depend on somebody
else's library which used call/cc with indefinite extent. When working
with somebody else's code, I want to know that it's going to return
only once. As such I don't think call/cc would be a good thing for CL,
which seems to be picking up steam in the MORE CODE / MORE LIBRARIES
department.
For web applications, call/cc poses a slight problem - you're going to
have to keep track of where you're keeping any "real world"
information like open files and sockets, because if you don't you
might end up calling a continuation to a time when a particular file
or socket was open that is now no longer open... KABOOM!
So perhaps you'd like to keep them in specials, as after all things
like sockets and open files are usefully dynamically scoped. Except,
in most Scheme implementations, specials/fluids are defined using
dynamic-wind, meaning that when you call/cc out of the expression,
your value of the special is lost! When you use explicit CPS, on the
other hand, or even a CPS transformer, your value of the special
sticks, because you are not exititing the dynamic scope of your
function - instead, you are just applying a regular old lambda.
Thus explicit CPS or a transformer works out better for web
programming anyway :-)
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBP7eCAWnXQDi0istxEQLm7QCg2kt/Z/lOOdTvpYqnz19aoWHgSpkAoP8A
7TA1tl3EVfEt2Q52hu4gbB07
=Oj4S
-----END PGP SIGNATURE-----
Brian Mastenbrook wrote:
> For web applications, call/cc poses a slight problem - you're going to
> have to keep track of where you're keeping any "real world"
> information like open files and sockets, because if you don't you
> might end up calling a continuation to a time when a particular file
> or socket was open that is now no longer open... KABOOM!
>
> So perhaps you'd like to keep them in specials, as after all things
> like sockets and open files are usefully dynamically scoped. Except,
> in most Scheme implementations, specials/fluids are defined using
> dynamic-wind, meaning that when you call/cc out of the expression,
> your value of the special is lost! When you use explicit CPS, on the
> other hand, or even a CPS transformer, your value of the special
> sticks, because you are not exititing the dynamic scope of your
> function - instead, you are just applying a regular old lambda.
>
> Thus explicit CPS or a transformer works out better for web
> programming anyway :-)
Brian, thanks a lot for pointing this out in such clear and easily
understandable words! This fits very nicely with some other ideas I
currently have wrt dynamic scoping, and you have just helped me to get a
better view on the issues involved.
Thanks!
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Joe Marshall
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <brrcxfk1.fsf@comcast.net>
Brian Mastenbrook <········@indiana.edu> writes:
>
> Thus explicit CPS or a transformer works out better for web
> programming anyway :-)
>
Except for one thing: tail recursion.
Because continuation-passing-style calls a continuation instead of
returning, the stack can get arbitrarily deep. You can get away with
this to some extent if your stack is deep enough and you attempt to
avoid continuation-passing-style unless absolutely necessary (as
Screamer does), or you can use an implementation that supports tail
recursion under certain circumstances (Allegro CL and Xanalys
Lispworks are among these).
--
~jrm
From: Brian Mastenbrook
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <BBDD68F4.5B8%bmastenb@indiana.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/16/03 2:46 PM, in article ············@comcast.net, "Joe Marshall"
<·············@comcast.net> wrote:
> Except for one thing: tail recursion.
>
> Because continuation-passing-style calls a continuation instead of
> returning, the stack can get arbitrarily deep. You can get away with
> this to some extent if your stack is deep enough and you attempt to
> avoid continuation-passing-style unless absolutely necessary (as
> Screamer does), or you can use an implementation that supports tail
> recursion under certain circumstances (Allegro CL and Xanalys
> Lispworks are among these).
>
Ah, yes. I forgot to mention the other piece of the puzzle:
trampolining, which fixes that too. I'd assume any CPS-based web
framework for CL would perform silent trampolining for you as well.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBP7f+tGnXQDi0istxEQKfvQCdH2SqdJP+W0DGHE1RcC2foUYMIqUAniiv
RapZBWFbG3idK6mP0j2YR9mc
=c1is
-----END PGP SIGNATURE-----
From: Christophe Rhodes
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <sqy8uggj94.fsf@lambda.jcn.srcf.net>
Joe Marshall <·············@comcast.net> writes:
> Because continuation-passing-style calls a continuation instead of
> returning, the stack can get arbitrarily deep. You can get away with
> this to some extent if your stack is deep enough and you attempt to
> avoid continuation-passing-style unless absolutely necessary (as
> Screamer does), or you can use an implementation that supports tail
> recursion under certain circumstances (Allegro CL and Xanalys
> Lispworks are among these).
Which current implementations don't support tail-call elimination
under any circumstances?
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Joe Marshall
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <3ccnxiku.fsf@comcast.net>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Joe Marshall <·············@comcast.net> writes:
>
>> Because continuation-passing-style calls a continuation instead of
>> returning, the stack can get arbitrarily deep. You can get away with
>> this to some extent if your stack is deep enough and you attempt to
>> avoid continuation-passing-style unless absolutely necessary (as
>> Screamer does), or you can use an implementation that supports tail
>> recursion under certain circumstances (Allegro CL and Xanalys
>> Lispworks are among these).
>
> Which current implementations don't support tail-call elimination
> under any circumstances?
Corman Common Lisp is one.
--
~jrm
Brian Mastenbrook wrote:
> However, I would quite simply not ever want to depend on somebody
> else's library which used call/cc with indefinite extent. When working
> with somebody else's code, I want to know that it's going to return
> only once.
Some implementations also provide call/cc1, which is similar to
call/cc, but where the continuation is a so called one-shot continuation,
i.e. it can only be called once. A one-shot continuation is cheaper
to capture than one with indefinite extent.
<http://citeseer.nj.nec.com/bruggeman96representing.html>
--
Jens Axel S�gaard
On 2003-11-14 16:49:16 -0500, Pascal Costanza <········@web.de> said:
> Hi,
>
> The subject line should be telling.
>
> Background: The recent thread about web applications vs. continuations
> has nearly convinced me that call/cc is probably not very essential for
> web applications, contrary to popular belief in some circles. (I still
> have to absorb the related information.)
>
> I recall hearing the argument that there are no good real-world examples
> of useful applications of call/cc. However, I have skipped through the
> Screamer sources and documentation, and from that one can get the
> impression that call/cc might have helped a lot in this case.
>
> I have googled for "continuations screamer" and "call/cc screamer", but
> haven't found any good arguments pro or against call/cc based on
> Screamer's implementation.
>
> I mean, it's clear that Screamer is implemented on top of Common Lisp,
> _without_ call/cc, but only by simulating call/cc via a transformation
> into CPS which is relatively complicated, and doesn't cover all of
> Common Lisp. Wouldn't call/cc have considerably reduced the complexity
> of Screamer's implementation? Or am I missing something?
Yes. call/cc does not preserve the semantics that code only ever unwinds (returns). This naturally conflicts with unwind-protect, which is another extremely useful tool for web (or any "real" application) programming. Essentially any attempt to rectify the two either revolves around forcing a declaration of whether or not you intend to call the continuation again and postponing the protect form (which is not so useful when you don't know what may be running in your unwind-protect) or by restricting the scope of the continuations.
Screamer in fact shows the opposite of what you expect - it shows that you can use continuations without explict CPS even when the language does not "natively" support them as first-class multi-callable entities.
Brian Mastenbrook wrote:
> Screamer in fact shows the opposite of what you expect - it shows that you can use continuations without explict CPS even when the language does not "natively" support them as first-class multi-callable entities.
OK, this means I have to check the Screamer code more carefully. Can you
give me a hint what I should be looking for?
Thanks,
Pascal
From: Pierpaolo BERNARDI
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <x2ftb.23843$9_.903185@news1.tin.it>
"Pascal Costanza" <········@web.de> ha scritto nel messaggio ················@newsreader3.netcologne.de...
> I have googled for "continuations screamer" and "call/cc screamer", but
> haven't found any good arguments pro or against call/cc based on
> Screamer's implementation.
You may want to compare Screamer with the analogous system
written in Scheme successively by one of the authors of
Screamer (Siskind).
It's included in the library Qobischeme, available from the author's
home page.
P.
Pascal Costanza wrote:
> Wouldn't call/cc have considerably reduced the complexity
> of Screamer's implementation? Or am I missing something?
The punch line may be that constraint logic programming was a terrible
idea. When the desperate Search for A Use (Any Use!) for a neat hack
produces nothing but a Godawful Programming Technique, it could be a Bad
Sign.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Pascal Costanza wrote:
>
>> Wouldn't call/cc have considerably reduced the complexity of
>> Screamer's implementation? Or am I missing something?
>
>
> The punch line may be that constraint logic programming was a terrible
> idea.
Why is that?
Pascal
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Wouldn't call/cc have considerably reduced the complexity of
>>> Screamer's implementation? Or am I missing something?
>>
>>
>>
>> The punch line may be that constraint logic programming was a terrible
>> idea.
>
>
> Why is that?
The premise was Free Lunch. There is no free lunch. They wanted to have
the engine figure things out for them based on partial information,
including even which things to figure out. Didn't scale. Computers are
dumb, In the end, you still have to tell them everything. The engines
started figuring wrong. Now you have an engine you want to run
autonomously figuring things out, but you are adding bells and whistles
by which to steer it away from dumb results. Almost works, then it
figures wrong again. I know! Walkabout strengths! (actul name for a
refinement aimed at getting the engines to stop being so dopey. More and
more refinements as the dopeyness persists, and refinements cannot just
tell the engine what to do, no, that is not powerful, we have to add a
new guiding influence which indirectly causes the engine to produce the
right answer, so as to preserve the grail of a system figuring things
out for itself -- because it is so powerful!
Ring a bell?
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Pascal Costanza wrote:
>
>> Kenny Tilton wrote:
>>
>>>
>>>
>>> Pascal Costanza wrote:
>>>
>>>> Wouldn't call/cc have considerably reduced the complexity of
>>>> Screamer's implementation? Or am I missing something?
>>>
>>>
>>>
>>>
>>> The punch line may be that constraint logic programming was a
>>> terrible idea.
>>
>>
>>
>> Why is that?
>
>
> The premise was Free Lunch. There is no free lunch. They wanted to have
> the engine figure things out for them based on partial information,
> including even which things to figure out. Didn't scale. Computers are
> dumb, In the end, you still have to tell them everything. The engines
> started figuring wrong. Now you have an engine you want to run
> autonomously figuring things out, but you are adding bells and whistles
> by which to steer it away from dumb results. Almost works, then it
> figures wrong again. I know! Walkabout strengths! (actul name for a
> refinement aimed at getting the engines to stop being so dopey. More and
> more refinements as the dopeyness persists, and refinements cannot just
> tell the engine what to do, no, that is not powerful, we have to add a
> new guiding influence which indirectly causes the engine to produce the
> right answer, so as to preserve the grail of a system figuring things
> out for itself -- because it is so powerful!
>
> Ring a bell?
OK, got it. ;)
Thanks,
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Jan Rychter wrote:
> Kenny Tilton wrote:
>
>>Pascal Costanza wrote:
>>
>>>Wouldn't call/cc have considerably reduced the complexity of
>>>Screamer's implementation? Or am I missing something?
>>
>>The punch line may be that constraint logic programming was a
>>terrible idea.
>
>
> I don't necessarily agree with Kenny here on the uselessness of CLP,
Not useless, just too damn hard to program. I do not think the field is
dead, and even if it were, Lisp has proven once and for all there is
life after death.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Joe Marshall
Subject: Re: Why is Screamer not a good example for the inclusion of call/cc?
Date:
Message-ID: <u151vdeu.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Costanza wrote:
>> Wouldn't call/cc have considerably reduced the complexity of
>> Screamer's implementation? Or am I missing something?
>
> The punch line may be that constraint logic programming was a terrible
> idea. When the desperate Search for A Use (Any Use!) for a neat hack
> produces nothing but a Godawful Programming Technique, it could be a
> Bad Sign.
I disagree. Constraint logic programming is a great technique for
solving constraint logic problems.
Pascal Costanza wrote:
> I mean, it's clear that Screamer is implemented on top of Common Lisp,
> _without_ call/cc, but only by simulating call/cc via a transformation
> into CPS which is relatively complicated, and doesn't cover all of
> Common Lisp. Wouldn't call/cc have considerably reduced the complexity
> of Screamer's implementation? Or am I missing something?
I believe Siskind implemented Screamer without call/cc to make
it more efficient. An whole program analysis determines which
parts that need CPS'ing.
<http://citeseer.nj.nec.com/siskind93screamer.html>
--
Jens Axel S�gaard