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, ...
Adrian Kubala <······@sixfingeredman.net> wrote in message news:<·································@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
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
Marco Antoniotti wrote:
>
> 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?
>
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
On Fri, 7 Nov 2003, Ray Dillinger wrote:
> Marco Antoniotti wrote:
> > Adrian Kubala wrote:
> > > 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?
> >
>
> I cannot speak for the original poster, but the usual ways are
> with SRFI-9, the TinyCLOS or Meroon libraries, and S2 or similar.
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.
Adrian Kubala wrote:
> On Fri, 7 Nov 2003, Ray Dillinger wrote:
>
>>Marco Antoniotti wrote:
>>
>>>Adrian Kubala wrote:
>>>
>>>>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?
>>>
>>
>>I cannot speak for the original poster, but the usual ways are
>>with SRFI-9, the TinyCLOS or Meroon libraries, and S2 or similar.
>
>
> 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.
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
Marco Antoniotti <·······@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
Alexander Schmolck wrote:
> Marco Antoniotti <·······@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?
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
From: Marco Baringer
Subject: continuations in web apps
Date:
Message-ID: <m2k769bdhq.fsf@bese.it>
Kenny Tilton <·······@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.
--
-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
Marco Baringer <··@bese.it> wrote in message news:<··············@bese.it>...
> Kenny Tilton <·······@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.
Kaz Kylheku wrote:
> Marco Baringer <··@bese.it> wrote in message news:<··············@bese.it>...
>
>>Kenny Tilton <·······@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.
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?
:)
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 wrote:
> Kenny Tilton <·······@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.
--
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:
> 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
Kenny Tilton wrote:
>
>
> Marco Baringer wrote:
>
>> Kenny Tilton <·······@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
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Marco Baringer
Subject: Re: continuations in web apps
Date:
Message-ID: <m2isltf3t1.fsf@bese.it>
Kenny Tilton <·······@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.
--
-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
On Mon, 10 Nov 2003 01:46:50 +0100, Marco Baringer <··@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.
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
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.
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).
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:
> 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
Jens Axel S�gaard <······@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
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
From: Arthur Lemmens
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <opryd3awuek6vmsw@news.xs4all.nl>
Pascal Costanza <········@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.
> 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
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
Arthur Lemmens <········@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
Kenny Tilton <·······@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.
From: Marc Battyani
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <bom6rg$vbe@library1.airnews.net>
"Pascal Costanza" <········@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
Marc Battyani wrote:
> "Pascal Costanza" <········@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...)
Why do you think so? What is the downside of continuations for complex
web applications?
Pascal
Pascal Costanza <········@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.
From: Marc Battyani
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <bp0ldf$lu7@library1.airnews.net>
"Pascal Costanza" <········@web.de> wrote
> Marc Battyani wrote:
>
> > "Pascal Costanza" <········@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...)
>
> Why do you think so? What is the downside of continuations for complex
> web applications?
It's not a problem of downside, it's a problem of not useful.
The last web application I've written has about one hundred object classes,
each slot in those class is modified/viewable or not according to its status,
an the user habilitations. Several users interact simultaneously on the same
objects. They can modify and annotate them. The modifications done by one
user are sent back to the other users browsers. When a user makes
modifications that disable/enable the access to slots or functions for
himself or other users, their views change automatically. The objects as
saved/retrieved in an SQL database.
The state management for this would be a nightmare.
Now, how many lines of code for this HTML user interface? Zero. All is
handled by my framework.
So what would I gain from continuations ?
For me continuations are (maybe) an answer to the third generation of web
apps. They could be useful for for things like: 1-ask shipping address, 2-ask
billing address, 3-ask credit card #, 4-ask are you sure?, 5-register sale.
But these simple applications are not interesting now, and I can't see any
use for them in a complex web application.
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message
···············@library1.airnews.net...
> Now, how many lines of code for this HTML user interface? Zero. All is
> handled by my framework.
> So what would I gain from continuations ?
This is the real key. The key to your application, and pretty much any
complicated application, is the overarching framework that your Application
Developers use vs what your Framework Developers use.
In this case, your Framework shrouds vast complexity from your Application
Developers (even if you are one and the same), and the Application
Developers work at your Framework level.
A zillion years ago I considered continuations for web apps, because they do
seem very straightforward at a glance, and perhaps for some applications
they are appropriate.
But with further thought, I think the number of applications that they're
appropriate for is less and less, and what looked like a nice silver bullet
really only lightly hid "real work" that had to be done anyway. That "real
work" soon eclisped the usefulness of continuations in this case as it was
more useful for the more general case and useable in the specific cases
where continuations are handy.
That boils continuations down to an implementation detail deep in the
Framework, when what is really critical to the Application Developers is the
Framework itself.
For example, most developers simply don't care, for example, how their
multi-threading capability is implemented within their system. It's novel
that it can be done with continuations, but truly unimportant to the issue
of what folks use multi-threading for in the first place.
Regards,
Will Hartung
(·····@msoft.com)
From: Marc Battyani
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <bp20oe$835@library1.airnews.net>
"Will Hartung" <·····@msoft.com> wrote
> "Marc Battyani" <·············@fractalconcept.com> wrote
> > Now, how many lines of code for this HTML user interface? Zero. All is
> > handled by my framework.
> > So what would I gain from continuations ?
>
> This is the real key. The key to your application, and pretty much any
> complicated application, is the overarching framework that your Application
> Developers use vs what your Framework Developers use.
>
> In this case, your Framework shrouds vast complexity from your Application
> Developers (even if you are one and the same), and the Application
> Developers work at your Framework level.
Yes.
> A zillion years ago I considered continuations for web apps, because they
do
> seem very straightforward at a glance, and perhaps for some applications
> they are appropriate.
>
> But with further thought, I think the number of applications that they're
> appropriate for is less and less, and what looked like a nice silver bullet
> really only lightly hid "real work" that had to be done anyway. That "real
> work" soon eclisped the usefulness of continuations in this case as it was
> more useful for the more general case and useable in the specific cases
> where continuations are handy.
This is exactly what I mean. Continuations are an answer to the previous
models of simple web applications.
> That boils continuations down to an implementation detail deep in the
> Framework, when what is really critical to the Application Developers is
the
> Framework itself.
>
> For example, most developers simply don't care, for example, how their
> multi-threading capability is implemented within their system. It's novel
> that it can be done with continuations, but truly unimportant to the issue
> of what folks use multi-threading for in the first place.
I agree with you.
I think this is a good illustration of the Scheme vs Common Lisp communities.
The Scheme community prefers theoretical purity (here continuations) while
the Common Lisp side prefers pragmatical solutions that solve the real
problems of the real world. (even if they are not clean) ;-)
Marc
From: =?iso-8859-2?q?S=B3awek_=AFak?=
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <86znez9b4y.fsf@thirst.unx.era.pl>
"Marc Battyani" <·············@fractalconcept.com> writes:
[...]
> Now, how many lines of code for this HTML user interface? Zero. All is
> handled by my framework.
> So what would I gain from continuations ?
I find the automatic undoing of transactions *very* appealing. Modeling user
session in interaction with a web page using function calls and returns is
also great. What about bookmarking your page and restarting the computation
after a while? If continuations only were serializable, you could restart
the server without any of the users noticing. Transfering the sessions
between machines in clusters would let you restart the servers
transparently. What about keeping state in memory (closures+call stack)
instead of RDBMS?
/S
S�awek �ak <····@era.pl> writes:
> I find the automatic undoing of transactions *very*
> appealing. Modeling user session in interaction with a web page
> using function calls and returns is also great. What about
> bookmarking your page and restarting the computation after a while?
> If continuations only were serializable, you could restart the
> server without any of the users noticing. Transfering the sessions
> between machines in clusters would let you restart the servers
> transparently. What about keeping state in memory (closures+call
> stack) instead of RDBMS?
Well, what about it? It would perhaps be a less painful workaround for
the fundamental problem that you are working against your tools, in
this case the HTTP protocol.
The problem isn't on the server side. It is perfectly possible, and
not that hard either, to model an app as a set of abstract resources
(that can be presented in various ways) that are manipulated with GET,
POST, PUT and DELETE (if you feel innovative, also MKCOL, PROPPATCH
etc). The problem is that HTTP clients, namely HTML-centric web
browsers, are crap and don't really support HTTP all that well. If
this changes (and it probably won't), writing web apps will be a lot
less painfull; until then, every server-side trick to pull "client
sessions" and other state out of the air will at some point prove to
be leaky abstractions in the Joel Spolsky sense.
I can see how continuations could make some web apps look more like
they would be written for a non-web environment, by making the code
look like it would use plain function calls. But web apps simply do
not work like non-web ones, and neither should they. The whole idea
has "leaky abstraction" (in the Joel Spolsky sense) written all over
it.
From: =?iso-8859-2?q?S=B3awek_=AFak?=
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <868ymjnrb3.fsf@thirst.unx.era.pl>
Henrik Motakef <············@henrik-motakef.de> writes:
> S�awek �ak <····@era.pl> writes:
>
>> I find the automatic undoing of transactions *very*
>> appealing. Modeling user session in interaction with a web page
>> using function calls and returns is also great. What about
>> bookmarking your page and restarting the computation after a while?
>> If continuations only were serializable, you could restart the
>> server without any of the users noticing. Transfering the sessions
>> between machines in clusters would let you restart the servers
>> transparently. What about keeping state in memory (closures+call
>> stack) instead of RDBMS?
>
> Well, what about it? It would perhaps be a less painful workaround for
> the fundamental problem that you are working against your tools, in
> this case the HTTP protocol.
Are we both talking about statelessness of HTTP?
> The problem isn't on the server side. It is perfectly possible, and
> not that hard either, to model an app as a set of abstract resources
> (that can be presented in various ways) that are manipulated with GET,
> POST, PUT and DELETE (if you feel innovative, also MKCOL, PROPPATCH
> etc).
Um. Okay but having the resources presented in response to the HTTP request
doesn't solve the session state problem.
> The problem is that HTTP clients, namely HTML-centric web
> browsers, are crap and don't really support HTTP all that well. If
> this changes (and it probably won't), writing web apps will be a lot
> less painfull;
I don't know what you are refering to. But for sure duplicating window
(splitting the interaction) and the back button frenzy will persist as a
problem no matter what. And this is best solved with continuations *if* you
use this "control-flow is session" paradigm.
> until then, every server-side trick to pull "client
> sessions" and other state out of the air will at some point prove to
> be leaky abstractions in the Joel Spolsky sense.
>
> I can see how continuations could make some web apps look more like
> they would be written for a non-web environment, by making the code
> look like it would use plain function calls. But web apps simply do
> not work like non-web ones, and neither should they. The whole idea
> has "leaky abstraction" (in the Joel Spolsky sense) written all over
> it.
They could. Why not think of it as of the action-callback thing in GUI's?
Even the links can be represented as continuations when you do some really
dynamic thing. Anyway, I don't know who Joel Spolsky is.
/S
From: Marc Battyani
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <bp20ov$nfd@library1.airnews.net>
"S�awek �ak" <····@era.pl> wrote in
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> [...]
>
> > Now, how many lines of code for this HTML user interface? Zero. All is
> > handled by my framework.
> > So what would I gain from continuations ?
>
> I find the automatic undoing of transactions *very* appealing. Modeling
user
> session in interaction with a web page using function calls and returns
is
> also great.
This implies modal interaction with the user which is not a good model for
web applications.
> What about bookmarking your page and restarting the computation
> after a while? If continuations only were serializable, you could
restart
> the server without any of the users noticing. Transfering the sessions
> between machines in clusters would let you restart the servers
> transparently. What about keeping state in memory (closures+call stack)
> instead of RDBMS?
That's what I do (keeping state in memory ) but in objects and closures, not
in the call stack because, as I and others tried to explain, web applications
do not have a modal stack based navigation.
Marc
Marc Battyani wrote:
> "Pascal Costanza" <········@web.de> wrote
>
>>Marc Battyani wrote:
>>
>>
>>>"Pascal Costanza" <········@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...)
>>
>>Why do you think so? What is the downside of continuations for complex
>>web applications?
>
>
> It's not a problem of downside, it's a problem of not useful.
>
> The last web application I've written has about one hundred object classes,
> each slot in those class is modified/viewable or not according to its status,
> an the user habilitations. Several users interact simultaneously on the same
> objects. They can modify and annotate them. The modifications done by one
> user are sent back to the other users browsers. When a user makes
> modifications that disable/enable the access to slots or functions for
> himself or other users, their views change automatically. The objects as
> saved/retrieved in an SQL database.
> The state management for this would be a nightmare.
>
> Now, how many lines of code for this HTML user interface? Zero. All is
> handled by my framework.
Sounds very cool!
Pascal
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m2n0axq1dn.fsf@bese.it>
"Marc Battyani" <·············@fractalconcept.com> writes:
> For me continuations are (maybe) an answer to the third generation of web
> apps. They could be useful for for things like: 1-ask shipping address, 2-ask
> billing address, 3-ask credit card #, 4-ask are you sure?, 5-register sale.
> But these simple applications are not interesting now, and I can't see any
> use for them in a complex web application.
please, e-commerce apps are not that simple. The logic is full of
conditionals and loops, questions which depend on prvious answers, the
ability to go back and change things. We want the user to be able do
what makes sense to them and have the app "just work". Some of the
order info needs to backtracked (ie "undo" itself if the user hits the
back button) some of the info needs to remain if the user hits the
back button, the app program needs to be able to specify this.
here's what a real chockout process looki like:
[usually all this logic is sparse over various pages and serlvets,
with a continuation like approach it all appears in a single block.]
#1 user verifies the order contents
#2 if the session is anonymous ask the user to login or register
(registration is another multi-step operation).
#3 if the user has already purchased from us and they want to re-use
the info from last time then: if the last order contains all the
info neccesary for this order goto #8, otherwise collect the
missing info (and only the missing info) follawing the same logic
in steps #4-#7
#4 if the order contains products (things which we have to ship) get
required shipping info. If the products came bundled with a service
jump to #5 to get the required service sign-up info, then continue
asking where to ship the other products. (the order can be split
up into various shipments)
#4b if the order contians fragile products or is expensive offer
the user the option to insure the shipment (which is then done
by going to an external site).
#5 if the order contains subscripitons to services get singup info for
all the various services.
#6 if the user is a "reseller" ask them how much credit they want to
use, remove that amount from the cost of the order. goto #8.
#7 if the user is a "regular" user get payment info. If they want to
pay in installments get the required bank info and verify it via an
external service. If they want to pay via credit card get the
credit card info. If the user has already been here but was denied
one of the available payment methods do not show it again.
#6b goto #6 unless the payment info (cc number or cedit status) is
valid.
#8 present the user all the info they've inserted and allow them to
go back and change things. If they change the order re-ask the
info which is dependant on the change.
#9 confirm the order, send all the info to the backoffice and send
the user a confirmation email.
--
-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
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
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
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m2smkxgit3.fsf@bese.it>
Pascal Costanza <········@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
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
Marco Baringer wrote:
> Pascal Costanza <········@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
Pascal Costanza wrote:
> Marco Baringer wrote:
>
>> Pascal Costanza <········@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. :)
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.
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:
>
>> Marco Baringer wrote:
>>
>>> Pascal Costanza <········@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
From: =?iso-8859-2?q?S=B3awek_=AFak?=
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <864qx89bgj.fsf@thirst.unx.era.pl>
Pascal Costanza <········@web.de> writes:
> Kenny Tilton wrote:
>
>> Pascal Costanza wrote:
[...]
>>> 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.
Yes. That's the point. It is a lot of code put to implement partial
solution. It seems to me that many times Common Lisp programmers prefer
using macros to taking shot at compiler modification. (I'm not sure if the
compiler used for this specific project was open source, but ...). You can
have CLOS with macros, but still can't implement continuations with macros
(oh - you can write a full code walker with environments but the compiler is
already walking the code!)
Paul Graham devoted 4 chapters of "On Lisp" to describe and emulate
continuations in Common Lisp. These are also good examples of their use
(take the parallel tree searching for one, multiprocessing as other
example). I think that PLT's work on web servlets using call/cc is just
excellent and could get really WILD if serialisation of continuations in PLT
Scheme was possible. For many other examples turn to readscheme.org.
Regarding Kent Pitman's objections for unwind-protect and call/cc
coexistence in Scheme, Dorai Sitaram's article at
http://www.ccs.neu.edu/home/dorai/uwcallcc/uwcallcc.html proved that it can
be done. (KMP's PFAQ is updated now, BTW). Presence of first class
continuations in Scheme allows them doing soft multithreading easily. There
are quite a few Common Lisps lacking multithreading and it is not a
coincidence I believe. Allegro CL for example uses "stack groups" to do MT
on UNIX, which lets them avoid dealing with multiple, often broken, OS based
MT implementations (SBCL's MT on Linux with clone() syscall was done for
this exact reason). Does anyone know how far are stack groups from real
continuations?
Getting back to the just-hack-the-compiler approach. There are examples of
doing even greater changes to compiler just to prove a point (and make a
difference ;). I really like the case of stackless Python, which deemed
impossible by GvR (Python's designer) was implemented as "exercise" by
Christian Tismer to prove otherwise (see http://www.stackless.com/). This
makes using coroutines and other concepts in Python possible and easy. First
class continuations cannot hurt Common Lisp; and performance hit should be
negligible if continuations were not necessary.
/S
S�awek �ak <····@era.pl> writes:
> be done. (KMP's PFAQ is updated now, BTW). Presence of first
> class continuations in Scheme allows them doing soft
> multithreading easily. There are quite a few Common Lisps
> lacking multithreading and it is not a coincidence I
> believe. Allegro CL for example uses "stack groups" to do MT on
> UNIX, which lets them avoid dealing with multiple, often broken,
> OS based MT implementations (SBCL's MT on Linux with clone()
> syscall was done for this exact reason). Does anyone know how
Sorry, you've lost me. What exact reason?
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> S�awek �ak <····@era.pl> writes:
>
> > be done. (KMP's PFAQ is updated now, BTW). Presence of first
> > class continuations in Scheme allows them doing soft
> > multithreading easily. There are quite a few Common Lisps
> > lacking multithreading and it is not a coincidence I
> > believe. Allegro CL for example uses "stack groups" to do MT on
> > UNIX, which lets them avoid dealing with multiple, often broken,
> > OS based MT implementations (SBCL's MT on Linux with clone()
> > syscall was done for this exact reason). Does anyone know how
>
> Sorry, you've lost me. What exact reason?
"Multi-threading with high performance is hadr, so let us use the
closest-to-metal implementation to see what needs doing, should we
decide to make it better and more portable"?
Or did you have another reason in mind?
//Ingvar
--
(defun m (a b) (cond ((or a b) (cons (car a) (m b (cdr a)))) (t ())))
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Daniel Barlow <···@telent.net> writes:
>
>> S�awek �ak <····@era.pl> writes:
>>
>> > be done. (KMP's PFAQ is updated now, BTW). Presence of first
>> > class continuations in Scheme allows them doing soft
>> > multithreading easily. There are quite a few Common Lisps
>> > lacking multithreading and it is not a coincidence I
>> > believe. Allegro CL for example uses "stack groups" to do MT on
>> > UNIX, which lets them avoid dealing with multiple, often broken,
>> > OS based MT implementations (SBCL's MT on Linux with clone()
>> > syscall was done for this exact reason). Does anyone know how
>>
>> Sorry, you've lost me. What exact reason?
>
> "Multi-threading with high performance is hadr, so let us use the
> closest-to-metal implementation to see what needs doing, should we
> decide to make it better and more portable"?
Is that the same reason as S�awek is talking about, or just another
reason that someone else has decided I must have had for writing it?
SBCL is going for native threads because (a) it means that blocking
foreign functions (e.g. database, network acess) will only block one
thread, not all of them (b) it takes advantage of SMP, (c) given the
manpower available to SBCL vs that available to kernel hackers of the
various systems it runs on, it's likely that despite any theoretical
advantage of a userland scheduler the kernel threads will be made to
run faster in practice. None of these reasons would change if there
were support for continuations in the language. I note that CMUCL has
co-operative MP based on stack-groups, and that doesn't seem to have
required adding continuations to the language either.
clone() on Linux is an OS-based interface (obviously, it's a kernel
syscall). It's not the Posix Threads interface: to get that on Linux
one would have (or would until recently have had[*]) to use
LinuxThreads, which I happily concede sucks rocks. This still has
nothing to do with continuations, however.
> Or did you have another reason in mind?
I don't know. Was that the same reason?
-dan
[*] there's a newer implementation called NPTL, available in Red Hat
Linux (as was) or in the imminently available kernel 2.6. This is a
Whole Lot Better
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> > Daniel Barlow <···@telent.net> writes:
> >
> >> S�awek �ak <····@era.pl> writes:
> >>
> >> > be done. (KMP's PFAQ is updated now, BTW). Presence of first
> >> > class continuations in Scheme allows them doing soft
> >> > multithreading easily. There are quite a few Common Lisps
> >> > lacking multithreading and it is not a coincidence I
> >> > believe. Allegro CL for example uses "stack groups" to do MT on
> >> > UNIX, which lets them avoid dealing with multiple, often broken,
> >> > OS based MT implementations (SBCL's MT on Linux with clone()
> >> > syscall was done for this exact reason). Does anyone know how
> >>
> >> Sorry, you've lost me. What exact reason?
> >
> > "Multi-threading with high performance is hadr, so let us use the
> > closest-to-metal implementation to see what needs doing, should we
> > decide to make it better and more portable"?
>
> Is that the same reason as S�awek is talking about, or just another
> reason that someone else has decided I must have had for writing it?
Thta is my (admittedly garbled) memory of one of your motivations
going for clone() as the primitive (the "let's get something working,
so we can see what actrually needs doing" angle), rather than
something else. I couldn't, really, see any reason listed that meshes
with anything I recall of what you've said in what S�awek wrote.
> SBCL is going for native threads because (a) it means that blocking
> foreign functions (e.g. database, network acess) will only block one
> thread, not all of them (b) it takes advantage of SMP, (c) given the
> manpower available to SBCL vs that available to kernel hackers of the
> various systems it runs on, it's likely that despite any theoretical
> advantage of a userland scheduler the kernel threads will be made to
> run faster in practice.
[SNIP]
> > Or did you have another reason in mind?
>
> I don't know. Was that the same reason?
To a first approximation, yes. There were further details that had
slipped my mind.
//Ingvar
--
(defmacro fakelambda (args &body body) `(labels ((me ,args ,@body)) #'me))
(funcall (fakelambda (a b) (if (zerop (length a)) b (format nil "~a~a"
(aref a 0) (me b (subseq a 1))))) "Js nte iphce" "utaohrls akr")
Daniel Barlow <···@telent.net> writes:
>> "Multi-threading with high performance is hadr, so let us use the
>> closest-to-metal implementation to see what needs doing, should we
>> decide to make it better and more portable"?
>
> Is that the same reason as S�awek is talking about, or just another
> reason that someone else has decided I must have had for writing it?
>
> SBCL is going for native threads because (a) it means that blocking
> foreign functions (e.g. database, network acess) will only block one
> thread, not all of them (b) it takes advantage of SMP, (c) given the
> manpower available to SBCL vs that available to kernel hackers of the
> various systems it runs on, it's likely that despite any theoretical
> advantage of a userland scheduler the kernel threads will be made to
> run faster in practice. None of these reasons would change if there
> were support for continuations in the language.
OS Threads are for sure better than doing it with continuations/stack
groups, but having continuations facilitates the task of having the threads
at all.
> I note that CMUCL has co-operative MP based on stack-groups,
> and that doesn't seem to have required adding continuations to
> the language either.
It seems to me, that continuations and stack groups are pretty close in
implementation.
> [*] there's a newer implementation called NPTL, available in Red Hat
> Linux (as was) or in the imminently available kernel 2.6. This is a
> Whole Lot Better
Is it POSIX threading library? Do you plan to use it in SBCL?
/S
S�awek �ak <····@era.pl> writes:
> OS Threads are for sure better than doing it with continuations/stack
> groups, but having continuations facilitates the task of having the threads
> at all.
You're not making sense. How would having continuations facilitate
an FFI-useful SMP-capable thread implementation?
I say again: if we'd wanted userland threads, these are clearly
possible to add to a Lisp without continuations because CMUCL has
them: in fact, it'd probably have taken about a day to steal them for
SBCL. Whatever your opinion on the merits of continuations, their
availability or otherwise in CL had absolutely no bearing on our
decisions about how to do thread support.
>> [*] there's a newer implementation called NPTL, available in Red Hat
>> Linux (as was) or in the imminently available kernel 2.6. This is a
>> Whole Lot Better
>
> Is it POSIX threading library? Do you plan to use it in SBCL?
Yes. Not in its entirety, though bits of it (e.g. futexes) are useful
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> S�awek �ak <····@era.pl> writes:
>
>> OS Threads are for sure better than doing it with continuations/stack
>> groups, but having continuations facilitates the task of having the threads
>> at all.
>
> You're not making sense. How would having continuations facilitate
> an FFI-useful SMP-capable thread implementation?
Not SMP capable. That's another goal. Having continuations and threads on UP
machine not using os threads lets you for example do IO programming without
select, which is very convenient.
> I say again: if we'd wanted userland threads, these are clearly
> possible to add to a Lisp without continuations because CMUCL has
> them: in fact, it'd probably have taken about a day to steal them for
> SBCL. Whatever your opinion on the merits of continuations, their
> availability or otherwise in CL had absolutely no bearing on our
> decisions about how to do thread support.
I had different impression on this matter. To me threads in scheme were
nothing else but non-escaping continuations managed by some form of built-in
scheduler.
>>> [*] there's a newer implementation called NPTL, available in Red Hat
>>> Linux (as was) or in the imminently available kernel 2.6. This is a
>>> Whole Lot Better
>>
>> Is it POSIX threading library? Do you plan to use it in SBCL?
>
> Yes. Not in its entirety, though bits of it (e.g. futexes) are useful
Great! So there is hope it won't be Linux-only. :)
/S
=?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
Pardon the non-Lisp-related administrative aside, but is there an RFC
somewhere that explains what this =?...?= stuff is that has started to
appear in from fields and in subject lines of mail, and apparently now
news newsgroups?
a: the handiwork of brain-dead mail clients
b: unicode
c: spam
those three probably cover 95% of what youre seeing
isildur
On Mon, 24 Nov 2003, Kent M Pitman wrote:
> =?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
>
> Pardon the non-Lisp-related administrative aside, but is there an RFC
> somewhere that explains what this =?...?= stuff is that has started to
> appear in from fields and in subject lines of mail, and apparently now
> news newsgroups?
>
>
Kent M Pitman <······@nhplace.com> writes:
> =?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
>
> Pardon the non-Lisp-related administrative aside, but is there an RFC
> somewhere that explains what this =?...?= stuff is that has started to
> appear in from fields and in subject lines of mail, and apparently now
> news newsgroups?
It is the `Q' encoding (similar to, but not the same as `quoted
printable' encoding) that first raised its head in
RFC 1341, subsequently superseded by RFC 1521, subsequently superseded
by RFCs 2045 - 2049
There is a `B' encoding, too, (identical to base64)
Kent M Pitman <······@nhplace.com> writes:
> =?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
>
> Pardon the non-Lisp-related administrative aside, but is there an RFC
> somewhere that explains what this =?...?= stuff is that has started to
> appear in from fields and in subject lines of mail, and apparently now
> news newsgroups?
I think it's RFC 2047 (November 1996), which replaces 1522 (September
1993), which replaced 1342 (June 1992).
On Mon, 24 Nov 2003 21:05:13 +0000, Bruce Stephens <············@cenderis.demon.co.uk> wrote:
> Kent M Pitman <······@nhplace.com> writes:
>
>> =?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
>>
>> Pardon the non-Lisp-related administrative aside, but is there an
>> RFC somewhere that explains what this =?...?= stuff is that has
>> started to appear in from fields and in subject lines of mail, and
>> apparently now news newsgroups?
>
> I think it's RFC 2047 (November 1996), which replaces 1522
> (September 1993), which replaced 1342 (June 1992).
Yes, some people actually have the nerve to put their real names into
the "From:" header although it can't be expressed with the holy 26
characters given to us by ASCII. Tsktsktsk... :)
Edi.
On Mon, 24 Nov 2003 22:06:06 +0100, Edi Weitz <···@agharta.de> wrote:
> On Mon, 24 Nov 2003 21:05:13 +0000, Bruce Stephens <············@cenderis.demon.co.uk> wrote:
>
>> Kent M Pitman <······@nhplace.com> writes:
>>
>>> =?iso-8859-2?q?S=B3awek_=AFak?= <····@era.pl> writes:
>>>
>>> Pardon the non-Lisp-related administrative aside, but is there an
>>> RFC somewhere that explains what this =?...?= stuff is that has
>>> started to appear in from fields and in subject lines of mail, and
>>> apparently now news newsgroups?
>>
>> I think it's RFC 2047 (November 1996), which replaces 1522
>> (September 1993), which replaced 1342 (June 1992).
>
> Yes, some people actually have the nerve to put their real names
> into the "From:" header although it can't be expressed with the holy
> 26 characters given to us by ASCII. Tsktsktsk... :)
BTW, the OP used a news client (Gnus) which is known for its
conforming behaviour with respect to RFCs and other standards. I
(using Gnus 5.10.2 with FSF Emacs 21.3) saw the "From:" header as it
was intended. I guess that either your (Kent's) version of Gnus is
rather old (I don't know how long it took them to implement an RFC
from 1996) or you're missing something else like Mule or the necessary
fonts.
Edi.
From: Christopher C. Stacy
Subject: Re: Scheme vs Lisp!
Date:
Message-ID: <u7k22aiu0.fsf@dtpq.com>
>>>>> On 14 Nov 2003 11:02:30 +0000, Ingvar Mattsson ("Ingvar") writes:
Ingvar> Daniel Barlow <···@telent.net> writes:
>> S�awek �ak <····@era.pl> writes:
>>
>> > be done. (KMP's PFAQ is updated now, BTW). Presence of first
>> > class continuations in Scheme allows them doing soft
>> > multithreading easily. There are quite a few Common Lisps
>> > lacking multithreading and it is not a coincidence I
>> > believe. Allegro CL for example uses "stack groups" to do MT on
>> > UNIX, which lets them avoid dealing with multiple, often broken,
>> > OS based MT implementations (SBCL's MT on Linux with clone()
>> > syscall was done for this exact reason). Does anyone know how
>>
>> Sorry, you've lost me. What exact reason?
Ingvar> "Multi-threading with high performance is hadr,
I think you mean "hard", as in "hard", "haard", "harad", "hardar", etc.
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 14 Nov 2003 11:02:30 +0000, Ingvar Mattsson ("Ingvar") writes:
>
> Ingvar> Daniel Barlow <···@telent.net> writes:
[ SNIP ]
> >> Sorry, you've lost me. What exact reason?
>
> Ingvar> "Multi-threading with high performance is hadr,
>
> I think you mean "hard", as in "hard", "haard", "harad", "hardar", etc.
Yes, keyboard slip-up, I'm afraid.
//Ingvar
--
Self-referencing
Five, seven, five syllables
This haiku contains
S�awek �ak <····@era.pl> writes:
> Regarding Kent Pitman's objections for unwind-protect and call/cc
> coexistence in Scheme, Dorai Sitaram's article at
> http://www.ccs.neu.edu/home/dorai/uwcallcc/uwcallcc.html proved that
> it can be done. (KMP's PFAQ is updated now, BTW).
To say that I acknowledge that at extreme cost (sacrificing the availability
of one or more general-purpose operators for this one purpose) it can be done.
Also, the call/cc that is in happy co-existence in Scheme is one you have
to construct, not the one you get for free with the language. So the above
misstates my positino. If, after reading my PFAQ, you think I haven't made
this concern clear in that document, please let me know and I'll update the
PFAQ further. I do not acknowledge that the Scheme spec is in a happy state
at all with respect to unwind-protect and call/cc, only that the bare claim
that unwind-protect cannot be written is, as a strictly technical matter,
false.
I expect languages to work out of the box with a certain set of important
features, and Scheme still does not provide the important set.
From: =?iso-8859-2?q?S=B3awek_=AFak?=
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <86llq5db6n.fsf@thirst.unx.era.pl>
Kent M Pitman <······@world.std.com> writes:
> S�awek �ak <····@era.pl> writes:
>
>> Regarding Kent Pitman's objections for unwind-protect and call/cc
>> coexistence in Scheme, Dorai Sitaram's article at
>> http://www.ccs.neu.edu/home/dorai/uwcallcc/uwcallcc.html proved that
>> it can be done. (KMP's PFAQ is updated now, BTW).
>
> To say that I acknowledge that at extreme cost (sacrificing the availability
> of one or more general-purpose operators for this one purpose)
Sorry. I understood that your objection to the Sitaram's proposition of
unwind-protect in Scheme was the specialising of call/cc to two cases:
call/cc-e and call/cc-l which are escaping and last-call continuations. In
my understanding those are suggestions contained in Proposed Solutions
section of your u-p-vs-c.html.
> Also, the call/cc that is in happy co-existence in Scheme is one you have
> to construct, not the one you get for free with the language. So the above
> misstates my positino. If, after reading my PFAQ, you think I haven't made
> this concern clear in that document, please let me know and I'll update the
> PFAQ further.
As stated above my understanding is that you still can use call/cc. The cob
technique described by Sitaram can free you of the burden of hand-marking
the constrained continuations used together with unwind-protect.
/S
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m2ekw9olx8.fsf@bese.it>
Sławek Żak <····@era.pl> writes:
> Yes. That's the point. It is a lot of code put to implement partial
> solution. It seems to me that many times Common Lisp programmers prefer
> using macros to taking shot at compiler modification. (I'm not sure if the
> compiler used for this specific project was open source, but ...). You can
> have CLOS with macros, but still can't implement continuations with macros
> (oh - you can write a full code walker with environments but the compiler is
> already walking the code!)
you forget what problem I was trying to solve. I do not want 100%
"perfect" continuations. I want to be able to write a block of
standard ANSI Common Lisp code which can "stopped" and "resumed" at
arbitrary points (within the code of the block). Mine is a complete
solution to this problem.
I'd like to repeat something: being to able write the logic which
controls a request/repsonse interaction model _as if_ it was a linear
sequence of operations is a GREAT idea.
And so what if I had to write a code walker and CPS transformer to do
it? we're still only talking about 800 lines of code (including
comments, empty lines, doc strings and copyright info).
p.s. - it's a macro.
--
-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
Marco Baringer wrote:
>
> And so what if I had to write a code walker and CPS transformer to do
> it? we're still only talking about 800 lines of code (including
> comments, empty lines, doc strings and copyright info).
Is the code walker packaged separatedly?
>
> p.s. - it's a macro.
>
Cheers
--
Marco
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m2llqax0mt.fsf@bese.it>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Marco Baringer wrote:
>
>> And so what if I had to write a code walker and CPS transformer to
>> do it? we're still only talking about 800 lines of code (including
>> comments, empty lines, doc strings and copyright info).
>
> Is the code walker packaged separatedly?
sort of, it's a part of a seperate library. look in the
src/code-transformers/walk directory in:
ftp://ftp.common-lisp.net/pub/project/bese/arnesi_latest.tar.gz
--
-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
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m21xsgvu0j.fsf@bese.it>
Marco Baringer <··@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
--
-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
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.)
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
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.
David Golden wrote:
> 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.
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
From: Marco Baringer
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <m2vfpsxb92.fsf@bese.it>
David Golden <············@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
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
Pascal Costanza <········@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?
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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> wrote in message
·················@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 when the session expires.
The next issue is typically when folks work there way through a web site,
particularly a dynamic site, when they "go back", they don't want to see
that state anyway.
If I go to a e-commerce site, hit pages A, B, C, D, E, buy something, on E,
and then Back to C, I'd like it to show that my shopping cart now has 1 item
in it.
Now, the browser cache prevents that (potentially), but moreso, if there's a
continuation maintaining the state of C, it's state is now wrong because of
a global change.
So, even with a continuation you still need to keep your state up to date,
which implys that continuations are only a partial solution, and more is
needed.
> > 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?
Web Apps can get confusing it two ways:
o When the you're in a "modal" process, and the user clicks "back" and
tries to do step 3 again even if you were at step 5. The application
typically can not control when this happens, but it may be important for it
to detect "hey you're already on step 5".
o Or, the corallary, simply jump from step 2 to step 5, skipping 3 and 4
(through direct URL manipulation perhaps).
Some applications are more sensitive to this kind of hopping around than
others.
Now, with continuations, you only know the "current" state, i.e. the state
that got you there. So, for the first case, relying on your continuations
leaves you with no knowledge that they've been to Step 5. In the second
case, you probably don't even HAVE a continuation since the continuations
tend to morph incrementally. So, perhaps now your in a spot where a) you're
not supposed to be and b) if you don't have a continuation available, you
don't know how they got there or where perhaps they SHOULD be (so you can
take them there, for example).
Many continuations tend to be rather opaque, so they can be difficult to
query.
So, while continuations handle linear flow of a process well, web apps are
non-linear beasts hammered to appear like a linear experience. It takes a
lot of work to make herd the catlike random stateless pages into a nice
procedural line.
> 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 ;)
It is interesting to see that when folks talk about using continuations for
web code, and how easy it is for them to use, they're talking about the
internal engine that runs there web app and how they IMPLEMENTED it.
Of the examples I've seen, the INTERFACE to that engine is basically a list
of states (pages) that describe the sequence, and since it's a high level
interface, it's essentially unaware that continuations are used at all
within the core.
And if those continuations are hidden, and perhaps the engine could be
reimplented using some other mechanism as long as the high level interface
is maintained, then the REQUIREMENT that there be continuations appears to
be quite moot.
> Or would you rather say that complex web applications need complex code,
> end of story?
Complex web apps need complex code. They need complex code in disparate
environments, both on the server and on the client.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> A web app is, essentially, a stack of pages (just look at the menu under
> your back button)....
>
> 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.
Depending on the browser to enforce stack discipline sounds like a
reliable way to introduce bugs into your web app. Even in browsers
that work the way you describe, it is usually possible to create a
new browser window that displays the same web page, so the user may
retain access to pages D or E after going from page C to page F.
In some applications, this is perfectly reasonable user behavior.
In others it may be unreasonable, but depending on the user to be
reasonable is another reliable way to introduce bugs into your web
app.
I am not entirely convinced that programming language support for
first class continuations makes reliable web apps easier to build,
but the conceptual connection is easy to demonstrate.
Will
"William D Clinger" <··········@verizon.net> wrote in message
·································@posting.google.com...
> Will Hartung wrote:
> Depending on the browser to enforce stack discipline sounds like a
> reliable way to introduce bugs into your web app. Even in browsers
> that work the way you describe, it is usually possible to create a
> new browser window that displays the same web page, so the user may
> retain access to pages D or E after going from page C to page F.
> In some applications, this is perfectly reasonable user behavior.
> In others it may be unreasonable, but depending on the user to be
> reasonable is another reliable way to introduce bugs into your web
> app.
That's the beauty of the web browser. You can't count on it for ANYTHING
(back buttons, scripting, graphics, resolution, character set, color,
cookies...). As you said, the user can takes "snapshots" of state and
literally pull cards from the deck, and if that is important to your
application, it's important to be aware of that detail.
It can all be overcome, it's just a lot of work.
The problem is trying to leverage a end-to-end process on to an inherently
chaotic framework.
Regards,
Will Hartung
(·····@msoft.com)
I wrote:
> I am not entirely convinced that programming language support for
> first class continuations makes reliable web apps easier to build,
> but the conceptual connection is easy to demonstrate.
In fact, I cloned this very page from the Google Groups server before
I sent my previous message. Then I went back to comp.lang.lisp and
visited a different page in my original window. Let's see what happens
when I hit the "Post message" button, conceptually returning a second
time to the continuation that I captured earlier...Hey, it looks like
it's gonna work!
Will
Will Hartung wrote:
> To me, the problem with the contiuations is how a web application is
> interacted with.
[...]
Thanks a lot for your detailed response!
Pascal
Pascal Costanza wrote:
> Will Hartung wrote:
>
>> To me, the problem with the contiuations is how a web application is
>> interacted with.
>
> [...]
>
>
> Thanks a lot for your detailed response!
<heh-heh> Now I am really confused. I am no Web app programmer, so I
have to hold back on my usual level of arrogance, but the stuff Will was
talking about are the things that struck me as not mapping nicely onto
continuations. But everyone seems to be jumping up and down about the
damn things as perfect for the Web. So I assumed I was missing
something. Now... I don't know, let's see if someone steps up to
denounce Will. <g>
I mean, sure, if you have a modal dialog model in which folks enter a
mode and /EITHER/ continue to the next mode /OR/ quit the mode at hand,
check, a straight-line script + continuations can model that (I said
"can", not "should"--I still don't see a call stack as a store for
long-lived state.) But if we are going to be good little post-GUI
programmers and keep up with a user bouncing hither and thither, and if
we are now saying "call/cc no can do"...hunh?
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:
>
>> Will Hartung wrote:
>>
>>> To me, the problem with the contiuations is how a web application is
>>> interacted with.
>>
>>
>> [...]
>>
>>
>> Thanks a lot for your detailed response!
>
>
> <heh-heh> Now I am really confused. I am no Web app programmer, so I
> have to hold back on my usual level of arrogance, but the stuff Will was
> talking about are the things that struck me as not mapping nicely onto
> continuations.
Yes.
> But everyone seems to be jumping up and down about the
> damn things as perfect for the Web. So I assumed I was missing
> something. Now... I don't know, let's see if someone steps up to
> denounce Will. <g>
>
> I mean, sure, if you have a modal dialog model in which folks enter a
> mode and /EITHER/ continue to the next mode /OR/ quit the mode at hand,
> check, a straight-line script + continuations can model that (I said
> "can", not "should"--I still don't see a call stack as a store for
> long-lived state.) But if we are going to be good little post-GUI
> programmers and keep up with a user bouncing hither and thither, and if
> we are now saying "call/cc no can do"...hunh?
It's hard to read you, especially as a non-native speaker. What's your
question?
More often than not, I tend to use web pages in ways that they were not
intended to be used, and I am always pissed off if that doesn't work,
and always delighted if it works. I think these things are important.
As Kent said stated in this thread, continuations sound like the right
thing at first, and some of the papers out there have convincing
examples. Will has given a good description why this probably is misleading.
Of course, another way could be to avoid web interfaces. With iTunes,
Apple has given a convincing example of a net-based application that
doesn't use a web interface at all.
Just some loosely related thoughts...
Pascal
"Pascal Costanza" <········@web.de> wrote in message
·················@newsreader2.netcologne.de...
> Of course, another way could be to avoid web interfaces. With iTunes,
> Apple has given a convincing example of a net-based application that
> doesn't use a web interface at all.
I am of the opinion that web interfaces are best suited for domains which
have a large number of untrained users doing operations of limited scope for
short periods of time.
That means they're better geared for the Masses, like a store front, but I
think they're just simply utterly horrible for something like, say, the
Accounting department.
iTunes is designed for the masses, but clearly a classic web interface would
fail miserably.
It can be argued that Intrenet Explorer is powerful enough that it can take
on almost "thick client"-esque interfaces, but then you get the grand
benefit of crappy performance (a web hit is simply expensive -- you need to
reload all of those coninuations, among other things :-) ) with no platform
portability (the only real argument for a web interface to begin with,
IMHO). If you mandate IE 6+, or whatever, you may as well mandate VB.DLL or
whatever and be done with it.
Of course, as soon as you dump the browser as an interface you're in the
wonderful world of portable GUI applications (again, see iTunes and how
quickly it came out for Windows...besides the marketing component of
implicit delay...). iTunes Linux anyone? No? Cue Java Rage...
IMHO, for the business world, the only thing the web has really added to the
mix is simply the consideration that you really need to seperate the
business component from the display component, but 99% of the applications
simply don't need that kind of flexibility.
It's not clear to me that the spate of OO methodologies and technologies
when used in the Real World(tm) have been able to convert rigid, static
masses of interdependent procedural code and processes into much of anything
but rigid static masses of interdependent OO code and processes.
There are exceptions, but it seems to me that object models are collapsing
and being raised to the higher level abstraction of simply process models,
with things being handled via work flow and message queues. These models
handle large bits of data and can more easily take on both web and "rich"
interfaces, and they work at a level that human beings can understand. One
big bubble labeled "Payroll".
Thus the push for Web Services, where these monolithic servers handle big
bulky transactions. EDI 12.0. XML payloads. I look over application design,
look at tools, databases, etc, and I wonder why after over 15 years, the
applications remain the same, the tools change, the platforms change, yet
despite all of the "advances", they're still no easier to write. The tools
don't help, and the platforms haven't changed in a dramatic, meaningful way
save adding horsepower.
We're in the age where the local tire dealer is running Linux Desktops at
the counter running a "green screen" application. The green-screen
application peaked in the mid 80's with color displays and pop-up windows.
Now we have GUIs that for most typical back office tasks are absolutely
HORRIBLE to use. The tire dealer runs Linux Desktops mostly so they can also
hit the web and get email.
Having to key in 100 invoices on a modern GUI is absolute Hell. It's bad
enough to have to take the hand off the 10-key pad to get letters, much less
having to reach for the mouse to navigate the bloody screen.
Whoops..sorry...tangential rant...went off my meds....
Nothing Lisp can do to help this I don't think.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> We're in the age where the local tire dealer is running Linux
> Desktops at the counter running a "green screen" application. The
> green-screen application peaked in the mid 80's with color displays
> and pop-up windows. Now we have GUIs that for most typical back
> office tasks are absolutely HORRIBLE to use. The tire dealer runs
> Linux Desktops mostly so they can also hit the web and get email.
>
...
>
> Nothing Lisp can do to help this I don't think.
>
Maybe. I was part of a project in 1994 that did a prototype in Lisp of
a smart client for a green-screen application. One module read in
screens from the application, extracted the data from them, and let you
send filled-in screens back (I believe this is called a "screenscraper"
nowadays). The other module had a CLIM-based GUI that tried to make the
data from the underlying application intelligible to novice users. We
were doing it in Lisp to get the traditional prototyping advantages
(flexibility, fast turnaround, changes with the customers looking on,
etc...).
The real problem with business apps is that when your business logic
changes, it always seems easier and less risky to incrementally hack the
existing application than to flush it and redesign. After a few
iterations, though, you have a classic Crawling Horror whose correct
functioning is now business-critical.
The application we were covering up with our prototype was a perfect
example of this: it had roots going back 20+ years, was absolutely
critical to the sales force of the company, and was so difficult to use
that a three-week training course barely got them up to speed using it.
- Bob
"Bob Bane" <····@removeme.gst.com> wrote in message
·····················@removeme.gst.com...
> Will Hartung wrote:
> > We're in the age where the local tire dealer is running Linux
> > Desktops at the counter running a "green screen" application. The
> > green-screen application peaked in the mid 80's with color displays
> > and pop-up windows. Now we have GUIs that for most typical back
> > office tasks are absolutely HORRIBLE to use. The tire dealer runs
> > Linux Desktops mostly so they can also hit the web and get email.
> > Nothing Lisp can do to help this I don't think.
>
> Maybe. I was part of a project in 1994 that did a prototype in Lisp of
> a smart client for a green-screen application. One module read in
> screens from the application, extracted the data from them, and let you
> send filled-in screens back (I believe this is called a "screenscraper"
> nowadays). The other module had a CLIM-based GUI that tried to make the
> data from the underlying application intelligible to novice users. We
> were doing it in Lisp to get the traditional prototyping advantages
> (flexibility, fast turnaround, changes with the customers looking on,
> etc...).
My issue is mostly with the interfaces in general and how modern ones based
on GUIs are woefully inadequate for typical, back office, mostly clerical
work, and I truly believe that these peaked with you basic green-screen
paradigm. Now, the driver for that is, essentially the age old keyboard vs
mouse argument. Having watched skilled data operators just zing along, I've
always felt that keyboarding skill and expertise is what should be leveraged
to make the interfaces efficient.
Modern "generic" GUIs tend to be poorly navigable by keyboard, and very
visual in their reporting (for errors and such), requiring operators to keep
their eyes on the screen so they can see what they're doing, and to aim the
mouse rather than focus on their documents that they're typically trying to
work from. Lots of hand motion, lots of unpredictablility, lots of
concentration for routine tasks.
Simple examples such as <ENTER> closing the screen vs advancing the
field...just drive folks nuts. In a generic Windows app, you must use your
left hand to advance (TAB), your right hand to key (10 Key) and which hand
to say click a button with the mouse? The TAB key makes sense when your
right hand is on the mouse all the time, but then you question what is tab
for anyway since the mouse can be used instead?
Thus, I feel that for these kind of back office applications, the
green-screen is really the peak and if anything, the modern GUI has shoved
it back.
It's a overall design issue which Lisp can't help, not a language thing at
all.
> The real problem with business apps is that when your business logic
> changes, it always seems easier and less risky to incrementally hack the
> existing application than to flush it and redesign. After a few
> iterations, though, you have a classic Crawling Horror whose correct
> functioning is now business-critical.
>
> The application we were covering up with our prototype was a perfect
> example of this: it had roots going back 20+ years, was absolutely
> critical to the sales force of the company, and was so difficult to use
> that a three-week training course barely got them up to speed using it.
A lot of the complexity with business apps isn't necessarily the interface,
it's the understanding of the business rules going on underneath, and the
fact that as applications evolve the requirments change for new business but
are still there in the application for old business. We had one system that
had four different pricing and discount models as marketing changed it every
season, but the app and to some extent the operators needed to understand
the current ones as well as the older ones.
The dark side of green-screen applications is that the 80x25 screen is in
one sense more than enough, but in others far too small. As business rules
change, many of their effects bubble up to the screen, and typically once
there they are stuck. I've seen several examples of "rotting" fields on the
screen to support data that was entered 3 years ago but is now never used,
yet it sucks up a precious 10 characters of screen real estate. All of that
adds to complexity.
Part of the difficulty in starting over is the baggage of the historical
data which can carry a heavy burden on top of the generic "no time no
budget" constraints. This is very important if some fields are simply
calculated rather than stored, because it means that those calculations and
processes need to be carried forward into the "new" design.
Lisp can help a little here simply because Lisp code tends to have less
momentum both because of its smaller size and its dynamic nature, so change
is a bit easier to make and it can be easier to retarget older processes in
new directions. You still have the business rule problems, but your code
isn't one big static brick wall that can collapsed when changed. Lisp code
can be much more resilient that way, IMHO.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung <·····@msoft.com> wrote:
> "Bob Bane" <····@removeme.gst.com> wrote in message
> ·····················@removeme.gst.com...
> > Will Hartung wrote:
>
> > > We're in the age where the local tire dealer is running Linux
> > > Desktops at the counter running a "green screen" application. The
> > > green-screen application peaked in the mid 80's with color displays
> > > and pop-up windows. Now we have GUIs that for most typical back
> > > office tasks are absolutely HORRIBLE to use. The tire dealer runs
> > > Linux Desktops mostly so they can also hit the web and get email.
>
> > > Nothing Lisp can do to help this I don't think.
> >
> > Maybe. I was part of a project in 1994 that did a prototype in Lisp of
> > a smart client for a green-screen application. One module read in
> > screens from the application, extracted the data from them, and let you
> > send filled-in screens back (I believe this is called a "screenscraper"
> > nowadays). The other module had a CLIM-based GUI that tried to make the
> > data from the underlying application intelligible to novice users. We
> > were doing it in Lisp to get the traditional prototyping advantages
> > (flexibility, fast turnaround, changes with the customers looking on,
> > etc...).
>
> My issue is mostly with the interfaces in general and how modern ones based
> on GUIs are woefully inadequate for typical, back office, mostly clerical
> work, and I truly believe that these peaked with you basic green-screen
> paradigm. Now, the driver for that is, essentially the age old keyboard vs
> mouse argument. Having watched skilled data operators just zing along, I've
> always felt that keyboarding skill and expertise is what should be leveraged
> to make the interfaces efficient.
>
> Modern "generic" GUIs tend to be poorly navigable by keyboard, and very
> visual in their reporting (for errors and such), requiring operators to keep
> their eyes on the screen so they can see what they're doing, and to aim the
> mouse rather than focus on their documents that they're typically trying to
> work from. Lots of hand motion, lots of unpredictablility, lots of
> concentration for routine tasks.
>
> Simple examples such as <ENTER> closing the screen vs advancing the
> field...just drive folks nuts. In a generic Windows app, you must use your
> left hand to advance (TAB), your right hand to key (10 Key) and which hand
> to say click a button with the mouse? The TAB key makes sense when your
> right hand is on the mouse all the time, but then you question what is tab
> for anyway since the mouse can be used instead?
>
> Thus, I feel that for these kind of back office applications, the
> green-screen is really the peak and if anything, the modern GUI has shoved
> it back.
>
> It's a overall design issue which Lisp can't help, not a language thing at
> all.
>
> > The real problem with business apps is that when your business logic
> > changes, it always seems easier and less risky to incrementally hack the
> > existing application than to flush it and redesign. After a few
> > iterations, though, you have a classic Crawling Horror whose correct
> > functioning is now business-critical.
> >
> > The application we were covering up with our prototype was a perfect
> > example of this: it had roots going back 20+ years, was absolutely
> > critical to the sales force of the company, and was so difficult to use
> > that a three-week training course barely got them up to speed using it.
>
> A lot of the complexity with business apps isn't necessarily the interface,
> it's the understanding of the business rules going on underneath, and the
> fact that as applications evolve the requirments change for new business but
> are still there in the application for old business. We had one system that
> had four different pricing and discount models as marketing changed it every
> season, but the app and to some extent the operators needed to understand
> the current ones as well as the older ones.
>
> The dark side of green-screen applications is that the 80x25 screen is in
> one sense more than enough, but in others far too small. As business rules
> change, many of their effects bubble up to the screen, and typically once
> there they are stuck. I've seen several examples of "rotting" fields on the
> screen to support data that was entered 3 years ago but is now never used,
> yet it sucks up a precious 10 characters of screen real estate. All of that
> adds to complexity.
>
> Part of the difficulty in starting over is the baggage of the historical
> data which can carry a heavy burden on top of the generic "no time no
> budget" constraints. This is very important if some fields are simply
> calculated rather than stored, because it means that those calculations and
> processes need to be carried forward into the "new" design.
>
> Lisp can help a little here simply because Lisp code tends to have less
> momentum both because of its smaller size and its dynamic nature, so change
> is a bit easier to make and it can be easier to retarget older processes in
> new directions. You still have the business rule problems, but your code
> isn't one big static brick wall that can collapsed when changed. Lisp code
> can be much more resilient that way, IMHO.
>
> Regards,
>
> Will Hartung
> (·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> The dark side of green-screen applications is that the 80x25 screen is in
> one sense more than enough, but in others far too small. As business rules
> change, many of their effects bubble up to the screen, and typically once
> there they are stuck. I've seen several examples of "rotting" fields on the
> screen to support data that was entered 3 years ago but is now never used,
> yet it sucks up a precious 10 characters of screen real estate. All of that
> adds to complexity.
What do you mean 80x25?
On my bitmap screen, I can show 178x78 in Courier-12 or up to 208x100
in 6x10 font (and I can put them in green on black too).
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
On Thu, 11 Dec 2003 19:19:17 +0100, Pascal Bourguignon wrote:
> On my bitmap screen, I can show 178x78 in Courier-12 or up to 208x100
> in 6x10 font (and I can put them in green on black too).
Quite a luxury, if you are a data entry clerk :-). A lot of extra space
to confuse a user, too!
faa
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> "Will Hartung" <·····@msoft.com> writes:
> > The dark side of green-screen applications is that the 80x25
> > screen is in one sense more than enough, but in others far too
> > small. As business rules change, many of their effects bubble up
> > to the screen, and typically once there they are stuck. I've seen
> > several examples of "rotting" fields on the screen to support data
> > that was entered 3 years ago but is now never used, yet it sucks
> > up a precious 10 characters of screen real estate. All of that
> > adds to complexity.
>
> What do you mean 80x25?
80x24 is what most CRT consoles were a couple of decades ago when
mainframes ruled the world. They were the kind you dialed up on a
modem or acoustic coupler to a mainframe. They today survive
primarily in retail and factory settings.
A few sophisticated CRT's had a 25th line that you could either use as
screen real estate or could allocate specially, e.g., as a process
status line that was not scrolled with the rest of the screen. I
believe the Heathkit H19 and the Ann Arbor Ambassador had this
feature, for example. Probably the higher numbered VTnnn consoles, for
nnn > 100 had it, too. (Not sure about the VT100. The VT52 did not
have it.)
The AAA had the ability to press a key and have it change the size of the
screen font to adjust to 48 and even 60 line high screens. It was also
bright green on dark green/black, whereas most of the other brands were
bright blue/grey on dark grey/black.
Although surely dot-matrix in nature, I don't think anyone really ever
expressed the capacity of these screens in pixels.
> On my bitmap screen, I can show 178x78 in Courier-12 or up to 208x100
> in 6x10 font (and I can put them in green on black too).
As far as I know, bitmap screens are the next generation after what Will
is talking about.
Kent M Pitman <······@nhplace.com> writes:
> 80x24 is what most CRT consoles were a couple of decades ago when
> mainframes ruled the world.
> As far as I know, bitmap screens are the next generation after what Will
> is talking about.
You may have missed a generation in the middle. I recall, during the days
of terminal-character 80x24 screens, being really excited to get access to
a Textronics, with a vector CRT display. Instead of using a frame buffer with
an NxM pixel screen, the display memory was a list of vectors to draw directly.
So the refresh rate slowed down as you drew more lines on the screen.
But: none of that ugly stair-stepping with diagonal lines that we see today.
No need for anti-aliasing!
I think there was a brief surge, in between the 80x24 display and the current
bitmap displays, when vector displays had their day.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I wish my name was Todd, because then I could say, "Yes, my name's Todd. Todd
Blankenship." Oh, also I wish my last name was Blankenship.
-- Deep Thoughts, by Jack Handey
Don Geddis <···@geddis.org> writes:
> I think there was a brief surge, in between the 80x24 display and the
> current bitmap displays, when vector displays had their day.
I have been told that the original version of Asteroids ran on a vector
display.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
>
> Don Geddis <···@geddis.org> writes:
>
> > I think there was a brief surge, in between the 80x24 display and the
> > current bitmap displays, when vector displays had their day.
>
> I have been told that the original version of Asteroids ran on a vector
> display.
yes, it did. I remember it well. Vector graphics were also featured
on several computers from Atari, and there was a time when you had a
choice between a vector graphics card and a raster graphics card as
upgrades for your 8088 ISA machines (which came with a monitor controller
that was only capable of treating the screen as a character array with
a single hardware font).
I also recall seeing vector graphics on an Apple ][ around 1980 or
thereabouts.
Bear
Rahul Jain wrote:
> Don Geddis <···@geddis.org> writes:
>>I think there was a brief surge, in between the 80x24 display and the
>>current bitmap displays, when vector displays had their day.
> I have been told that the original version of Asteroids ran on a vector
> display.
The arcade game emulator MAME supports the old vector displays including
Astereroids. Some time ago hackers took the vector display routines and
made them direct a laser. Then they played the old vector display games
at the side of a tall building.
<http://slashdot.org/article.pl?sid=00/10/27/1236203&mode=nested&tid=126>
--
Jens Axel S�gaard
Don Geddis <···@geddis.org> writes:
> Kent M Pitman <······@nhplace.com> writes:
> > 80x24 is what most CRT consoles were a couple of decades ago when
> > mainframes ruled the world.
> > As far as I know, bitmap screens are the next generation after what Will
> > is talking about.
>
> You may have missed a generation in the middle. I recall, during the days
> of terminal-character 80x24 screens, being really excited to get access to
> a Textronics, with a vector CRT display. Instead of using a frame buffer with
> an NxM pixel screen, the display memory was a list of vectors to draw directly.
> So the refresh rate slowed down as you drew more lines on the screen.
>
> But: none of that ugly stair-stepping with diagonal lines that we see today.
> No need for anti-aliasing!
>
> I think there was a brief surge, in between the 80x24 display and the current
> bitmap displays, when vector displays had their day.
Yes, but nowadays, with LCDs at more than 200 dpi, I can live with
stair-steppings.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Pascal Bourguignon wrote:
>> You may have missed a generation in the middle. I recall, during the
>> days of terminal-character 80x24 screens, being really excited to get
>> access to
>> a Textronics, with a vector CRT display. Instead of using a frame buffer
>> with an NxM pixel screen, the display memory was a list of vectors to
>> draw directly. So the refresh rate slowed down as you drew more lines on
>> the screen.
>>
If you have a linux or unix box:
XTerm (the one from XFree, not konsole or gnome-terminal or the like) can
still emulate such a vector display, though almost everyone just uses it in
vt10x mode, try :
xterm -t -tn tek4014
or acccessing an xterm options menu with ctrl+middlemousebutton.
You might need to install ncurses-extraterms or something too to
get the terminfo for tek4014 - it's not even installed by default
on most linux distros anymore...
Plus, you have to manually tell it to clear the screen with "clear"
or with the ctrl-mmb menu - you'll rapidly get rubbish with normal
vt-oriented command line tools as new output overwrites old output without
erasing the old output.
You really need some programs with tek-specific output capability to try it
out on - try GNU plotutils (not the same package as gnuplot at all!).
(in xterm tek window, with plotutils installed:)
echo "0 0 2 2 1 1 2 0" | graph -Ttek
Whammo, out pops a graph. Immediate gratification for people wanting vector
graphical output with no fuss. SO much easier than today :-)
Er... Lisp... Right... well... one COULD write a tektronix output library
for Common Lisp... I guess...
Pascal Bourguignon wrote:
> Yes, but nowadays, with LCDs at more than 200 dpi, I can live with
> stair-steppings.
Is it possible to get an LCD monitor (standalone or in a laptop)
whose resolution is better than 200dpi for less than, say, $5000?
--
Gareth McCaughan
.sig under construc
>>>>> "GMcC" == Gareth McCaughan <·····@g.local> writes:
[...]
GMcC> Is it possible to get an LCD monitor (standalone or in a
GMcC> laptop) whose resolution is better than 200dpi for less
GMcC> than, say, $5000?
Yes, I remember seeing a fancy IBM for about that in late 2002 at their
online store as a special. I don't remember if it was the T-221 or a
previous model. I am sure deals like that can be had both on that and the
Viewsonic one. Of course <$5k is hardly a deal. I expect they'll be
down in the $2-3k-ish range by the end of 2005. Sooner, if, by some magic,
people understand the monitor is the most important part of a desktop system.
cheers,
BM
Gareth McCaughan <·····@g.local> writes:
> Pascal Bourguignon wrote:
>
> > Yes, but nowadays, with LCDs at more than 200 dpi, I can live with
> > stair-steppings.
>
> Is it possible to get an LCD monitor (standalone or in a laptop)
> whose resolution is better than 200dpi for less than, say, $5000?
Last price I saw was between 8000 and 9000 euros. At least, they're available.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
From: Christopher C. Stacy
Subject: Re: Application Dynamics [was Re: Scheme vs Lisp!]
Date:
Message-ID: <ur7z9qpjp.fsf@news.dtpq.com>
>>>>> On 12 Dec 2003 13:07:37 -0800, Don Geddis ("Don") writes:
Don> during the days of terminal-character 80x24 screens, being
Don> really excited to get access to a Textronics, with a vector CRT
The Tektronix displays were storage tubes: they were write-once.
After you had put something on the screen, you had to not only
clear the vector display memory, but also de-gauss the screen.
There was a button on the keyboard that did that.
Quite dramatic on the dark!
The one I used (ca 1979) also had a cool electrostatic printer.
When using the Tektronix as a regular terminal (as opposed to its
intended purpose as a special graphics display device, for maps),
I used to display longer pages than 24 lines on the thing,
but not wider lines, because of course all the files were
formatted for 80 columns. And if I made them longer than 80,
nobody including myself would be able to read them on any other
terminal. There was only 1 Tektronix at our facility, although
we had hundreds of various other kinds of CRTs and printing terminals.
······@news.dtpq.com (Christopher C. Stacy) writes:
> The Tektronix displays were storage tubes: they were write-once.
> After you had put something on the screen, you had to not only
> clear the vector display memory, but also de-gauss the screen.
In fairness, there as also the issue of de-gaussing one's eyes, at
least if these were at all like the dm imlacs, since after a while,
the image would hang on your eyes after leaving the screen, especially
if you used these kinds of things in the dark.
Geez, for that matter, I used to clear my Ann Arbor Ambassador screen
ahead of when I needed to read it, figuring the afterimage would persist
long enough for me to read or copy down the rest of what I was looking at.
(sigh)
Don Geddis <···@geddis.org> writes:
> You may have missed a generation in the middle. I recall, during the days
> of terminal-character 80x24 screens, being really excited to get access to
> a Textronics, with a vector CRT display. Instead of using a frame buffer
> with an NxM pixel screen, the display memory was a list of vectors to draw
> directly.
No, I _think_ I just left it out intentionally. I'm familiar with Imlacs,
which had this display model, too. We used to play MAZE (probably the
earliest version of the "hunt down and kill things in a maze" game) on the
DM (DynaMod or Dynamic Modeling) pdp10 (the one that developed Zork).
It was multi-user and had some of the most low-tech graphics I ever saw, but
it was able to draw hallways in nice perpective. It used two dots for eyes
facing you, or an arrow left, right, or up for the other directions, with a
name under the dots or eyes in appropriate size for the distance.
But I considered them an orthogonal branch of console development, not
time-ordered in this 80x24 thing, since screen models today are mostly not
vector-oriented.
> So the refresh rate slowed down as you drew more lines on the screen.
Heh.
> But: none of that ugly stair-stepping with diagonal lines that we see today.
> No need for anti-aliasing!
Yep.
> I think there was a brief surge, in between the 80x24 display and the current
> bitmap displays, when vector displays had their day.
The imlac was certainly concurrent with 80x24 vt52's, and might have predated
them... not sure.
From: Christopher Jeris
Subject: Re: Application Dynamics [was Re: Scheme vs Lisp!]
Date:
Message-ID: <uznduuife.fsf@oinvzer.net>
Don Geddis <···@geddis.org> writes:
> You may have missed a generation in the middle. I recall, during
> the days of terminal-character 80x24 screens, being really excited
> to get access to a Textronics, with a vector CRT display. Instead
> of using a frame buffer with an NxM pixel screen, the display memory
> was a list of vectors to draw directly. So the refresh rate slowed
> down as you drew more lines on the screen.
Did these vector tubes have a much shorter life than raster CRTs?
That was an issue for arcade manufacturers and operators in the early
80s when Atari, Sega et al made a number of excellent games on vector
monitors. But I don't know whether they chose less reliable monitor
models for the harsh conditions of a video arcade, or whether the
vector technology was intrinsically less robust.
--
Chris Jeris ······@oinvzer.net Apply (1 6 2 4)(3 7) to domain to reply.
From: Karl A. Krueger
Subject: Re: Application Dynamics [was Re: Scheme vs Lisp!]
Date:
Message-ID: <brnbe6$7h5$1@baldur.whoi.edu>
Christopher Jeris <······@oinvzer.net> wrote:
> Did these vector tubes have a much shorter life than raster CRTs?
> That was an issue for arcade manufacturers and operators in the early
> 80s when Atari, Sega et al made a number of excellent games on vector
> monitors. But I don't know whether they chose less reliable monitor
> models for the harsh conditions of a video arcade, or whether the
> vector technology was intrinsically less robust.
I never saw a "Star Wars" vector-graphics arcade game that _hadn't_
burned through the screen in the middle, thanks to the fantastically
hardware-abusive Death Star explosion.
(When you blow up the Death Star, the explosion is drawn as a huge
number of concentric polygons -- or a very dense spiral? -- centered on
the screen, at maximum brightness, sustained for several seconds. Over
the life of the machine, this leads to (what looks like, at least) the
center phosphors being burned away, leaving a small ragged hole through
the phosphor screen.)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
* Pascal Bourguignon wrote:
> On my bitmap screen, I can show 178x78 in Courier-12 or up to 208x100
> in 6x10 font (and I can put them in green on black too).
Unfortunately millions of years of evolution mean that it's rather
hard for people to read lines that are significantly longer than
~10-12 words, or about 80 characters in a fixed pitch font. And it's
rather hard to read anything at all in a 6x10 font.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Pascal Bourguignon wrote:
>
> > On my bitmap screen, I can show 178x78 in Courier-12 or up to 208x100
> > in 6x10 font (and I can put them in green on black too).
>
> Unfortunately millions of years of evolution mean that it's rather
> hard for people to read lines that are significantly longer than
> ~10-12 words, or about 80 characters in a fixed pitch font. And it's
> rather hard to read anything at all in a 6x10 font.
Don't be silly!
I'm not expecting you to design you TUI with lines 178-character wide!
Just use the real estate to show the various 40 or 60-character wide
fields in serveral columns.
Some emacs lisp:
(defun double-window ()
"Enlarge the frame, and split it horizontally in two 80-column windows."
(interactive)
(let ((*current-frame* (car (frame-list))))
(set-frame-width *current-frame* 167)
(set-frame-position *current-frame* 0 0)
(delete-other-windows)
(split-window-horizontally 86)
(other-window 1)
(switch-to-buffer
(do ((buffers (buffer-list) (cdr buffers)))
((or (null buffers)
(not (or (position (char (buffer-name (car buffers)) 0) " *")
(equal (current-buffer) (car buffers)))))
(car buffers))))
));;double-window
(defun single-window ()
"Reduce the frame, to one 80-columns window."
(interactive)
(let ((*current-frame* (car (frame-list))))
(set-frame-width *current-frame* 81)
(set-frame-position *current-frame* -64 0)
(delete-other-windows)
));;single-window
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Will Hartung wrote:
>>>
>>>> To me, the problem with the contiuations is how a web application is
>>>> interacted with.
>>>
>>>
>>>
>>> [...]
>>>
>>>
>>> Thanks a lot for your detailed response!
>>
>>
>>
>> <heh-heh> Now I am really confused. I am no Web app programmer, so I
>> have to hold back on my usual level of arrogance, but the stuff Will
>> was talking about are the things that struck me as not mapping nicely
>> onto continuations.
>
>
> Yes.
>
>> But everyone seems to be jumping up and down about the damn things as
>> perfect for the Web. So I assumed I was missing something. Now... I
>> don't know, let's see if someone steps up to denounce Will. <g>
>>
>> I mean, sure, if you have a modal dialog model in which folks enter a
>> mode and /EITHER/ continue to the next mode /OR/ quit the mode at
>> hand, check, a straight-line script + continuations can model that (I
>> said "can", not "should"--I still don't see a call stack as a store
>> for long-lived state.) But if we are going to be good little post-GUI
>> programmers and keep up with a user bouncing hither and thither, and
>> if we are now saying "call/cc no can do"...hunh?
>
>
> It's hard to read you, especially as a non-native speaker.
Don't worry, native speakers cannot understand me either.
> What's your
> question?
I could have sworn you demanded to know "who is to say continuations are
not appropriate for a given application?"
So the correct answer was "Will"?
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Pascal Costanza <········@web.de> writes:
> 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?
But this is just as crappy as most non-continuation-using solutions!
I don't understand why so many people (who use GC'ed languages, too)
think that adding continuations makes it okay. Continuations are the
right *model*, but the wrong implementation technique. If you have to
manually track how long a continuation is reachable, and guess at when
it's okay to delete it, it should be obvious that this is a Big Sign
that Something Is Very Wrong. Instead, arrange it so that the
requests the browser makes reconstruct the state of computation up to
that point -- then you only need timeouts if they're semantically
necessary, not just to support an implementation technique. The job
of the web-app frameowrk should be to make this saving/reconstruction
of "continuations" painless for the programmer.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> But this is just as crappy as most non-continuation-using solutions!
> I don't understand why so many people (who use GC'ed languages, too)
> think that adding continuations makes it okay. Continuations are the
> right *model*, but the wrong implementation technique. If you have to
> manually track how long a continuation is reachable, and guess at when
> it's okay to delete it, it should be obvious that this is a Big Sign
> that Something Is Very Wrong. Instead, arrange it so that the
> requests the browser makes reconstruct the state of computation up to
> that point -- then you only need timeouts if they're semantically
> necessary, not just to support an implementation technique. The job
> of the web-app frameowrk should be to make this saving/reconstruction
> of "continuations" painless for the programmer.
>
You may want to read "Automatically Restructuring Programs for the Web"
-- http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.pdf
Basically, the authors are using CPS, lambda lifting and
defunctionalization to automatically restructure the program, so that
the continuation is actually saved in the browser.
--
Ivan Toshkov
email: ··········@last-name.org
Ivan Toshkov wrote:
> You may want to read "Automatically Restructuring Programs for the Web"
> -- http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.pdf
>
> Basically, the authors are using CPS, lambda lifting and
> defunctionalization to automatically restructure the program, so that
> the continuation is actually saved in the browser.
Ivan, you don't seem to understand that this is usenet.
If you can't defend your opinions and intimidate your
opponents without referring to scholarly articles or
actual facts, then you don't belong here.
;)
So long as I'm posting nonsense, I'll add a couple more
links to papers that are related to the one Ivan cited:
Graunke, Findler, Krishnamurthi, Felleisen.
Modeling Web Interactions.
http://www.ccs.neu.edu/scheme/pubs/esop2003-gfkf.pdf
Felleisen. Developing Interactive Web Programs.
http://www.ccs.neu.edu/scheme/pubs/afp2002-f.ps
Will
From: Kent M Pitman
Subject: Re: Scheme vs Lisp! [was Re: web application framework]
Date:
Message-ID: <wk1xsdb9qr.fsf@nhplace.com>
Pascal Costanza <········@web.de> writes:
> > 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?
If you associated time to live with a continuation, then I suppose
it might be bludgeoned into working. But you can't go back and reanalyze
your decision about how much time to keep soemthing because you have lost
the original higher level information. What if some customers get more
time than others? Or some get infinite time? Or some merely bump others.
What if each customer should get only one session, and finding that someone
comes in over another channel means they have dropped the session early.
And on and on. Continuations can be associated with this information,
but are not primitively equipped to handle the information. To the extent
that you work around the problem, you are saying that continuations didn't
buy you what you needed.
> 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?
This would be inspecting a program instead of inspecting data, at some
level. I don't want to use (symbol-value-in-instance x 'user)
I want to use (session-owner session), if that helps.
> > - 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?
I'm saying that continuations do not, in a first class way, represent the
kinds of sharing that, say, a database does. If I am half-way through a
dialog that asks my home phone number and I happen to have an unrelated
session open to the same database and I haven't gotten to the part that
asks my phone number, a database would still show that it knew my phone
number, whereas a continuation might insist on asking me a second time.
Of course, you can construct a continuation not to rely on closure
information but to go back to the DB all the time. But the more you do
this, the less like a continuation it becomes and the more it vanishes
to nothingness. It is not a process. If it is not data storage either,
then what is it? Just a pointer into a set of things to make sure you
have asked...which is not the same as a set of things to ask.
> 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 ;)
Different means, yes. Macros, hmm. I dunno. I don't think that's what I'd
use. But I'm not sure I want to explain what I'd offer as an alternative.
Not at this time in this venue. Something I might write about in another
venue at another time. Sorry. I'm just saying that continuations are too
rigid. The term "procedural embedding of information" really captures the
critical side of what I'm trying to say. I guess either you understand
and believe that or you don't. If you are thinking "well, I just don't
know anything better to do", then I guess I'd say I think you're on the
wrong track if you're thinking about having the process be precoded at
compile time rather than dynamically planned.
> Or would you rather say that complex web applications need complex code,
> end of story?
No. I definitely would not say that.
In article <··············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> The term "procedural embedding of information" really captures the
> critical side of what I'm trying to say.
So would it be fair to characterize one of your objections as:
continuations store state implicitly, while other methods (CLOS objects,
for example) store state explicitly?
Just asking for clarification, because that's what I'm hearing, but it
may be because that's what I dislike about continuations myself. I
dislike methodologies that store information implicitly because they
make debugging more difficult.
Raf
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
>> The term "procedural embedding of information" really captures the
>> critical side of what I'm trying to say.
>
> So would it be fair to characterize one of your objections as:
> continuations store state implicitly, while other methods (CLOS objects,
> for example) store state explicitly?
>
> Just asking for clarification, because that's what I'm hearing, but it
> may be because that's what I dislike about continuations myself. I
> dislike methodologies that store information implicitly because they
> make debugging more difficult.
Things like lexical scoping and aggregate data, for example.
--
~jrm
Joe Marshall wrote:
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>
>
>>In article <··············@nhplace.com>,
>> Kent M Pitman <······@nhplace.com> wrote:
>>
>>
>>>The term "procedural embedding of information" really captures the
>>>critical side of what I'm trying to say.
>>
>>So would it be fair to characterize one of your objections as:
>>continuations store state implicitly, while other methods (CLOS objects,
>>for example) store state explicitly?
>>
>>Just asking for clarification, because that's what I'm hearing, but it
>>may be because that's what I dislike about continuations myself. I
>>dislike methodologies that store information implicitly because they
>>make debugging more difficult.
>
>
> Things like lexical scoping and aggregate data, for example.
I guess you mean aggregate data types, right? What's implicit about them?
Pascal
Pascal Costanza <········@web.de> writes:
> Joe Marshall wrote:
>
>> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>>
>>>In article <··············@nhplace.com>,
>>> Kent M Pitman <······@nhplace.com> wrote:
>>>
>>>
>>>>The term "procedural embedding of information" really captures the
>>>>critical side of what I'm trying to say.
>>>
>>>So would it be fair to characterize one of your objections as:
>>> continuations store state implicitly, while other methods (CLOS
>>> objects, for example) store state explicitly?
>>>
>>> Just asking for clarification, because that's what I'm hearing, but
>>> it may be because that's what I dislike about continuations
>>> myself. I dislike methodologies that store information implicitly
>>> because they make debugging more difficult.
>> Things like lexical scoping and aggregate data, for example.
>
> I guess you mean aggregate data types, right? What's implicit about them?
When you pass them as arguments you implicitly get the entire aggregate.
If you wanted to be explicit, you would destructure the aggregate
at function boundaries.
Joe Marshall wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Joe Marshall wrote:
>>
>>
>>>Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>>>
>>>
>>>>In article <··············@nhplace.com>,
>>>>Kent M Pitman <······@nhplace.com> wrote:
>>>>
>>>>
>>>>
>>>>>The term "procedural embedding of information" really captures the
>>>>>critical side of what I'm trying to say.
>>>>
>>>>So would it be fair to characterize one of your objections as:
>>>>continuations store state implicitly, while other methods (CLOS
>>>>objects, for example) store state explicitly?
>>>>
>>>>Just asking for clarification, because that's what I'm hearing, but
>>>>it may be because that's what I dislike about continuations
>>>>myself. I dislike methodologies that store information implicitly
>>>>because they make debugging more difficult.
>>>
>>>Things like lexical scoping and aggregate data, for example.
>>
>>I guess you mean aggregate data types, right? What's implicit about them?
>
>
> When you pass them as arguments you implicitly get the entire aggregate.
> If you wanted to be explicit, you would destructure the aggregate
> at function boundaries.
Ah, ok! But this means there are several "degrees" of implicitness. For
example, for lexical closures, it's rather hard to get at the local
variables from the outside, unless you have explicitly provided a way to
do that. Whereas for aggregate data, you have functions that determine
the number of elements, and ways to iterate over the data.
Pascal
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > The term "procedural embedding of information" really captures the
> > critical side of what I'm trying to say.
>
> So would it be fair to characterize one of your objections as:
> continuations store state implicitly, while other methods (CLOS objects,
> for example) store state explicitly?
If by methods, you mean "means" or "techniques", then this seems an
partial restatement of what I said, yes. (If you mean literally
"methods", as in the CL datatype, then something is confused.)
In fact, part of what explicit/implicit mean in this case is that in the
case of a continuation, all you can do is invoke it. While in the case
of an object with so-called explicit state, you can invoke a variety of
independent methods that serve different functions. (Yes, yes, I can hear
someone saying that the continuation might take as an arg a message name
and parameters, and might therefore be "method-like" but this is a weak
and contrived definition of explicit. It requires cooperation and is
possible to get wrong. Nor can one trust a continuation for which one does
not know the pedigree to behave this way... For that matter, you probably
can't even tell functions from continuations, which is somewhat the point
of continuations.)
> Just asking for clarification, because that's what I'm hearing, but it
> may be because that's what I dislike about continuations myself. I
> dislike methodologies that store information implicitly because they
> make debugging more difficult.
Could be. It's often the case that our brains recognize "bad patterns"
faster than we can articulate names for them. That's why intuition is
so odd--there's part of your brain just saying "that looks right" when
you see something even though you've not yet named it.
Kenny Tilton wrote:
> Alexander Schmolck wrote:
>> Marco Antoniotti <·······@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
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 <······@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 >
On Fri, 7 Nov 2003 ·······@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.
From: Marco Baringer
Subject: Re: web application framework
Date:
Message-ID: <m2fzgzz0xq.fsf@bese.it>
Adrian Kubala <······@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 <······@sixfingeredman.net> wrote in message news:<·······························@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
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 <······@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 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.
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*)
On Sat, 8 Nov 2003, Anthony Ventimiglia wrote:
> Adrian Kubala <······@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.
Adrian Kubala <······@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
"Marc Spitzer" <········@optonline.net> wrote in message
···················@bogomips.optonline.net...
> Adrian Kubala <······@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
(·····@msoft.com)
Adrian Kubala <······@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*)
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.
Vladimir S. <·································@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
Shriram Krishnamurthi <··@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."
On Mon, 10 Nov 2003, Vladimir S. wrote:
> Shriram Krishnamurthi <··@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.
"Adrian Kubala" <······@sixfingeredman.net> wrote in message
······································@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
(·····@msoft.com)
On Mon, 10 Nov 2003, Will Hartung wrote:
> "Adrian Kubala" <······@sixfingeredman.net> wrote in message
> ······································@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.
"Adrian Kubala" <······@sixfingeredman.net> wrote in message
······································@sixfingeredman.net...
> On Mon, 10 Nov 2003, Will Hartung wrote:
> > 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.
Actually the macros will shroud the details, but the problem remains. Since
the macro encapsulates logic, if that logic doesn't "do what you want", then
all of a sudden the macro is basically worthless. The side effect is that
the higher level the macro (i.e. the more funcionality it conceals), the
more work you have to do should you choose to work around it. Whether its a
macro or a function is pretty irrelevant (though you can cheat and
macroexpand the macro to "steal" its output and hack it directly, that's
difficult to do with a function).
So, granularity is very important.
>
> > [...] 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.
More like an automatic patching system. Rather than writing source code,
you're essentially writing patches to the generated code. It does sound
crude, and in many ways is, but since the generated code is well structured
it's not as painful as it sounds.
> > 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.
Perhaps data-model dependent is a better word, but it turns out that SQL
databases are fabulous places to store data models of relational databases.
You always have synchronization issues no matter what (whether between you
model and you database, or you development DB and the production DBs).
> > 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.
I have a gut feeling that you're overcomplicating things, but I'm basically
lazy.
I'm partial to a fine grained object model with a generated core mostly
because it, in the end, exposes all of the functionality to you in a form
where you can actually do something to change the behavior: source code.
Your application (or application component as in "Customer Maintenance" vs
"E-Commerce Suite") is broken in to the three components. The common core
shared by all similar components, the schema centric generated scut code,
and the specializations that make the default app work the way you want.
As long as your app modules follow all of the assumptions of the framework,
everything is easy. But many times, you'll find that your app needs to
"bend" the model a little bit.
If that model is rigid, it doesn't bend at all and you get to throw the
whole thing out for minor deviations. When the model is exposed as higher
level macros and functions, it can actually be quite rigid. Same problem
with a reflection based system, because a lot of the internal mechanism of
the application is actually hidden by automated processes relying on meta
data. And if that meta data doesn't convey some detail that you find
imporant for a specific case, blammo, out goes the introspection and
reflection. If that bit is actually critical to what you need to do, say for
one particular field of the table, then not only did you lose the automation
for that one field, you lost it for the entire table. The goal is not to
have to adapt the core engine to the variances of your application. If the
core engine is completely off base, then sure, changes may be justified.
However, say for example you have 50 simple database tables that need to be
maintained, but 1 of them is actually two tables combined (and you, say,
don't have an updateable view on your DB which may solve that problem
elegantly). It can be argued that the core system designed to make creating
maintenance programs for single tables is flawed because it can't handle
this "two table" solution. A lot of folks would have to lose the tool
completely because of this, or complicate that system to handle the rare two
table case (and, no doubt, probably punish the other 49 single table
examples to handle the new more general case).
But if you can take ownership of a couple of core pieces of the engine for
this case, then you have one minorly tweaked black sheep program in the sea
of 50 that can still leverage the system in other ways.
A fine grained model will give you that flexibility, specializing the bits
that need it. It also gives the more advanced APPLICATION programmers that
power without them having to rewrite core macros or tweak code walkers. They
just need a solid understanding of the model.
So, automation is good, source code is better, but automatic source code is
the best.
This doesn't eliminate the need for functions and macros to implement low
level parts of the engine, things that simply should not be changed for the
sake of an application, but the goal is to have something that lets the app
writers leverage the tool, bend it as much as possible and have to punt on
only the real fringe of the domain.
Let the users throw away small parts of the engine and tool, rather than
make them throw it away entirely.
It's a fine balance, because flexibility comes at a cost in complexity, and
the whole point is to make the process as simple as practical.
Regards,
Will Hartung
(·····@msoft.com)
Seems the thing that I feared the most has come to pass :). I
specifically neglected to mention databases in my original post on the
assumption that Adrian just wanted an app to marshall stuff from some
SQL-speaking relational database to HTML and back. Boilerplate code is
exactly the thing I had in mind.
I've never had to do anything of the complexity Will is describing,
but Shiro Kawai has (and beyond), and he's written a couple of papers
on how he handled it with Common Lisp:
http://www.lava.net/~shiro/articles-e.html
(see specifically "Shooting a moving target" and "Tracking assets")
One thing to notice is the way he handled changes in the model:
modifying base classes wasn't just an option, it was the best option
(and I think this is true for less complicated/dynamic systems as
well).
Draw your own conclusions from these papers, but if there's one thing
you should come away with, it is this:
Stop worrying and learn to love the CLOS :)
Vladimir Sedach
Adrian Kubala <······@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