web application framework

15 views
Skip to first unread message

Adrian Kubala

unread,
Nov 6, 2003, 6:47:51 PM11/6/03
to
I'm fixing to write a basic database web frontend for HR data. I'd really
like to do it in Scheme. I've been paid only to write PHP for the last
several years and so I've accumulated a very practical, lightweight
collection of libraries: sql manipulation, MVC forms, object-relational
layer, db abstraction, date libs, etc., and I can't justify rewriting all
this stuff, straightforward though it may be. There's also the fact that
I'm relatively new to Lisp and I'd rather start (and learn) from a
foundation created by experienced programmers than risk hacking together
an ugly, un-Lispy framework which I eventually have to throw away.

So I'm wondering if there are any existing open-source projects which can
get me partway there -- anything close to a framework for web
applications, but ideally something which goes so far as to fully automate
creating a basic interface for a given relational schema.

Common Lisp would be ok too -- I prefer Scheme because it seems to have
less awkward historical baggage and I like a functional (lots of HOFs)
style -- but any (statically scoped) Lisp is better than PHP.

The only examples of such things I know of are from Python: Webunit,
Twisted, etc.; and Java: Atris, EJB, ...

Noel Welsh

unread,
Nov 7, 2003, 4:01:22 AM11/7/03
to
Adrian Kubala <adr...@sixfingeredman.net> wrote in message news:<Pine.LNX.4.56.03...@sixfingeredman.net>...
> I'm fixing to write a basic database web frontend for HR data...
...

> I've accumulated a very practical, lightweight
> collection of libraries: sql manipulation, MVC forms, object-relational
> layer, db abstraction, date libs, etc.,
...

> So I'm wondering if there are any existing open-source projects which can
> get me partway there -- anything close to a framework for web
> applications, but ideally something which goes so far as to fully automate
> creating a basic interface for a given relational schema.
...

> The only examples of such things I know of are from Python: Webunit,
> Twisted, etc.; and Java: Atris, EJB, ...

