[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: continuations in the real world?

Shriram Krishnamurthi <sk@cs.brown.edu> writes:

> I think *lots* of sites used to do this without being conscious of it.
> Arguably, any time you use a combination of
> - hidden fields
> - a generated reference to a different script

I once did this in ASP/VBScript.  A page that lists search results from
the company phone directory takes a "namelink" input that tells the page
where to jump to next.  That is, if namelink is "foo.asp?x=1&eid=" and
someone clicks on the name associated with employee #42, they will go to
"foo.asp?x=1&eid=42" from that page.  This search results page can then
be used in a helpdesk application to select the employee who initiated a

> you're using a form of CPS.

I agree.  In this example, namelink is a continuation.

However, I would say that programmers using this style are *very*
conscious of what they're doing, even if they don't know the CPS
terminology.  The continuation passing is very explicit, and you have to
think of exactly what variables you want to pass along, as well as the
security implications of entrusting their values to the client.

The nice thing about call/cc, and especially about your send/suspend
syntax based on call/cc, is that the programmer needn't be so very
conscious of the CPS happening.

> My very unscientific survey is that fewer sites do this now, relying
> on server-side state to inform the same script where it is.  This
> change is rather unfortunate.

It is unfortunate.  Perhaps it happens because it's hard for people to
think so explicitly about CPS.

> Maybe it's because I've made lots of reservations lately, but Orbitz
> is by far the worst offender.  You explore several options in parallel
> (say, hotels), and it always only remembers the last one you visited,
> no matter what the page you're on when you click a link says.

Yes, it's because you've made lots of reservations lately.  The
customers they lose will be their best ones.

What's ironic is that a lot of these sites using "session variables"
store them in a way that is no more persistent, distributed, or
load-balanced than server-side continuations would be.

<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/