As chief shill for the Schematics project
(http://schematics.sourceforge.net/) and "a shameless PLT booster"
(http://plt-scheme.org/) I'll answer as best I can in terms of what is
available for PLT Scheme. Where I don't give URLs the code can be
found via Schematics.

sql manipulation: We've got SchemeQL which currently runs on top of
an ODBC driver. We've talked about standardising a lower-level DB API
and have mostly working drivers for Postgres and MySQL, and to a
lesser extent Firebird, but haven't completed this yet.

db abstraction: see above

object-relational layer: nothing here

MVC forms: For the view component I really like WebIt!
(http://celtic.benderweb.net/webit/) It's like an XML transformation
system built in pure Scheme.

date libs: Combination of the PLT builtins and SRFI-19
(http://srfi.schemers.org/srfi-19/srfi-19.html), which is distributed
with PLT Scheme, have always done me.

webunit: This is a testing framework for web applications. There is a
prototype in Schematics CVS.

twisted: This is a server. The web server distributed with PLT Scheme
is very easy to use. If you don't know about continuations read
"Developing Interactive Web Programs" availabe from
http://www.ccs.neu.edu/scheme/pubs/ to see why continuation based web
servers are such a good thing.

HTH,
Noel

Marco Antoniotti

unread,
Nov 7, 2003, 10:28:55 AM11/7/03
to

Adrian Kubala wrote:

> I'm fixing to write a basic database web frontend for HR data. I'd really
> like to do it in Scheme.

...

> Common Lisp would be ok too -- I prefer Scheme because it seems to have
> less awkward historical baggage and I like a functional (lots of HOFs)
> style -- but any (statically scoped) Lisp is better than PHP.

... and how do you plan to do structs, objects and packages in Scheme?

Cheers
--
Marco

Ray Dillinger

unread,
Nov 7, 2003, 12:31:05 PM11/7/03
to

I cannot speak for the original poster, but the usual ways are
with SRFI-9, the TinyCLOS or Meroon libraries, and S2 or similar.

Bear

tal...@noshpam.lbl.government

unread,
Nov 7, 2003, 4:50:42 PM11/7/03
to Adrian Kubala
I'd recommend checking out the LAML project:

http://www.cs.auc.dk/~normark/laml/

From the page:

"The main idea in this work is to bring XML and HTML into the domain
of the Scheme programming language, and as such let the author and
programmer use the power of abstraction and programmed solutions when
he or she is doing web work. Web work includes web authoring in Scheme
(programmatic authoring) and web programming, included XML
transformation."

I'm fairly eager to start using it, along with JavaScript Scheme. :-)
As a refugee from Perl CGI.pm ( worthless! you can only do simple
stuff in the high-level notation, and 'hard' stuff, like nested
tables, get garbled ), and a current PHP web-scripter ( not elegant, &
not nested like XML/HTML, but at least it isn't a poser like CGI.pm ),
I'd be very happy to use Scheme instead.

Please let us know about your progress!

~Tomer


On Nov 6, 2003 at 5:47pm, Adrian Kubala wrote:

adrian >Date: Thu, 6 Nov 2003 17:47:51 -0600
adrian >From: Adrian Kubala <adr...@sixfingeredman.net>
adrian >Newsgroups: comp.lang.scheme, comp.lang.lisp
adrian >Subject: web application framework
adrian >
adrian >I'm fixing to write a basic database web frontend for HR data. I'd really
adrian >like to do it in Scheme. I've been paid only to write PHP for the last
adrian >several years and so I've accumulated a very practical, lightweight
adrian >collection of libraries: sql manipulation, MVC forms, object-relational
adrian >layer, db abstraction, date libs, etc., and I can't justify rewriting all
adrian >this stuff, straightforward though it may be. There's also the fact that
adrian >I'm relatively new to Lisp and I'd rather start (and learn) from a
adrian >foundation created by experienced programmers than risk hacking together
adrian >an ugly, un-Lispy framework which I eventually have to throw away.
adrian >
adrian >So I'm wondering if there are any existing open-source projects which can
adrian >get me partway there -- anything close to a framework for web
adrian >applications, but ideally something which goes so far as to fully automate
adrian >creating a basic interface for a given relational schema.
adrian >
adrian >Common Lisp would be ok too -- I prefer Scheme because it seems to have
adrian >less awkward historical baggage and I like a functional (lots of HOFs)
adrian >style -- but any (statically scoped) Lisp is better than PHP.
adrian >
adrian >The only examples of such things I know of are from Python: Webunit,
adrian >Twisted, etc.; and Java: Atris, EJB, ...
adrian >

Adrian Kubala

unread,
Nov 7, 2003, 5:39:20 PM11/7/03
to
On Fri, 7 Nov 2003 tal...@noshpam.lbl.government wrote:
> http://www.cs.auc.dk/~normark/laml/

> "The main idea in this work is to bring XML and HTML into the domain
> of the Scheme programming language [...]

I've heard of both WebIt! and LAML (I probably should have mentioned this
in the original post.) Those are indeed helpful, though on a different
level than I'm looking for. I don't have any interest in using XSL or
XQuery, so XML is out. I'd really like to work on the level of widgets and
forget that HTML has anything to do with it, and I imagine the
lowest-level layer where HTML gets generated can be format strings or a
few macros.

BTW, I mentioned Python's "Webunit" -- I actually meant to say "Webware"
and specifically Middlekit. You give it a simple, CSV-formatted schema
definition, run a preprocessor, and it generates an object-oriented layer
for your relational data with all the standard methods you could desire.
You extend the base objects to add interesting behaviours. (Oh, and it
keeps the SQL scheme up-to-date as well).

I hear this and the first things I think of are macros and CLOS
multimethods, to eliminate the preprocessing step and make extending the
base objects even more transparent. Of course my knowledge about both of
those fits in a thimble.

Adrian Kubala

unread,
Nov 7, 2003, 5:46:29 PM11/7/03
to

Yes. I don't want to start another Scheme vs Lisp thread -- I should
probably have refrained from that "awkward historical baggage". While R5RS
might not offer everything I would want, I believe several Scheme
implementations (PLT in particular) do. I am also quite excited about the
possibilities of continuation-based sessions.

Anthony Ventimiglia

unread,
Nov 7, 2003, 10:33:46 PM11/7/03
to
Adrian Kubala <adr...@sixfingeredman.net> writes:

Take a look at CLHP http://common-lisp.net/pjoject/clhp/

I've basically written it to be able to do what PHP does, only using
common lisp as opposed to PHP's C like langauge.

I'm calling it alpha, but I've been using it to develop web sites,
right now you have to use it through a cgi script (which can also be
Lisp), but I'm working on a native apachae module.

Check it out, it may suit your needs, if you like it, please feel free
to ask questions, and make recommendations.

--
(incf *yankees-world-series-losses*)

Marco Baringer

unread,
Nov 8, 2003, 4:04:01 AM11/8/03
to
Adrian Kubala <adr...@sixfingeredman.net> writes:

> I hear this and the first things I think of are macros and CLOS
> multimethods, to eliminate the preprocessing step and make extending the
> base objects even more transparent. Of course my knowledge about both of
> those fits in a thimble.

Have a look at CommonSQL:

http://www.lispworks.com/reference/lw43/LWUG/html/lwuser-167.htm

--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen

Adrian Kubala

unread,
Nov 8, 2003, 5:53:25 PM11/8/03
to
On Sat, 8 Nov 2003, Anthony Ventimiglia wrote:
> Adrian Kubala <adr...@sixfingeredman.net> writes:
> > I'm fixing to write a basic database web frontend for HR data. I'd really
> > like to do it in Scheme. I've been paid only to write PHP for the last
> > several years [...]

>
> Take a look at CLHP http://common-lisp.net/pjoject/clhp/
>
> I've basically written it to be able to do what PHP does, only using
> common lisp as opposed to PHP's C like langauge.

The fact that my alternative is PHP is misleading -- I only use PHP
because that's what I started on and that's where I can find part-time
work -- but in my opinion PHP is inferior to many other languages in every
respect except that I have the most experience in it. :)

I think that embedding other languages in HTML, ala JSP or PHP, is a good
idea in very few situations -- like when you have a large static site and
you just want to plug in some dynamic elements, or when you're coming to
programming knowing only HTML. (Which, I think, is why PHP is so popular.)

But the code-in-HTML model is no longer the one I use when even working in
PHP, and it's not the model I would want to use in scheme either.

Marco Antoniotti

unread,
Nov 8, 2003, 7:38:53 PM11/8/03
to

As usual, you have to boil it down to one or the other Scheme
implementations to do exactly what you can achieve (in a better and more
consistent way) with *any* CL implementation.

Your choice.

Cheers
--
Marco

Alexander Schmolck

unread,
Nov 8, 2003, 8:57:17 PM11/8/03
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Adrian Kubala wrote:
> > probably have refrained from that "awkward historical baggage". While R5RS
> > might not offer everything I would want, I believe several Scheme
> > implementations (PLT in particular) do. I am also quite excited about the
> > possibilities of continuation-based sessions.
>
> As usual, you have to boil it down to one or the other Scheme implementations
> to do exactly what you can achieve (in a better and more consistent way) with
> *any* CL implementation.

Since when does *any* CL implementation have continuations (in a better and
more consistent way than [PLT] scheme)?

Do you actually write these posts yourself or do you have some emacs-script
that automatically inserts some blanket claim about the superiority of CL for
each and every purpose whenever it finds a reference to a different
programming language in the message body of a newsgroup posting?

'as

Marc Spitzer

unread,
Nov 8, 2003, 11:07:21 PM11/8/03
to
Adrian Kubala <adr...@sixfingeredman.net> writes:

> But the code-in-HTML model is no longer the one I use when even working in
> PHP, and it's not the model I would want to use in scheme either.

have you looked at openacs(openacs.org)? Here is a link about how they
do it: http://openacs.org/doc/templates.html, it is a nice system.

marc

Kenny Tilton

unread,
Nov 9, 2003, 1:13:36 PM11/9/03
to

And they're off! Well, just as well, because this time I think we can
really settle the Scheme vs. Lisp thing once and for all. Especially if
we start making sarcastic, ad homineum attacks about auto-responders.

The more blanket claims the better, for my money, but in this case I
think you were the auto-responder. All he said was "to do exactly what
you can achieve", not "use continuations". Or is that what you are
trying to achieve, using continuations?

Yes, I think so. Continuations are a solution looking for a problem. The
mistake is thinking that the call stack is a smart place for long-lived
state. That's silly on the face of it. Continuations are a classic
geek-hack, creating insane technical difficulties for an apparently
clever solution to a problem with a much simpler, boring, direct
solution that just happens to fit the problem better.

Quick, more gasoline!

kenny

--
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application

Marco Baringer

unread,
Nov 9, 2003, 1:31:13 PM11/9/03
to
Kenny Tilton <kti...@nyc.rr.com> writes:

they were talking abouts web apps, in the context of web apps do you
really think that modelling user interaction via continuations is


"creating insane technical difficulties for an apparently clever
solution to a problem with a much simpler, boring, direct solution

that just happens to fit the problem better."?

If I took you seriously when you weren't being serious then just
ignore me. If there was some truth to what you said I'd be interested
in why you think so.

Pascal Costanza

unread,
Nov 9, 2003, 1:39:30 PM11/9/03
to
Kenny Tilton wrote:

> Yes, I think so. Continuations are a solution looking for a problem. The
> mistake is thinking that the call stack is a smart place for long-lived
> state. That's silly on the face of it. Continuations are a classic
> geek-hack, creating insane technical difficulties for an apparently
> clever solution to a problem with a much simpler, boring, direct
> solution that just happens to fit the problem better.

I think that continuations are currently becoming more important because
they really make sense in the context of web applications. Common Lisp
vendors should start to think about adding them IMHO.


Pascal

Kenny Tilton

unread,
Nov 9, 2003, 1:47:10 PM11/9/03
to

Pascal Costanza wrote:

Wrong. Yes, there are cases (Web or no) where one needs long-lived
state, no the stack is not where to keep it.

Damn, we forgot to cross-post to clscheme!

And to think I was going to work this weekend on getting Cello the
portable CL gui running under the newest Freeglut and some new opengl
text/font libs. What a waste /that/ would have been when I can be here
debating continuations!

<sigh>

Ironically, I ran into a problem with what I call dataflow interference
with Cells, for which continuations seemed like the perfect solution.
But it occurred to me that I am also looking at a cool dataflow
enhancement which kills the idea of using the call-stack anyway -- I
need to implement a "dataflow stack" somehow. And once I make that
enhancement, presto! the role for call-stack continuations evaporates.

And that is a Message From God(tm).

Jens Axel Søgaard

unread,
Nov 9, 2003, 1:57:49 PM11/9/03
to
Kenny Tilton wrote:

> Wrong. Yes, there are cases (Web or no) where one needs long-lived
> state, no the stack is not where to keep it.

Does it help, if one can rely on the OS to swap out the unused
stack part.

--
Jens Axel Søgaard

Kenny Tilton

unread,
Nov 9, 2003, 2:05:22 PM11/9/03
to

Marco Baringer wrote:

> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> they were talking abouts web apps, in the context of web apps do you
> really think that modelling user interaction via continuations is
> "creating insane technical difficulties for an apparently clever
> solution to a problem with a much simpler, boring, direct solution
> that just happens to fit the problem better."?

yes. I have done a lot of GUI programming where my app is effectively
one big callback fed events by the OS. I can manage state arising from
unpredictable user interaction between callbacks without a problem.
continuations, RIP.

it's a fine line between clever and stupid (Spinal Tap). clever in
programming, as a rule, /means/ stupid. just find someplace to keep the
state! always address The Real Problem(tm). the real problem is knowing
where one left off, not that one does not really want to execute RTS.

now it so happens that not returning preserves state, but that is how
kluges are born. using something for an incidental quality when solving
the problem directly is really not that hard and whose solution does not
create new dificulties.

kenny

ps. you were right both times. my post was facetious, but the ideas
expressed were not.

Kenny Tilton

unread,
Nov 9, 2003, 2:17:35 PM11/9/03
to

Kenny Tilton wrote:

>
>
> Marco Baringer wrote:
>
>> Kenny Tilton <kti...@nyc.rr.com> writes:
>>
>> they were talking abouts web apps, in the context of web apps do you
>> really think that modelling user interaction via continuations is
>> "creating insane technical difficulties for an apparently clever
>> solution to a problem with a much simpler, boring, direct solution
>> that just happens to fit the problem better."?
>
>
> yes.

btw, the classic example seems to be someone at a web page ending up
buying the wrong thing. ie, they are looking at tickets to NYC
(yeahhh!), they end up with tickets to Boston (booo!!).

are Scheme continuations the only way to prevent that? well, obviously
not. so we are talking about how ugly are the different solutions?

kenny

Vladimir S.

unread,
Nov 9, 2003, 2:54:52 PM11/9/03
to

What webserver are you using? If it's Apache, try Marc Battyani's
mod_lisp and Kevin Rosenberg's associated cl-modlisp. If you're
flexible in this respect, I recommend Portable Allegroserve (really
fast, good session and web app support, neat publishing/access control
system) or Daniel Barlow's Araneida (similar features to
Allegroserve), or CL-HTTP. For database mangling, try uncommonSQL
(which also includes CLOS to relational DB mappings). You have a lot
of options when it comes to dates. The functions that come with
Allegroserve are enough for me, but there's also net-telent-date and
the date utilities in the CLOCC libraries. decode-universal-time in CL
makes it pretty easy to handle dates yourself (particularly since
support for (non-integral) time zones is already there).

When it comes to "fully automate creating a basic interface for a
given relational schema," I'd have to apologize though - no one seems
to be working on a "write my web app for me" tool. :)

Vladimir Sedach

PS - I suggest you reconsider your stance on dynamic scope. It's far
more useful than most people imply.

Marc Battyani

unread,
Nov 9, 2003, 3:08:57 PM11/9/03
to

"Pascal Costanza" <cost...@web.de> wrote

> I think that continuations are currently becoming more important because
> they really make sense in the context of web applications. Common Lisp
> vendors should start to think about adding them IMHO.

I really disagree with this.
First there is a really great diversity of web applications. There is
absolutely nothing in common between simple web applications (like
e-Commerce) and really complex ones. I think continuations can be a
simplification for the simple ones but IMO they don't have real advantages
for complex cases. (if they can handle them...)

Marc


Pascal Costanza

unread,
Nov 9, 2003, 3:09:09 PM11/9/03
to
Kenny Tilton wrote:

>
>
> Pascal Costanza wrote:
>
>> Kenny Tilton wrote:
>>
>>> Yes, I think so. Continuations are a solution looking for a problem.
>>> The mistake is thinking that the call stack is a smart place for
>>> long-lived state. That's silly on the face of it. Continuations are a
>>> classic geek-hack, creating insane technical difficulties for an
>>> apparently clever solution to a problem with a much simpler, boring,
>>> direct solution that just happens to fit the problem better.
>>
>>
>>
>> I think that continuations are currently becoming more important
>> because they really make sense in the context of web applications.
>> Common Lisp vendors should start to think about adding them IMHO.
>
>
> Wrong. Yes, there are cases (Web or no) where one needs long-lived
> state, no the stack is not where to keep it.

Two responses:

a) I appreciate that most of the time, Common Lisp doesn't tell me
"that's not the way how you should do things". To the contrary, the
strength of Common Lisp is that it adapts to each and everybody's
programming style "in 99% of all cases". It doesn't do so in the case of
continuations, and that's objectively a disadvantage because it renders
certain programming styles inconvenient. Who are you, or who is anybody,
to judge whether continuations are appropriate for a particular
application or not?

Especially when there already exist obviously workable proposals how to
integrate them, for example with UNWIND-PROTECT? cf.
http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations.html

b) Here are some link collection that point to uses of continuations in
web servers:

+ http://home.comcast.net/~bc19191/2003_08_24_bill-clementson_archive.html

+ http://radio.weblogs.com/0102385/2003/08/30.html

+ http://radio.weblogs.com/0102385/2003/10/08.html

BTW, Screamer is another library that would benefit from built-in
continuations.


> Ironically, I ran into a problem with what I call dataflow interference
> with Cells, for which continuations seemed like the perfect solution.
> But it occurred to me that I am also looking at a cool dataflow
> enhancement which kills the idea of using the call-stack anyway -- I
> need to implement a "dataflow stack" somehow. And once I make that
> enhancement, presto! the role for call-stack continuations evaporates.
>
> And that is a Message From God(tm).

To me, such arguments just sound like bad excuses for a particular
feature not being part of a language. Paul Graham gives similar
arguments for not having OOP in Arc, Smalltalkers and Haskellers give
similar arguments for not having macros in their languages, and Java
fans give similar arguments for not having HOFs in their languages.

Yes, everything can be implemented with "simpler" language features. But
IMHO that's not the gist of high-level programming languages, at least
not in the Lisp world.


Pascal

Pascal Costanza

unread,
Nov 9, 2003, 3:11:34 PM11/9/03
to
Marc Battyani wrote:

Why do you think so? What is the downside of continuations for complex
web applications?


Pascal

Arthur Lemmens

unread,
Nov 9, 2003, 4:29:10 PM11/9/03
to
Pascal Costanza <cost...@web.de> wrote:

> a) I appreciate that most of the time, Common Lisp doesn't
> tell me "that's not the way how you should do things". To the
> contrary, the strength of Common Lisp is that it adapts to each
> and everybody's programming style "in 99% of all cases". It doesn't
> do so in the case of continuations, and that's objectively a
> disadvantage because it renders certain programming styles
> inconvenient.

I totally agree with this. Continuations are the only thing from Scheme
that I would really like to see in Common Lisp. Fortunately, in Common
Lisp we don't need continuations to implement stuff like condition
handling or multiprocessing. But they do make it a lot easier to use a
non-deterministic programming style when you want to.

Lispers saying "I don't need any continuations, because I can do everything
I want some other way" remind me a lot of the python/functional programmers
saying they don't need macros. Of course they don't really _need_ them.
But they do miss part of the fun (and the power) without them.

Yes, I read those (and a couple of articles by Krishnamurti and Felleisen
as well). The trouble with Web programming is that you lose all state after
each interaction with the user, so you're forced to deal with capturing
relevant parts of the state in a way that's not necessary with classical GUI
programming. But it's pretty easy to implement a mechanism that allows you
to use something very similar to the callbacks that you'd use in 'normal'
GUI programming. You only need closures for that, not full continuations.

The only GUI example I can think of that would be a lot harder to solve
without continuations is the bookmarking example in "Advanced Control
Flows for Flexible Graphical User Interfaces" by Graunke and Krishnamurti.
But for that kind of bookmarking, even Scheme-style continuations aren't
enough. Those continuations must be serializable as well, and that's
something that even Scheme doesn't have (at least it didn't the last time
I took a serious look at it).

Arthur Lemmens

Shriram Krishnamurthi

unread,
Nov 9, 2003, 4:21:14 PM11/9/03
to
Vladimir S. <last-name-first-...@cpsc.ucalgary.ca> writes:

> When it comes to "fully automate creating a basic interface for a
> given relational schema," I'd have to apologize though - no one seems
> to be working on a "write my web app for me" tool. :)

One could easily imagine that "fully automate..." means, given a
database schema, generate a simple set of forms that captures and
prints the corresponding information. This would let you get your
application running quickly, then spend time on improving the
interface.

Indeed, given a schema there is no reason why one couldn't
automatically generate a simple set of forms. It doesn't seem like a
silly request, and certainly not "write my web app for me". There are
Web application frameworks that will do this, just not any I know of
for Lisp/Scheme.

Shriram

Daniel Barlow

unread,
Nov 9, 2003, 3:42:38 PM11/9/03
to
Jens Axel Søgaard <use...@jasoegaard.dk> writes:

> Does it help, if one can rely on the OS to swap out the unused
> stack part.

It might, if you can also share that stack between all the web-serving
machines in your backend cluster so that user sessions can be migrated
to a second machine when the first goes down or is overloaded.


-dan

--

http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro

David Golden

unread,
Nov 9, 2003, 5:25:42 PM11/9/03
to
Pascal Costanza wrote:

>
> I think that continuations are currently becoming more important because
> they really make sense in the context of web applications. Common Lisp
> vendors should start to think about adding them IMHO.
>
>
> Pascal

I'm unconvinced that there's much benefit to them for web applications (when
the lawyers descend, you may be thankful you've taken a very "data"
approach instead and learned to love RDBMS), there are of course situations
where continuations might be nice.

However, naive use of the basic scheme continuation could, I feel, hurt you
in web apps. Web servers cannot trust the client to send back anything at
all, let alone sane data. If your web app is sufficiently complex to have
to deal with external resources (since many web apps are frontends to, or
at least have to deal with, horrible legacy systems in businesses, that's a
lot of them), you'll start to yearn for unwind-protect-like functionality.
This is probably a place where the points made by Kent Pitman [1] re
unwind-protect vs. continuations could become very relevant...

While Dorai Sitaram has apparently showed how to build the required fancier
continuations out of the basic scheme one [2], I don't know if all these
continuations-rock-for-web-apps people have read and thought about the
issues involved. I know I haven't thought through ramifications
rigorously, the above is vague feeling.

[1] http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations.html
[2] http://www.ccs.neu.edu/home/dorai/uwcallcc/uwcallcc.html

Kaz Kylheku

unread,
Nov 9, 2003, 5:58:48 PM11/9/03
to
Marco Baringer <m...@bese.it> wrote in message news:<m2k769b...@bese.it>...

> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> they were talking abouts web apps, in the context of web apps do you
> really think that modelling user interaction via continuations is
> "creating insane technical difficulties for an apparently clever
> solution to a problem with a much simpler, boring, direct solution
> that just happens to fit the problem better."?

I think you can use continuations for web apps if your continuations
are so powerful that they can snapshot the entire state of the system,
including its database stores and so forth. Moreover, they should be
able to survive reboots, and be capable of migration from server to
server, so the user can start a multi-step transaction on a socket
connected to one server, and then midway through, the connection can
be moved to a different server which can pick up the transaction in
the right place.

Kenny Tilton

unread,
Nov 9, 2003, 6:32:16 PM11/9/03
to

Gee, if it's that easy, maybe I should look at continuations again.
Anything would be better than using a database to store long-lived state.

btw, this same discussion is now going on in three different threads. Is
it possible three different servers picked up the same continuation?

:)

Pascal Costanza

unread,
Nov 9, 2003, 6:53:03 PM11/9/03
to
David Golden wrote:

> I'm unconvinced that there's much benefit to them for web applications (when
> the lawyers descend, you may be thankful you've taken a very "data"
> approach instead and learned to love RDBMS), there are of course situations
> where continuations might be nice.
>
> However, naive use of the basic scheme continuation could, I feel, hurt you
> in web apps. Web servers cannot trust the client to send back anything at
> all, let alone sane data. If your web app is sufficiently complex to have
> to deal with external resources (since many web apps are frontends to, or
> at least have to deal with, horrible legacy systems in businesses, that's a
> lot of them), you'll start to yearn for unwind-protect-like functionality.
> This is probably a place where the points made by Kent Pitman [1] re
> unwind-protect vs. continuations could become very relevant...
>
> While Dorai Sitaram has apparently showed how to build the required fancier
> continuations out of the basic scheme one [2], I don't know if all these
> continuations-rock-for-web-apps people have read and thought about the
> issues involved. I know I haven't thought through ramifications
> rigorously, the above is vague feeling.

Aren't these things also hard to solve _without_ continuations? Even if
continuations helped to reduce the complexity only partially this would
be an improvement.

I have to admit that I don't have any experience with continuations and
web applications, but what I have read about that combination sounds
convincing to me. It probably takes some experimentation and some more
serious experience to sort out if and how continuations can really help
in the long run. It would be great if Common Lisp could be the platform
to carry out these experiments so that one has all the other advantages
of Common Lisp as well.

(When I read about stuff that sounds interesting, my usual approach is
to hack some examples together to see how things work out for me. In the
case of continuations, I can't do that with my favorite language in a
straightforward way, and that's a pity.)

Just my 0.02€


Pascal

Marco Baringer

unread,
Nov 9, 2003, 7:37:28 PM11/9/03
to
Pascal Costanza <cost...@web.de> writes:

> (When I read about stuff that sounds interesting, my usual approach is
> to hack some examples together to see how things work out for me. In
> the case of continuations, I can't do that with my favorite language
> in a straightforward way, and that's a pity.)

plug:

there is a more or less complete (it does everything _i_ need it do
do) CPS transformer at:

ftp://common-lisp.net/project/bese/arnesi_latest.tar.gz

I made the decision to support just enough continuation like
functionality to be able write the web app logic as a linear code
sequence, nothing more, this decision is shows in the CPS transformer.

Marco Baringer

unread,
Nov 9, 2003, 7:46:50 PM11/9/03
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> are Scheme continuations the only way to prevent that? well, obviously
> not. so we are talking about how ugly are the different solutions?

continuations are a great way to manage the state of the usr
interface. this is different from the state of the application
itself. I can reasnably keep the values of a multi-page form on the
stack until i've submitted the form, then they go to the db, and
that's that.

none of this touches on the real advantage of continuations, which
actually has nothing to do with how the app works. With continuations
I can _write_ my web app as a sequence of function calls, this is the
real advantage. What happens after a certain click is expressed
cleanly and clearly in the app's code, this actually results in
people writing far more advanced user interfaces over http.

i agree that there are other ways to do this however i believe that:

being able to model the user's interaction with the server as a series
of function calls, loops and conditionals is a Good Thing. Being able
have the state of the user interface be exactly what the user sees is
a Good Thing.

Pascal Costanza

unread,
Nov 9, 2003, 7:56:04 PM11/9/03
to
Marco Baringer wrote:

> Pascal Costanza <cost...@web.de> writes:
>
>
>>(When I read about stuff that sounds interesting, my usual approach is
>>to hack some examples together to see how things work out for me. In
>>the case of continuations, I can't do that with my favorite language
>>in a straightforward way, and that's a pity.)
>
>
> plug:
>
> there is a more or less complete (it does everything _i_ need it do
> do) CPS transformer at:
>
> ftp://common-lisp.net/project/bese/arnesi_latest.tar.gz
>
> I made the decision to support just enough continuation like
> functionality to be able write the web app logic as a linear code
> sequence, nothing more, this decision is shows in the CPS transformer.

Cool, thanks!


Pascal

William D Clinger

unread,
Nov 9, 2003, 8:38:14 PM11/9/03
to
Kenny Tilton wrote:
> yes. I have done a lot of GUI programming where my app is effectively
> one big callback fed events by the OS. I can manage state arising from
> unpredictable user interaction between callbacks without a problem.
> continuations, RIP.

Most GUI programming is quite different from web apps, where the
usual protocol forces you to simulate continuation-passing style,
regardless of whether you are aware of what that style is called
or of its history. Whether Scheme's continuations genuinely help
is moot (i.e. debatable), but to deny continuations are relevant
to web apps is just ignorant.

Will

Ray Dillinger

unread,
Nov 9, 2003, 8:44:10 PM11/9/03
to
Kenny Tilton wrote:
> Alexander Schmolck wrote:
>> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>>> Adian Kubala wrote:

>>>> I am also quite excited about the
>>>>possibilities of continuation-based sessions.

>>>As usual, you have to boil it down to one or the other Scheme implementations
>>>to do exactly what you can achieve (in a better and more consistent way) with
>>>*any* CL implementation.

>> Since when does *any* CL implementation have continuations (in a better and
>> more consistent way than [PLT] scheme)?

> The more blanket claims the better, for my money, but in this case I


> think you were the auto-responder. All he said was "to do exactly what
> you can achieve", not "use continuations". Or is that what you are
> trying to achieve, using continuations?

According to what Adrian Kubala wrote, he intends to use
continuation-based sessions. I think scheme is a logical
choice, as a lisp that has maximally robust continuations.

PLT's implementation of continuations is also quite good;
it will be no more expensive than managing any heap-based
datastructure, so I think his choice of implementations is
fine.

And I have to believe that your response here is a deliberate
misdirection; the OP was talking about using continuations.
There may be other ways to do it, sure; but he's using a lisp,
and he wants to do it with continuations, so the lisp he's
using is scheme. Doesn't this go right back to what someone
was saying here a few days ago about "any way you want to do
it, you can do it that way in Lisp"...?

> Continuations are a solution looking for a problem. The
> mistake is thinking that the call stack is a smart place for long-lived
> state.

The stack is a data structure, nothing more or less. Robust
continuations simply use it as one.

> That's silly on the face of it. Continuations are a classic
> geek-hack, creating insane technical difficulties for an apparently
> clever solution to a problem with a much simpler, boring, direct
> solution that just happens to fit the problem better.

Remember that this is how most of the world feels about Common
Lisp macros, too. They require you to bend your brain in
unaccustomed directions, so they seem difficult. Get used to
working with them and you wonder how you ever survived without
them.

I'm a Lisp user. Sometimes Common Lisp, Sometimes Scheme. I
probably wouldn't have ever started on Common Lisp if I hadn't
learned Scheme first -- scheme is, probably, *THE* single easiest
way to learn to think in lispy patterns.

I still prefer scheme where it's applicable, because I really
like the elegance and simplicity of it. I use Common Lisp when
I'm driven to it, usually for its libraries, raw performance,
and more consistent mathematical behavior.

Now, my advice to Common Lispniks who feel that robust
continuations are useless or a "solution in search of a problem"
is to remember how they felt about CL macros before they learned
what CL macros are good for. I'm thinking it's likely to be
about the same.

'Cause Ladies and Gents, it's all good. Scheme and CL are
different aspects of the platonic ideal which is Lisp, and
each has its excellences. I believe that Lisp itself is the
last programming language -- the one that will endure forever.
But neither the current form of Scheme nor the current form
of CL does everything that a Lisp can do, and more Lisps
will come along in time. And each of them will have its own
excellences too.

Bear

Kenny Tilton

unread,
Nov 9, 2003, 8:48:42 PM11/9/03
to

I don't understand. The desired functionality was achieved without
support from the Common Lisp compiler? /That/ is why Cl is your favorite
language. :)

You know, programming is hard, so programmers are easily seduced by
apparent quick fixes, such as language feautures which seem to map onto
functional requirements. And programmers are smart, so when those quick
fixes turn out to be problematic -- when the mapping from language
feature to functional requirement proves to be just a hair inside -- no
problem! we stay up all night and hack around the problems, because that
way we can keep our quick fix. And when it turns out that some of the
things we hoped to solve with our quick fix don't yield to it, Hey, no
problem! We still covered /some/ of the problems with the quick fix we
have to stay up all night with again tonight because -- surprise,
surprise -- the quick fix has another issue we are smart enough to hack
around. Sure, we now have to find some Other Way to solve the cases not
covered by the Quick Fix, and that approach of course would work for the
simple cases the language feature mapped onto, but we won't use that
Other Way for all the cases, because the Quick Fix we will now be
maintaining in addition to the Other Way is, uh...well...you know, so,
um, quick.

Vladimir S.

unread,
Nov 9, 2003, 9:24:53 PM11/9/03
to
Shriram Krishnamurthi <s...@cs.brown.edu> writes:

> One could easily imagine that "fully automate..." means, given a
> database schema, generate a simple set of forms that captures and
> prints the corresponding information. This would let you get your
> application running quickly, then spend time on improving the
> interface.

This assumes that most of the application logic is in "a simple set of
forms." While this is exactly what Adrian wants, I don't think it
applies to most web apps written in Lisp!

> Indeed, given a schema there is no reason why one couldn't
> automatically generate a simple set of forms. It doesn't seem like a
> silly request, and certainly not "write my web app for me". There are
> Web application frameworks that will do this, just not any I know of
> for Lisp/Scheme.

The main problem (at least in the case of CL) would be the
proliferation of (quite useful) web tools. With a little macrology,
it's not difficult to abstract over the different choices of
generating html, etc., but it would be _extremely_
tedious. Considering the restricted usefulness of this tool, it's
really no wonder there's nothing available for Lisp. I think it would
probably be faster (and certainly more instructive on good Lisp
style!) for anyone interested in such a "feature" to roll their own
macros (if the schema is indeed as simple as you suppose this should
be trivial)^.

Vladimir

PS - In my original post I totally forgot to mention where to find all
the stuff I was talking about: http://www.cliki.net/index (which, btw,
is powered by Araneida).

^ - They should then maybe consider putting their toil into a code
repository, so we could indeed claim that we had a "fully automated
system for creating web interfaces based on database schema."

David Golden

unread,
Nov 9, 2003, 10:59:16 PM11/9/03
to
Pascal Costanza wrote:

> Even if continuations helped to reduce the complexity only partially this
> would be an improvement.
>

But if you're throwing away the reduction in complexity that other things
bring because you're using naive scheme continuations that stop certain CL
constructs working properly, then I'm no sure it's a net win. Hence my
link to the unwind-protect thing.

And on a different note, what about timeouts? Won't you need them?
I think you'll thus end up needing some sort of wacky "timeout-ing
continuation" too? And ideally, assuming the first unwind-protect issue
were solved, these would be potentially capable of being wrapped in
unwind-protects so that when they time out, relevant unwind-protects can
fire as if the continuation inside the unwind-protect were called but the
continued program took an immediate non-local exit to the heart?

Or not? Would that be wrong? Have I only succeeded in totally confusing
myself?

Argh. It's to the point now I'd need to actually write some practical
examples myself to get my head around it. And that would mean swapping back
in my never-very-good Scheme into my tiny brain, and probably understanding
Dorai Sitaram's paper.

So not tonight (actually this morning, it's now 04:00 here and I'm probably
already asleep and this is just a horrible dream.)


Chris Double

unread,
Nov 10, 2003, 12:26:34 AM11/10/03
to
Arthur Lemmens <alem...@xs4all.nl> writes:

> But for that kind of bookmarking, even Scheme-style continuations
> aren't enough. Those continuations must be serializable as well, and
> that's something that even Scheme doesn't have (at least it didn't
> the last time I took a serious look at it).

Sisc Scheme [1] has serializable continuations. You can load the
serialized continuation on a different machine and it works fine. I
use this in a continuation based web server framework and it works
very well.

[1] http://sisc.sourceforge.net

Chris.
--
http://radio.weblogs.com/0102385
http://www.double.co.nz/cl

Pascal Costanza

unread,
Nov 10, 2003, 4:13:24 AM11/10/03
to
Kenny Tilton wrote:

>
>
> Pascal Costanza wrote:
>
>> Marco Baringer wrote:
>>
>>> Pascal Costanza <cost...@web.de> writes:
>>>
>>>
>>>> (When I read about stuff that sounds interesting, my usual approach is
>>>> to hack some examples together to see how things work out for me. In
>>>> the case of continuations, I can't do that with my favorite language
>>>> in a straightforward way, and that's a pity.)
>>>
>>>
>>>
>>>
>>> plug:
>>>
>>> there is a more or less complete (it does everything _i_ need it do
>>> do) CPS transformer at:
>>>
>>> ftp://common-lisp.net/project/bese/arnesi_latest.tar.gz
>>>
>>> I made the decision to support just enough continuation like
>>> functionality to be able write the web app logic as a linear code
>>> sequence, nothing more, this decision is shows in the CPS transformer.
>>
>>
>>
>> Cool, thanks!
>
>
> I don't understand. The desired functionality was achieved without
> support from the Common Lisp compiler? /That/ is why Cl is your favorite
> language. :)

It's still a restricted call/cc - see the documentation for things taht
don't work well.

It seems to be better than what I have seen yet, that's why I think it's
cool. But look at the amount of code Marco needed to implement it. And
it's still clear that you can't have a complete solution.


Pascal

Pascal Costanza

unread,
Nov 10, 2003, 4:15:44 AM11/10/03
to
David Golden wrote:

> Pascal Costanza wrote:
>
>
>>Even if continuations helped to reduce the complexity only partially this
>> would be an improvement.
>>
>
>
> But if you're throwing away the reduction in complexity that other things
> bring because you're using naive scheme continuations that stop certain CL
> constructs working properly, then I'm no sure it's a net win. Hence my
> link to the unwind-protect thing.
>
> And on a different note, what about timeouts? Won't you need them?
> I think you'll thus end up needing some sort of wacky "timeout-ing
> continuation" too? And ideally, assuming the first unwind-protect issue
> were solved, these would be potentially capable of being wrapped in
> unwind-protects so that when they time out, relevant unwind-protects can
> fire as if the continuation inside the unwind-protect were called but the
> continued program took an immediate non-local exit to the heart?

Hmm, I am just brainstorming, but what about a leasing protocol?


Pascal

Anthony Ventimiglia

unread,
Nov 10, 2003, 8:31:33 AM11/10/03
to
Adrian Kubala <adr...@sixfingeredman.net> writes:

> The fact that my alternative is PHP is misleading -- I only use PHP
> because that's what I started on and that's where I can find part-time
> work -- but in my opinion PHP is inferior to many other languages in every
> respect except that I have the most experience in it. :)

The reason I use PHP is that it is so convenient. The reason I wrote
CLHP is that I'd rather be using Lisp.

>
> I think that embedding other languages in HTML, ala JSP or PHP, is a good
> idea in very few situations -- like when you have a large static site and
> you just want to plug in some dynamic elements, or when you're coming to
> programming knowing only HTML. (Which, I think, is why PHP is so popular.)
>
> But the code-in-HTML model is no longer the one I use when even working in
> PHP, and it's not the model I would want to use in scheme either.

So you recognize that PHP allows you to use different approaches to
coding, that's one of the nice things about it, you can drop in small
bits of code, or generate an entire site dynamically. My approach with
PHP is almost always the latter. Which is again, why I am no moving to
do it all in Lisp. Simply put, every time I'm working in PHP (which is
a source of income for me), I wish I could be doing it lisp, CLHP is
my solution. When I first started this, I saw that there were other
Lisp based web application solutions, they were all nice, but they
didn't have the convenience of PHP.

As for looking at PHP (or CLHP) as being code embedded in HTML, I do
not agree with that view. I look at them as XML processing
instructions, you can add PHP or CLHP to any valid XML document and it
will still be valid XML, part of the goals I have for CLHP is to allow
XML processors to execute Lisp code, which brings CLHP out of the
constriction of just being Hypertext based. This distinction may seem
trivial to you, but I consider it an important one.

--
(incf *yankees-world-series-losses*)

Noel Welsh

unread,
Nov 10, 2003, 9:29:41 AM11/10/03
to
Adrian Kubala <adr...@sixfingeredman.net> wrote in message news:<Pine.LNX.4.56.0...@sixfingeredman.net>...
> I've heard of both WebIt! and LAML (I probably should have mentioned this
> in the original post.) Those are indeed helpful, though on a different
> level than I'm looking for. I don't have any interest in using XSL or
> XQuery, so XML is out. I'd really like to work on the level of widgets and
> forget that HTML has anything to do with it, and I imagine the
> lowest-level layer where HTML gets generated can be format strings or a
> few macros.

WebIt! is that "lowest-level layer" (and a bit of the middle layer).
For example, it sounds like you want to write code like:

(define name-form
(form
(name "Foo")
(field (name "Name") (type 'text) (content "Enter your name
here"))
(button (name "Submit")))

That could be a valid WebIt! document and you'd then write a WebIt!
transformation to turn it into HTML. You could also write:

(define name-form
(form "Foo"
(field "Name" 'text "Enter your name here")
(button "Submit")))

and a few helper functions:

(define (field name type content)
(webit:field :name name :type type :content content))

would turn it into WebIt! structures.

And now for something completely different!

You could use SISC and write bindings for the Java toolkits that do
what you want. This is less work and has been done succesfully in
industry. See e.g. "Scheme in the Real World" at
http://www.lshift.net/news.280903lispconference.html (NB: I'm one of
the authors -- hardly unbiased!)

Noel

David Golden

unread,
Nov 10, 2003, 1:36:59 PM11/10/03
to
Pascal Costanza wrote:

>
> Hmm, I am just brainstorming, but what about a leasing protocol?
>
>

If you need locks to be held for the minimal time possible, that means you
need locks to release at lease timer expiry, not when the code discovers the
lease has expired on trying to call the continuation?

All in all, might be easier to think/model in terms of real concurrent
processes at that stage, and explicitly pass the state around between them
as data.

Though "timbebomb continuations" seem like an independently interesting
thing, particularly if one could catch the "explosion" and substitute in
another continuation on the fly or something.

Pascal Costanza

unread,
Nov 10, 2003, 1:40:23 PM11/10/03
to
David Golden wrote:

Hmm, I was thinking more of a broader scale here. For example, in a web
session, the continuations stored in, say, bookmarked webpages could
require to be visited every so often in order to be refreshed.


Pascal

Joe Marshall

unread,
Nov 10, 2003, 2:11:25 PM11/10/03
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Yes, there are cases (Web or no) where one needs long-lived state,
> no the stack is not where to keep it.

That's a circular argument. You shouldn't keep long-lived state on
the stack because the stack isn't long lived. If the stack were long
lived, though, there's no reason not to keep long-lived data there.

The real problem occurs when you accidentally rely on having
long-lived data on a short-lived stack. There's nothing stopping you
from doing that, and there's no easy way to tell when you are writing
the code. Reifying the stack is one way to get around this problem.

Joe Marshall

unread,
Nov 10, 2003, 2:13:32 PM11/10/03
to
Pascal Costanza <cost...@web.de> writes:


> What is the downside of continuations for complex web applications?

Storage. They have to live for a while. They are difficult to
migrate. They may be holding on to unnecessary resources.

Marco Baringer

unread,
Nov 10, 2003, 2:40:57 PM11/10/03
to
David Golden <david....@oceanfree.net> writes:

> However, naive use of the basic scheme continuation could, I feel, hurt you
> in web apps. Web servers cannot trust the client to send back anything at
> all, let alone sane data. If your web app is sufficiently complex to have

the client should send back a key which is tied to the data in the db,
the client should _not_ send a serialized continuation. the problem of
session hijacking still exists, and HTTPS is the only "real" solution
to this problem anyway, continuations or not.

> to deal with external resources (since many web apps are frontends to, or
> at least have to deal with, horrible legacy systems in businesses, that's a
> lot of them), you'll start to yearn for unwind-protect-like functionality.

web continuations (maybe i should stop calling them continuations and
find a new name for them) do not interfere with unwind-protect.

you couldn't wrap an unwind-protect around a response+subsequent
request without continuations and you can't do it with them either.

> This is probably a place where the points made by Kent Pitman [1] re
> unwind-protect vs. continuations could become very relevant...

then don't use them like that. "normal" continuations can be taken at
_any_ function call, web app continuations only apply between
requests. Continuations are not about writing all (or most) of you
code using continuations, they allow you to hide the fact that HTTP is
a request/response paradigm while most interactions are, basically,
decision trees. that's it. that's all they're good for. The DB code
remains the same, the interaction with external systems is just as
painful as before, the serever's haven't gotten an faster and the
clients haven't gotten any better, but at least I can hide the page
flow control logic and pretend it's just a bunch of function calls,
even when it isn't.

Marco Baringer

unread,
Nov 10, 2003, 3:38:36 PM11/10/03
to
Marco Baringer <m...@bese.it> writes:

> plug:
>
> there is a more or less complete (it does everything _i_ need it do
> do) CPS transformer at:
>
> ftp://common-lisp.net/project/bese/arnesi_latest.tar.gz

sorry, the above URL is wrong:

ftp://ftp.common-lisp.net/pub/project/bese/arnesi_latest.tar.gz

Adrian Kubala

unread,
Nov 10, 2003, 3:41:14 PM11/10/03
to
On Mon, 10 Nov 2003, Noel Welsh wrote:
> WebIt! is that "lowest-level layer" (and a bit of the middle layer).
> For example, it sounds like you want to write code like:
>
> (define name-form
> (form
> (name "Foo")
> (field (name "Name") (type 'text) (content "Enter your name here"))
> (button (name "Submit")))
>
> That could be a valid WebIt! document and you'd then write a WebIt!
> transformation to turn it into HTML. You could also write:

At this level I don't see what great advantage WebIt! provides over a
handful of format-string functions. And if I needed to write AST->AST
transformations, why not do it with macros? I will concede that maybe all
the macros and functions I'd write would end up re-implementing WebIt!, or
maybe there's some emergent benefits to the collective WebIt! system that
I don't see yet.

But since you asked I'd like to at least write code like this, which is
analagous to what I do in PHP (just less verbose):

;;;;;
(def-form name-form
(row-field-group
[field name
:label "Name"
:checker (lambda (v)
(if (= (string-length v) 0)
"~a must not be blank."))]
[button submit
:label "Submit"
:action (lambda (form context)
(context=>form context form)
(let ((model (new-name-model)))
(and (validate-form form context)
(form=>model form model)
(save-model model)
(add-form-message form "Success!"))))]))
(process-form name-form)
(render-form name-form)
;;;;;

But I'm hoping that I'll discover some completely new ways to do things.

> You could use SISC and write bindings for the Java toolkits that do
> what you want. This is less work and has been done succesfully in
> industry. See e.g. "Scheme in the Real World" at
> http://www.lshift.net/news.280903lispconference.html

That's a good idea I hadn't considered, thanks.

Adrian Kubala

unread,
Nov 10, 2003, 4:13:30 PM11/10/03
to
On Mon, 10 Nov 2003, Vladimir S. wrote:
> Shriram Krishnamurthi <s...@cs.brown.edu> writes:
> > One could easily imagine that "fully automate..." means, given a
> > database schema, generate a simple set of forms that captures and
> > prints the corresponding information.

Yes, this is indeed what I meant. With the additional restriction that
these forms should be flexible and modifyable enough to evolve into your
final, arbitrarily-complex web-app. And best of all would be if, even
after all these modifications, the forms still automatically reflected
changes to the original schema in reasonable ways. It's a tall order -- I
don't know of anything that does all this -- but even a part of it is
great.

> This assumes that most of the application logic is in "a simple set of
> forms."

I don't think it assumes that at all. It assumes that as much of the
application logic which can be automatically inferred from the data model,
should be. And that "a simple set of forms" is closer to your final goal
than nothing at all.

> The main problem (at least in the case of CL) would be the proliferation
> of (quite useful) web tools. With a little macrology, it's not difficult

> to abstract over the different choices of generating html [...]

To what purpose? HTML is HTML. I don't think the user of such a library
should need to care how it generates HTML at the lowest level.

> Considering the restricted usefulness of this tool, it's really no
> wonder there's nothing available for Lisp.

I don't know about that -- I think if my current employer had such a tool
it would improve programmer productivity by 15%. By that I mean that about
15% of what we do (and I think we're a pretty typical web-services shop)
amounts to generating PHP which does nothing but interface between the
user and the data model in a straightforward way.

If we didn't have libraries which already implemented parts of this
concept though, I would put that figure as high as 40%, so all-in-all it's
a pretty useful framework for at least one niche.

Will Hartung

unread,
Nov 10, 2003, 6:15:47 PM11/10/03
to
"Marc Spitzer" <mspi...@optonline.net> wrote in message
news:868ymqi...@bogomips.optonline.net...

> Adrian Kubala <adr...@sixfingeredman.net> writes:
>
> > But the code-in-HTML model is no longer the one I use when even working
in
> > PHP, and it's not the model I would want to use in scheme either.
>
> have you looked at openacs(openacs.org)? Here is a link about how they
> do it: http://openacs.org/doc/templates.html, it is a nice system.

This (at a 5 second glance) is different from what the "code-in-HTML" is.

If you limit the problem to simply "templating", then embedded code is
almost reasonable. The big problem is that most templating systems, by
necessity, are essentially complete systems and it is easy to cross the fine
line between using HTML templates, and writing logic within the HTML.

The problem stems from the fact that (a majority of) HTML authors live more
in the world of Graphic Design and VERY lightweight scripting and are not
programmers, whereas programmers are just the opposite (the infamous
"programmer art"). Of course there are those talented in both realms, but
they're in the minority.

When the scripting creeps into the HTML, all of the power of the modern
development flies out the window as little bits of script creep into the
final page. Notably abstraction.

Thus on large sites, you end up with Cut-n-paste Hell across pages as the
Web Page authors hack out solutions that ideally should be done deeper into
the system. Typically the Web Page authors don't realize this or simply
don't have access to make the changes directly.

Of course, these inevitably result in quick results, but your code base
rapidly gathers source code momentum that makes it very difficult to change
on a wide scale.

Templating I think is the best compromise, as it allows Web Page authors to
keep the dynamic bits to a very minimum. Layer some kind of "block" system
where the authors actually define specific sections of pages, and then have
another system to integrate these pieces together as a whole I think is even
better. This adds a bit of lightweight abstraction to the entire page, even
for basic pages which are simply one big block.

But for good or ill, I think that none of the hard decisions about the state
of the page belong, of all places, in the page itself. The page should be
just a skeleton linking bits defined elsewhere together. IMHO, YMMV, etc.

Regards,

Will Hartung
(wi...@msoft.com)


Shriram Krishnamurthi

unread,
Nov 10, 2003, 6:03:11 PM11/10/03
to
Adrian Kubala <adr...@sixfingeredman.net> writes:

> I don't know about that -- I think if my current employer had such a tool
> it would improve programmer productivity by 15%. By that I mean that about
> 15% of what we do (and I think we're a pretty typical web-services shop)
> amounts to generating PHP which does nothing but interface between the
> user and the data model in a straightforward way.

I think there's a better way to justify the need for such a thing
without even citing percentages. One of the things that makes
languages like Lisp such a win is the ability to prototype rapidly and
develop bottom-up. One key aspect to both is the ability to write
data with a minimum of overhead. In Lisp I can write

(list 'a 'b 'c)

We all know what it takes to write the corresponding datum in C.
Likewise Lisp can print

(a b c)

and we know what that means.

What Adrian is looking for would largely elevate this i/o convenience
to the Web. Who cares whether this persists into your final
application? It's clearly useful for prototyping and bottom-up
development.

Shriram

Will Hartung

unread,
Nov 10, 2003, 8:14:22 PM11/10/03
to

"Adrian Kubala" <adr...@sixfingeredman.net> wrote in message
news:Pine.LNX.4.56.03...@sixfingeredman.net...

> Yes, this is indeed what I meant. With the additional restriction that
> these forms should be flexible and modifyable enough to evolve into your
> final, arbitrarily-complex web-app. And best of all would be if, even
> after all these modifications, the forms still automatically reflected
> changes to the original schema in reasonable ways. It's a tall order -- I
> don't know of anything that does all this -- but even a part of it is
> great.

I have yet to see anything that works well in this regard in a long, long
time.

Most app/form generators that I've seen (albeit, most of them have been for
simple DB screens, not web pages) are utter crap.

They happily spit out Kbytes of boiler plate template code that is only a
fraction above cutting and pasting in terms of sophistication.

Almost none that I have seen provided any support for adjusting to the
schema changes, as most were simply boiler plate generators rather than
actually integrated into development process.

Part of this problem is simply that the result of both the generated result
and your custom modifications is the source code, it's difficult for most
generators to seperate your content from the generated content.

I used one system where the input to the system was the screen definition,
and an extensions file. The extensions file enumerated tagged bits within
the source code and the results were boiler plate created from the screen
definition file merged with the bits in the extension file. What made this
particularly useful was that the extensions file had the capability of
modifying arbitrary bits of the generated source. Using a mechanism much
like "within the after change in name field block, replace the block of text
delimited by these two regexps with ....".

This made development really pretty efficient because your code was pretty
much isolated from the screen changes and the database changes.

Today, you'd be motivated to not use this technique at all, and rather
simply define a CLOS method to replace the common hook. But, even that
doesn't give you the flexibility that this does simply because you can't
easily make just arbitrary changes to the final source code. The fix to that
is to simply be able to redefine any bit of code you need. (We did that in
this system by copying library code locally and changing it as necessary
confident that the system will our local version over the community version.
Made upgrades potentially difficuly, but you gotta do what you gotta do).

I thought about a similar system leveraging CL macros, but having database
dependent macros didn't sit right with me.

Today, I think a combination of a solid "boiler plate" class core that is
designed to be overloaded/pre-empted combined with reflection and a high
level definition file would be a pretty good solution. I suppose a three
tier model: [core class -> generated class -> your class] might work well as
well. Most of the boiler plate is in the generated class, and you specific
changes are in your own class that extends the generated one. With source
code to the core, you can steal its functionality if necessary for tweaking
and plop it in your application class. In theory you could use reflection to
replace the middle generated class, but I'm not sure if it would really give
you the flexibility that I've found I've needed in applications in the past.

Ideally there's no reason this couldn't be done with web forms.

However, I do not know of today any system that is both automated and
extensible and that actually leaves the process of coding the edges of the
application around a common core.

There are a bazillion screen builders that will pump out source code et al,
but very few that actually help abstract the "CRUD" cycle of the
application. All of the "VB" like systems that tie controls directly to the
SQL cursor are 99% of time too tightly bound to be useful beyond the most
basic of applications, and rarely provide the flexibility to put your code
in the "right places" without tossing the entire baby out with the
bathwater.

So, not only do I not offer any help, I don't offer any hope either! :-)

Regards,

Will Hartung
(wi...@msoft.com)


Adrian Kubala

unread,
Nov 11, 2003, 9:32:41 PM11/11/03
to
On Mon, 10 Nov 2003, Will Hartung wrote:
> "Adrian Kubala" <adr...@sixfingeredman.net> wrote in message
> news:Pine.LNX.4.56.03...@sixfingeredman.net...
> > Yes, this is indeed what I meant. With the additional restriction that
> > these forms should be flexible and modifyable enough to evolve into your
> > final, arbitrarily-complex web-app. And best of all would be if, even
> > after all these modifications, the forms still automatically reflected
> > changes to the original schema in reasonable ways. It's a tall order -- I
> > don't know of anything that does all this -- but even a part of it is
> > great.
>
> Most app/form generators that I've seen (albeit, most of them have been
> for simple DB screens, not web pages) are utter crap. They happily spit
> out Kbytes of boiler plate template code that is only a fraction above
> cutting and pasting in terms of sophistication. [...]

That's why I'm hoping Lisp will be a cut above -- it has a built-in
preprocessor (macros) so your "boiler plate" automatically gets generated
every time you compile.

> [...] Using a mechanism much like "within the after change in name field


> block, replace the block of text delimited by these two regexps with
> ....".

Sounds like primitive, fragile, unstructured macros to me.

> I thought about a similar system leveraging CL macros, but having

> database dependent macros didn't sit right with me. [...]

Database-dependent... I take it you mean that it infers the data model
from the database? I was envisioning more having the macro-defined data
model be authoritative, and teach it to output database schemas or schema
deltas to keep the database up-to-date manually.

> Today, I think a combination of a solid "boiler plate" class core that is
> designed to be overloaded/pre-empted combined with reflection and a high
> level definition file would be a pretty good solution.

Well, I'm still very fuzzy on how an ideal system would work (or I'd be
working on it instead of babbling here) but I have some vague ideas about
approaches I think won't be able to go far enough. For example, any
traditional OO-relational mapping, because it cripples your ability to use
arbitrary relations flexibly. And like you said, I don't think inheritance
will be able to handle all customizations, but modifying the base class is
not an option I'd like to consider. I have a gut feeling that generic
functions, HOFs, units/functors/mixins and code-walking macros would all
be part of the ultimate solution.

Kent M Pitman

unread,
Nov 12, 2003, 4:15:01 AM11/12/03
to
Pascal Costanza <cost...@web.de> writes:

> Kenny Tilton wrote:
>
> > Yes, I think so. Continuations are a solution looking for a


> > problem. The mistake is thinking that the call stack is a smart

> > place for long-lived state. That's silly on the face of


> > it. Continuations are a classic geek-hack, creating insane technical
> > difficulties for an apparently clever solution to a problem with a
> > much simpler, boring, direct solution that just happens to fit the
> > problem better.
>

> I think that continuations are currently becoming more important
> because they really make sense in the context of web
> applications. Common Lisp vendors should start to think about adding
> them IMHO.

Conceptually this may seem right, and I personally tried to implement
a web server dialog system based on first class continuations a while
back because the idea seemed so compelling and I thought I had struck
on the first Real reason to care about continuations. But though I
went in with a positive attitude, I was quickly disenchanted.

The problems I recall encountering were...

- You end up with a rack of likely-to-be-stale continuations and
a desire to poke at them to find out whether you should continue
to hold them. If they are just raw continuations, they are hard
to poke at since you really want to know information about their
internal lexical state. Even just debugging them is a pain
because they all print awfully. CLOS objects, just for example,
print better.

- The information in a continuation is procedurally embedded, so if
someone goes to another web browser and connects in parallel in
a different session o nthe same account, changing even one piece of
state, your pending continuation is likely to overwrite the change
or to ask needless questions.

The right model seems to be something database-like or blackboard-like,
since such systems allow partial update in a graceful way that is
globally visible to a system in which multiple sessions might exist.
I bet that such systems typically represent the state more compactly,
but not by ordinary metrics of simply "better storage" but by forcing
you into a more explicit understanding of the FSM dialogs that make
serious web programming more likely to work. In a sense, the problem
in this regard might be re-expressed by saying that the web really
requires, for effective use, dynamic re-planning of a dialog at every
question, since arbitrary state might have changed between utterances,
and continuations, by their nature, are really working against that
UNLESS the only piece of information they close over is "where was I?"
in a dynamic plan, but if that's all they contain, what value are they
really giving you? And at what cost?

frr

unread,
Nov 12, 2003, 8:50:47 AM11/12/03
to
On Mon, 10 Nov 2003 01:46:50 +0100, Marco Baringer <m...@bese.it> wrote:


>none of this touches on the real advantage of continuations, which
>actually has nothing to do with how the app works. With continuations
>I can _write_ my web app as a sequence of function calls, this is the
>real advantage. What happens after a certain click is expressed
>cleanly and clearly in the app's code, this actually results in
>people writing far more advanced user interfaces over http.

Can you point to some article or tutorial on this subject? I always
considered continuations a cool concept, but without any clear application.
After spending quite some time writing 'Wizard' GUIs, I'd love to see a less
painful and boring way to do it.

Pascal Costanza

unread,
Nov 12, 2003, 9:58:18 AM11/12/03
to
Kent M Pitman wrote:

> Conceptually this may seem right, and I personally tried to implement
> a web server dialog system based on first class continuations a while
> back because the idea seemed so compelling and I thought I had struck
> on the first Real reason to care about continuations. But though I
> went in with a positive attitude, I was quickly disenchanted.
>
> The problems I recall encountering were...
>
> - You end up with a rack of likely-to-be-stale continuations and
> a desire to poke at them to find out whether you should continue
> to hold them. If they are just raw continuations, they are hard
> to poke at since you really want to know information about their
> internal lexical state. Even just debugging them is a pain
> because they all print awfully. CLOS objects, just for example,
> print better.

Some questions for understanding:

Do you think that time-outs for continuations wouldn't work either?

And if you could inspect their internal state in better ways, would this
help? Or are these just symptoms, and the root of these problems is deeper?

> - The information in a continuation is procedurally embedded, so if
> someone goes to another web browser and connects in parallel in
> a different session o nthe same account, changing even one piece of
> state, your pending continuation is likely to overwrite the change
> or to ask needless questions.
>
> The right model seems to be something database-like or blackboard-like,
> since such systems allow partial update in a graceful way that is
> globally visible to a system in which multiple sessions might exist.
> I bet that such systems typically represent the state more compactly,
> but not by ordinary metrics of simply "better storage" but by forcing
> you into a more explicit understanding of the FSM dialogs that make
> serious web programming more likely to work. In a sense, the problem
> in this regard might be re-expressed by saying that the web really
> requires, for effective use, dynamic re-planning of a dialog at every
> question, since arbitrary state might have changed between utterances,
> and continuations, by their nature, are really working against that
> UNLESS the only piece of information they close over is "where was I?"
> in a dynamic plan, but if that's all they contain, what value are they
> really giving you? And at what cost?

Let me try to rephrase this: Are you saying that, because you need to
store much more information than just "where did I come from" anyway,
and such information doesn't fit nicely with continuations, it's better
to organize the "continuation-like stuff" close to the other state you
need to keep rather than spread the various bits of information in
different places?

Furthermore, I have read several times that continuations make code for
web applications dramatically more compact than when you program the
stuff by hand. Do you think that similar reductions of code size can be
achieved with different means? (that is, probably macros, of course ;)

Or would you rather say that complex web applications need complex code,
end of story?


Pascal

--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

Will Hartung

unread,
Nov 12, 2003, 1:00:55 PM11/12/03
to
"Pascal Costanza" <cost...@web.de> wrote in message
news:bothqb$q7k$1...@f1node01.rhrz.uni-bonn.de...

> Kent M Pitman wrote:
> > - You end up with a rack of likely-to-be-stale continuations and
> > a desire to poke at them to find out whether you should continue
> > to hold them. If they are just raw continuations, they are hard
> > to poke at since you really want to know information about their
> > internal lexical state. Even just debugging them is a pain
> > because they all print awfully. CLOS objects, just for example,
> > print better.
>
> Some questions for understanding:
>
> Do you think that time-outs for continuations wouldn't work either?
>
> And if you could inspect their internal state in better ways, would this
> help? Or are these just symptoms, and the root of these problems is
deeper?

To me, the problem with the contiuations is how a web application is
interacted with.

A web app is, essentially, a stack of pages (just look at the menu under
your back button).

The user interacts with the application either through new links on the
current page, or by going "back" into the stack.

If they click on a new link, you have a new page on the stack (even if it's
a page that was seen before).

If they click back (or select an older page), and then select a DIFFERENT
link, then your stack has just been truncated.

For example, if I start at Page A and using links hit pages A, B, C, D, E,
then Back, Back to C, and then go to F the state of the D and E are
basically gone.

Technically, there's no way to get back to D and E as they represent not
only pages, but a point in time when the page was created.

So, conceptually, those instances of the D and E coninuations are now gone
and need to expire. This would probably happen