Hi,
Does UFFI allow you to integrate with C++ code or only C code? Many
other languages seem to only have clear interfacing libs for C, even
though C++ is more common for certain larger codebases. Is UFFI
relatively easy to use, or a P.I.T.A.? (In comparison to, say, SWIG?)
If our funding comes thru, we may be BUYING an NLP product that is
written in C++ instead of (trying) to build our own. Is UFFI basically
the same across different Lisp implemenations, or...? We have no idea
how it works at all.
In the same vein, why don't Lispers take advantage of more pre-existing
codebases? Python's growth seems to have been fueled, in large part,
by the ease of assimilating existing libraries thru the use of SWIG
etc., yet this doesn't seem to happen much with Lisp...? Is there a
practical reason, or is it just the "roll your own" culture thing?
All of the examples of domain specific languages I have seen in Lisp
keep the lispy syntax. Can anyone point me to examples of a DSL that
uses, say, a BASIC or C-style syntax (or is that even possible)?
Lisp OO seems to not really have encapsulation. Is it possible to
'enforce' encapsulation in Lisp? If Alan Kay modeled Smalltalk in
Lisp, as I've been told, I would think this is possible if desired?
Is CAPI from Lispworks a pretty good GUI library, or is their another
toolkit that allows for more native-looking GUIs? Major downsides to
CAPI? Is it possible to tie Lisp together with a standard desktop GUI
building tool (Delphi, VB, etc.), while still retaining the dynamic
benefits of Lisp? Lisp as .DLL or whatever, only multi-platform?
Is there a great deal of practical difference between the various Lisp
implementations as far as actually writing code? While I prefer the
Smalltalk editors in many ways, Lisp has an advantage in this regard as
far as consistency (emacs or emacs clone.) The VisualWorks and Dolphin
IDEs, frameworks, and class libraries are all just different enough
from one another that I feel like I'm completely starting over when I
try to move from one to another. Lispers seem to have less trouble
moving between implementations than Smalltalkers, but is that only once
you've mastered most of the language? Someone sent me a private email,
for example, that said that LW had an unusual MOP implementation...?
Has UnCommon SQL reached the functional level or Common SQL, or is it
necessary to buy Common SQL (LW Enterprise) if you are doing lots of DB
work?
Are there any fully OO databases available for Lisp? Our UIUC coder
has a novel solution to one of our problems, but it relies on the use
of Omnibase or Gemstone OO databases. Lispers seem to mainly use just
relational or "object-relational" databases...presumably because of the
multi-paradigm approach to coding?
Seaside has a larger community and better documentation that UnCommon
Web, but that tells me little about their functional equivalence and
maturity. I know of several companies using Seaside for commercial
products NOW, but UCW use seems harder to find.
Since Seaside/Smalltalk has 'native' support for continuations it means
that they work "no matter what piece of code you're using them in,
whereas UCW can only simulate them for code directly under its control.
This comes into play in areas like the interaction between
continuations and exception handling: Seaside, for example, has
exceptionally good debugging support for a web framework because you
can backtrack to an error page and start it over inside the debugger as
many times as you like. I doubt this is possible to duplicate in UCW.
In general, you will potentially run into problems with UCW any time
you callback from non-UCW code into UCW code." (Unattributed quote from
private email received from one of my new programming heroes.) Since
I'm a complete newbie, I don't understand all of the real implications
of this. It seems that keeping things straight in UCW as a newbie
would outweigh some of the advantags of the abstraction to begin with.
Can anyone compare and contrast UCW and Seaside for me?
Many thanks in advance,
Sergei
From: Peter Seibel
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <m33bwnxysd.fsf@javamonkey.com>
·······@runbox.com writes:
> Hi,
>
> Does UFFI allow you to integrate with C++ code or only C code?
Only C, but that's the fault of C++ not UFFI. (Lookup "name mangling"
and "extern C" in a C++ context to understand why.)
> Many other languages seem to only have clear interfacing libs for C,
> even though C++ is more common for certain larger codebases.
See above. The typical maneuver is to write a a thin C wrapper around
the C++ API you want to use and then use whatever facilities your
language has for calling out to C to link to that.
> Is UFFI relatively easy to use, or a P.I.T.A.? (In comparison to,
> say, SWIG?) If our funding comes thru, we may be BUYING an NLP
> product that is written in C++ instead of (trying) to build our own.
> Is UFFI basically the same across different Lisp implemenations,
> or...? We have no idea how it works at all.
It is the same across implementations. I've never used it in anger
myself but it seems that within its lowest-common-denominator
limitations (e.g. no callbacks from C to Lisp) it's straight forward
to use. It doesn't provide access to all the features provided the
"native" FFIs of different Lisp's. Of course if you've got cash you
can buy a license for Allegro and just use SWIG to generate Allegro
FFI code.
> In the same vein, why don't Lispers take advantage of more
> pre-existing codebases? Python's growth seems to have been fueled,
> in large part, by the ease of assimilating existing libraries thru
> the use of SWIG etc., yet this doesn't seem to happen much with
> Lisp...? Is there a practical reason, or is it just the "roll your
> own" culture thing?
I think your premise may be wrong. My guess is that the reason there
are so many Python bindings for C libs is because there are
(presently) so many Python programmers. Basically libs get wrapped
when someone needs them and the more folks are using a language the
more likely that someone will need some lib. I think Lispers are
generally fine with wrapping existing libs if that's the quickest way
to get the job done. Kenny alone has wrapped just about every lib
under the sun having anything to do with generating pretty pictures or
annoying sounds as part of his Cello project. However there is the
issue--assuming you buy the premise that not all languages are equally
powerful--that there are certain libs that aren't worth wrapping in
Lisp that are worth wrapping in a less powerful language because it's
easier to write a Lisp version than to wrap an existing lib. (I guess
I'm also assuming that most of the cost of wraping a lib--in any
language--comes from trying to understand the library and thus will be
pretty much the same between languages.)
> All of the examples of domain specific languages I have seen in Lisp
> keep the lispy syntax. Can anyone point me to examples of a DSL that
> uses, say, a BASIC or C-style syntax (or is that even possible)?
It's possible. It's just generally not as useful because you can't
incorporate it seemlessly into a Lisp program. I.e. you end up with a
stand alone DSL rather than an embeddable DSL. Also writing a parser
for a non-sexp based language is a (relative) lot of work for little
gain.
> Lisp OO seems to not really have encapsulation. Is it possible to
> 'enforce' encapsulation in Lisp? If Alan Kay modeled Smalltalk in
> Lisp, as I've been told, I would think this is possible if desired?
Depends what you mean by enforce. If you mean it the way C++ and Java
folks mean it, no. Then again neither does Smalltalk since all methods
are "public".
> Is there a great deal of practical difference between the various
> Lisp implementations as far as actually writing code? While I prefer
> the Smalltalk editors in many ways, Lisp has an advantage in this
> regard as far as consistency (emacs or emacs clone.) The VisualWorks
> and Dolphin IDEs, frameworks, and class libraries are all just
> different enough from one another that I feel like I'm completely
> starting over when I try to move from one to another. Lispers seem
> to have less trouble moving between implementations than
> Smalltalkers, but is that only once you've mastered most of the
> language? Someone sent me a private email, for example, that said
> that LW had an unusual MOP implementation...?
For things specified by the language standard implementations are
largely interchangable. (And getting more so thanks to Paul Dietz's
test suite.) But each implementation provides its own extensions that
may or may not be of use to you.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Friedrich Dominicus
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <877jlzutzb.fsf@q-software-solutions.de>
Peter Seibel <·····@javamonkey.com> writes:
> It is the same across implementations. I've never used it in anger
> myself but it seems that within its lowest-common-denominator
> limitations (e.g. no callbacks from C to Lisp) it's straight forward
> to use. It doesn't provide access to all the features provided the
> "native" FFIs of different Lisp's. Of course if you've got cash you
> can buy a license for Allegro and just use SWIG to generate Allegro
> FFI code.
Have you checked the latest LispWorks. It does not need SWIG, it has a
feature which write all that wrappers for you "built-in". Of course it
uses the lw:ffi
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Is it possible for Swig to autogenerate a C wrapper as well as the LISP
wapper around the C required to wrap the C++? It seems to work for
Chicken and TinyClos, so conceptually, at least couldn't Swig handle
UFFI and CLOS?
Or am I betraying some ignorance here?
Peter Seibel wrote:
> ·······@runbox.com writes:
>
> > Hi,
> >
> > Does UFFI allow you to integrate with C++ code or only C code?
>
> Only C, but that's the fault of C++ not UFFI. (Lookup "name mangling"
> and "extern C" in a C++ context to understand why.)
>
> > Many other languages seem to only have clear interfacing libs for
C,
> > even though C++ is more common for certain larger codebases.
>
> See above. The typical maneuver is to write a a thin C wrapper around
> the C++ API you want to use and then use whatever facilities your
> language has for calling out to C to link to that.
>
>
> -Peter
>
> --
> Peter Seibel
·····@javamonkey.com
>
> Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Edi Weitz
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <uekg5a9w0.fsf@agharta.de>
On 28 Jan 2005 06:41:42 -0800, "JohnFredCee" <·····@yagc.ndo.co.uk> wrote:
> Is it possible for Swig to autogenerate a C wrapper as well as the
> LISP wapper around the C required to wrap the C++? It seems to work
> for Chicken and TinyClos, so conceptually, at least couldn't Swig
> handle UFFI and CLOS?
SWIG can generate FFI code for Allegro Common Lisp, so it should be
possible to extend that to other Common Lisp implementations.
<http://www.franz.com/support/tech_corner/swig042804.lhtml>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Edi Weitz
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <uacqta9tk.fsf@agharta.de>
On Fri, 28 Jan 2005 15:47:11 +0100, Edi Weitz <········@agharta.de> wrote:
> SWIG can generate FFI code for Allegro Common Lisp, so it should be
> possible to extend that to other Common Lisp implementations.
>
> <http://www.franz.com/support/tech_corner/swig042804.lhtml>
Oops, at the bottom of that page they specifically exclude C++
classes...
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Peter Seibel
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <m3wttxqt3o.fsf@javamonkey.com>
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> Is it possible for Swig to autogenerate a C wrapper as well as the LISP
> wapper around the C required to wrap the C++? It seems to work for
> Chicken and TinyClos, so conceptually, at least couldn't Swig handle
> UFFI and CLOS?
I don't think so. The reason the C wrapper is needed in the first
place is because C++ compilers mangle names in
implementation-dependent ways (unless a chunk of code is wrapped in
"extern C"). So SWIG has no more insight into what C++ compiler you,
or whovever compiled the library you want to wrap, use. At least
that's my understanding--I try to avoid actual contact with C++.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: John Thingstad
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <opslcedgzvpqzri1@mjolner.upc.no>
On Fri, 28 Jan 2005 18:58:43 GMT, Peter Seibel <·····@javamonkey.com>
wrote:
> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>
>> Is it possible for Swig to autogenerate a C wrapper as well as the LISP
>> wapper around the C required to wrap the C++? It seems to work for
>> Chicken and TinyClos, so conceptually, at least couldn't Swig handle
>> UFFI and CLOS?
>
> I don't think so. The reason the C wrapper is needed in the first
> place is because C++ compilers mangle names in
> implementation-dependent ways (unless a chunk of code is wrapped in
> "extern C"). So SWIG has no more insight into what C++ compiler you,
> or whovever compiled the library you want to wrap, use. At least
> that's my understanding--I try to avoid actual contact with C++.
>
> -Peter
>
True. The name mangeling happens because the function parameter type
information needs to be passed together with the function.
(To allow function overlading)
This is usually a good thing but it does complicate talking to
other processes. Still today you typically access a .so or
.dll file which should work fine.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Pascal Bourguignon
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87k6pwk5lq.fsf@thalassa.informatimago.com>
Peter Seibel <·····@javamonkey.com> writes:
> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>
> > Is it possible for Swig to autogenerate a C wrapper as well as the LISP
> > wapper around the C required to wrap the C++? It seems to work for
> > Chicken and TinyClos, so conceptually, at least couldn't Swig handle
> > UFFI and CLOS?
>
> I don't think so. The reason the C wrapper is needed in the first
> place is because C++ compilers mangle names in
> implementation-dependent ways (unless a chunk of code is wrapped in
> "extern C"). So SWIG has no more insight into what C++ compiler you,
> or whovever compiled the library you want to wrap, use. At least
> that's my understanding--I try to avoid actual contact with C++.
Yes, of course. But a lisp program could contain some AI which from a
nm c++module.o would infer the wrapping and generate a defun sexp to
unwrap/rewrap C++ names.
--
__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
From: Marco Antoniotti
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <liSKd.9$fp1.16306@typhoon.nyu.edu>
Pascal Bourguignon wrote:
> Peter Seibel <·····@javamonkey.com> writes:
>
>
>>"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>>
>>
>>>Is it possible for Swig to autogenerate a C wrapper as well as the LISP
>>>wapper around the C required to wrap the C++? It seems to work for
>>>Chicken and TinyClos, so conceptually, at least couldn't Swig handle
>>>UFFI and CLOS?
>>
>>I don't think so. The reason the C wrapper is needed in the first
>>place is because C++ compilers mangle names in
>>implementation-dependent ways (unless a chunk of code is wrapped in
>>"extern C"). So SWIG has no more insight into what C++ compiler you,
>>or whovever compiled the library you want to wrap, use. At least
>>that's my understanding--I try to avoid actual contact with C++.
>
>
> Yes, of course. But a lisp program could contain some AI which from a
> nm c++module.o would infer the wrapping and generate a defun sexp to
> unwrap/rewrap C++ names.
>
Sounds like a simple project for common-lisp.net. The trick will be to
support multiple C++ vendors.
Cheers
--
Marco
"The trick will be to support multiple C++ vendors. "
Usually people give up on such things before they begin, because it
seems like an "all or none" proposition, but I would think that
supporting only 2-3 compilers would go a very long way. I've never
seen anybody - even large tools companies - really support more than 3
compilers because of the headaches involved.
I've used a few obscure multimedia programs in the past that supported
gcc, Borland, and Metrowerks compilers to write 'plug-ins'...mainly
because they had better cross-platform support and because gcc is free
and so frequently used.
Heck, just gcc support would go a very long way, I would think...?
From: Marco Antoniotti
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <scxLd.11$fp1.18402@typhoon.nyu.edu>
·······@runbox.com wrote:
> "The trick will be to support multiple C++ vendors. "
>
> Usually people give up on such things before they begin, because it
> seems like an "all or none" proposition, but I would think that
> supporting only 2-3 compilers would go a very long way. I've never
> seen anybody - even large tools companies - really support more than 3
> compilers because of the headaches involved.
Of course. Allow me to rephrase: the trick is to have an architecture
that will allow you to easily support yet another vendor, should the
need arise.
> I've used a few obscure multimedia programs in the past that supported
> gcc, Borland, and Metrowerks compilers to write 'plug-ins'...mainly
> because they had better cross-platform support and because gcc is free
> and so frequently used.
> Heck, just gcc support would go a very long way, I would think...?
GCC would be the primary target. Other vendor's would come right after it.
Cheers
Marco
From: Matthias Koeppe
Subject: SWIG, C++ and Lisp (was: Specific questions from Lisp newbie (Please don't taunt the fresh blood))
Date:
Message-ID: <uw5u0oxj164.fsf_-_@merkur.math.uni-magdeburg.de>
Peter Seibel <·····@javamonkey.com> writes:
> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>
>> Is it possible for Swig to autogenerate a C wrapper as well as the LISP
>> wapper around the C required to wrap the C++? It seems to work for
>> Chicken and TinyClos, so conceptually, at least couldn't Swig handle
>> UFFI and CLOS?
>
> I don't think so. The reason the C wrapper is needed in the first
> place is because C++ compilers mangle names in
> implementation-dependent ways (unless a chunk of code is wrapped in
> "extern C"). So SWIG has no more insight into what C++ compiler you,
> or whovever compiled the library you want to wrap, use. At least
> that's my understanding--I try to avoid actual contact with C++.
The trick of SWIG (as it is used for the Scheme targets and the
scripting language targets) is to automatically create these C
wrappers from the C++ header files. The C wrapper functions are then
compiled with the C++ compiler using extern "C" linkage. Because
names of extern "C" functions are not mangled, it is easily possible
to link to them using the FFI. There is no extra difficulty in doing
so from a Common Lisp FFI, compared to a scripting language FFI.
Regards
--
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> Is it possible for Swig to autogenerate a C wrapper as well as the LISP
> wapper around the C required to wrap the C++? It seems to work for
> Chicken and TinyClos, so conceptually, at least couldn't Swig handle
> UFFI and CLOS?
Yes, this can be easily implemented in SWIG. We just need someone who
wants to work on this. Actually, there are three little projects for
those who are interested:
(1) Copy the SWIG Allegro CL module and modify it to emit UFFI
declarations instead of ACL FFI declarations. (There are no
license problems; the SWIG Allegro CL module is part of SWIG and
is distributed under the BSD-ish SWIG license.) This should be
straightforward for anyone who is familiar with UFFI.
(2) Add code for generating C wrappers for C++ functions. This code
can be copied from the other language modules of SWIG.
(3) Add code for generating CLOS wrapper code. This code can be
adapted from the Chicken module (which generates TinyCLOS classes
and generic functions) or the Guile module (GOOPS).
Anyone who wants to contribute?
--
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe
From: Bulent Murtezaoglu
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87651jihq5.fsf@p4.internal>
>>>>> "d" == devmail <·······@runbox.com> writes:
d> ... If our funding comes thru, we may
d> be BUYING an NLP product that is written in C++ instead of
d> (trying) to build our own. Is UFFI basically the same across
d> different Lisp implemenations, or...? We have no idea how it
d> works at all.
I wouldn't worry about this. See what kind of interface the C++
library exports first. Maybe you'll need to build a shim layer or pay
the NLP system vendor to export what will be useful to you in a way
that lisp can access or pay your lisp vendor for the same if their ffi
is lacking, or perhaps do something else altogether. Shortcomings of
UFFI isn't an issue to waste cycles on when there's still an _if_
attached to funding.
d> In the same vein, why don't Lispers take advantage of more
d> pre-existing codebases?
We do when we need to. Your pal Kenny loves linking in all kinds of
libraries for example. See cello-magick-opengl-ftgl that uses
outlook as a dll and AOL through DDE.
[...]
d> All of the examples of domain specific languages I have seen in
d> Lisp keep the lispy syntax. Can anyone point me to examples of
d> a DSL that uses, say, a BASIC or C-style syntax (or is that
d> even possible)?
Of course it is possible, but perhaps not as convenient (both for the
implementor and the user). You usually embed your DSL into a language
you like so you get to use both. There's an infix artihmetic package
you could google for if you want an example.
d> Lisp OO seems to not really have encapsulation. Is it possible
d> to 'enforce' encapsulation in Lisp? If Alan Kay modeled
d> Smalltalk in Lisp, as I've been told, I would think this is
d> possible if desired?
What do you expect this enforcement to accomplish for you? And what
level of enforcement would you like?
d> Is CAPI from Lispworks a pretty good GUI library, or is their
d> another toolkit that allows for more native-looking GUIs?
Capi looks native enough to me on windows and Linux (but I have not seen
it on the Mac). Lispworks has enough demos they ship with the trial
edition so checking this shouldn't be hard.
d> Major downsides to CAPI?
Single vendor.
d> Is it possible to tie Lisp together
d> with a standard desktop GUI building tool (Delphi, VB, etc.),
d> while still retaining the dynamic benefits of Lisp? Lisp as
d> .DLL or whatever, only multi-platform? [...]
Yes.
(the rest I don't know).
cheers,
BM
From: Wade Humeniuk
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <OJ9Kd.51328$Qb.20864@edtnps89>
Bulent Murtezaoglu wrote:
>
> I wouldn't worry about this. See what kind of interface the C++
> library exports first. Maybe you'll need to build a shim layer or pay
> the NLP system vendor to export what will be useful to you in a way
> that lisp can access or pay your lisp vendor for the same if their ffi
> is lacking, or perhaps do something else altogether. Shortcomings of
> UFFI isn't an issue to waste cycles on when there's still an _if_
> attached to funding.
>
There is free one that works with Lisp.
OpenCyc http://www.opencyc.org
Knowledgebase, Reasoning, NLP
Written in SubL (A Lisp)
http://www.opencyc.org/doc
Wade
From: Wade Humeniuk
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <4N9Kd.51329$Qb.35242@edtnps89>
And it can be used from LispWorks.
http://www.opencyc.org/faq/opencyc_faq#139063504
Wade
From: Christopher C. Stacy
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ud5vrqn4b.fsf@news.dtpq.com>
·······@runbox.com writes:
> Does UFFI allow you
Since you're a newbie, I just wanted to make sure you know that
each Lisp system has its own "foreign function" interface, and
that UFFI is only a compatability library that allows you to do
least-common denominator stuff across Lisp systems. The other
option is to choose a particular vendor's Lisp system and use
their proprietary FFI, which may have more features than UFFI.
A proprietary FFI, like the other features that the vendor
provides, may also be portable across operating systems
without any need for UFFI.
> All of the examples of domain specific languages I have seen in Lisp
> keep the lispy syntax. Can anyone point me to examples of a DSL that
> uses, say, a BASIC or C-style syntax (or is that even possible)?
Anything is possible, but if it's not broken...?
> Lisp OO seems to not really have encapsulation. Is it possible to
> 'enforce' encapsulation in Lisp?
To what end? Are you suggesting that your programmer cannot be
trusted to call the advertised, documented APIs? They have to go
to some definite and deliberate trouble to break the abstraction.
And wouldn't you want them to be able to do that, if they really
needed, rather than saying, "Sorry, not allowed, you're just screwed?"
> Is CAPI from Lispworks a pretty good GUI library
I like it, as do most Lispworks users.
> Is it possible to tie Lisp together with a standard desktop GUI
> building tool (Delphi, VB, etc.), while still retaining the dynamic
> benefits of Lisp? Lisp as .DLL or whatever, only multi-platform?
Lisp programs can be delivered as DLLs that can be called through
standard interfaces, including COM. I think you can just call your
Lisp function from VB the same way that you would call a dynamically
loaded C function. I haven't personally tried that.
> Is there a great deal of practical difference between the various
> Lisp implementations as far as actually writing code?
You then go on to talk about Emacs, so I'm not sure what you're asking.
All the Lisp implementations can be used through GNU Emacs.
Some Lisp systems also include some sort of non-Emacs interface.
Lispworks also includes its own version of Emacs, all written
in Lisp, and they give you the sources for it. Lispworks also
has graphical IDE tools (such as various browsers), which are
not really related to any native Emacs functionality.
> Lispers seem to have less trouble moving between implementations
> than Smalltalkers, but is that only once you've mastered most of the
> language?
Now you're talking about language features. Common Lisp is an
ANSI standard language, and each implementation also has extensions.
For the extension functionality that implementations have in common,
they are not very different from each other. Taking advantage of that,
people have gone to the trouble of writing compatability libraries, so
the exact same code runs everywhere. But some vendors have lots and
lots of extra goodies that the others don't have, or don't do as well,
and would naturally like for you to get hooked on those.
You are going to have to pick some actual implementation, after all.
Talk to the vendor to see why theirs might be the best one for you,
according to your own criteria (features, support, licensing, whatever).
> Someone sent me a private email, for example, that said
> that LW had an unusual MOP implementation...?
I regularly use Lispworks and CMUCL, and sometimes CLISP and others,
and I don't know the answer to your question. You see people talking
about the MOP on this newsgroup because it's a very advanced, cool,
and obscure feature, not because it's part of the language that you
will ordinarily use. It's not in ANSI CL. It's purpose is to change
the way that OOP normally works in Lisp. I've been programming in Lisp
for about 25 years writing all kinds of OOP programs, and have basically
never had to use the MOP for anything. Nice to know it's there.
Don't worry about it.
> Are there any fully OO databases available for Lisp? Our UIUC coder
> has a novel solution to one of our problems, but it relies on the use
> of Omnibase or Gemstone OO databases. Lispers seem to mainly use just
> relational or "object-relational" databases...presumably because of the
> multi-paradigm approach to coding?
Object-oriented databases were pioneered by Lisp, very long ago,
and in more modern times (late 80s, early 90s) there were several
products you could use, but I don't know what offerings are currently
available.
I assume that most people are using relational databases because they
are interfacing to existing systems - few customers in the real world
are using object oriented databases. (Last time I looked into this,
for a long-distance carrier company, the best one was ODI.
But they had dropped support for Lisp, and were focusing on JAVA.
I believe they've been out of business for some years now.)
Perhaps someone else can comment on current offerings in this area.
"Since you're a newbie, I just wanted to make sure you know..."
Yes, thank you, all of the was very helpful...especially the FFI info.
I mentioned the DSL syntax and the encapsulation only because the
systems analysts will be making modifications to certain parts of the
system while it is running (adding new investment vehicles as they
appear,etc.), not the programmers. I was curious as to how much
everything could be "dumbed down" and where one might reach a point of
diminishing returns...
I kind of blurred the line between language features and environment
because I was trying to make a point about the difficulty of moving
between Smalltalk implementations, where the language and environment
are pretty much tied together. Lisp, on the other hand, allows you to
always use emacs - so part of the learning curve is solved, leaving
only the differences in language features/implementations. I was
trying to understand how different the language features are between
implementations.
Thanks,
- Sergei
From: Pascal Costanza
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctao0v$74k$1@snic.vub.ac.be>
·······@runbox.com wrote:
> All of the examples of domain specific languages I have seen in Lisp
> keep the lispy syntax. Can anyone point me to examples of a DSL that
> uses, say, a BASIC or C-style syntax (or is that even possible)?
The LOOP macro that is part of ANSI Common Lisp has a very non-Lispy
syntax. There are also packages that provide infix operators.
Non-Lisp syntaxes are not so widely used because they don't give you any
important advantages. That may be different if you want to have your DSL
be used by "non-programmers". But Common Lisp is still quite flexible to
accomodate them. If all else fails, just write a thin parser that
translates from your preferred syntax to Lisp code. That's not very hard
to do.
> Lisp OO seems to not really have encapsulation. Is it possible to
> 'enforce' encapsulation in Lisp? If Alan Kay modeled Smalltalk in
> Lisp, as I've been told, I would think this is possible if desired?
In Common Lisp, encapsulation is achieved via agreement on a few simple
rules that you adhere to as a programmer. You cannot accidentally break
them, only intentionally. And you may have good reasons for the latter.
Even in more stringent languages there are ways around encapsulation
boundaries, once they are used in production environments.
> Is CAPI from Lispworks a pretty good GUI library, or is their another
> toolkit that allows for more native-looking GUIs? Major downsides to
> CAPI? Is it possible to tie Lisp together with a standard desktop GUI
> building tool (Delphi, VB, etc.), while still retaining the dynamic
> benefits of Lisp? Lisp as .DLL or whatever, only multi-platform?
Yep, this is all possible, and depends largely on the concrete
requirements of your system.
> Is there a great deal of practical difference between the various Lisp
> implementations as far as actually writing code? While I prefer the
> Smalltalk editors in many ways, Lisp has an advantage in this regard as
> far as consistency (emacs or emacs clone.) The VisualWorks and Dolphin
> IDEs, frameworks, and class libraries are all just different enough
> from one another that I feel like I'm completely starting over when I
> try to move from one to another. Lispers seem to have less trouble
> moving between implementations than Smalltalkers, but is that only once
> you've mastered most of the language? Someone sent me a private email,
> for example, that said that LW had an unusual MOP implementation...?
Here, the fact that Common Lisp is quite a large language that specifies
a large number of predefined operators is an advantage because it eases
transition from one implementation to another. Nevertheless, you will
probably still want to use vendor-specific libraries. Evaluate the
different implementations in the beginning, and then choose one and
stick with it.
The LispWorks MOP indeed deviates from the semi-official MOP
specification (that is not part of ANSI!). I think that some of the
things that are implemented in their MOP are somewhat more useful than
what the MOP spec requires, but YMMV.
I don't see how this would seriously prevent you from switching to
another CL implementation. In fact, it's one of the strong points of CL
that you can bend it quite a lot to do what you want.
> Are there any fully OO databases available for Lisp? Our UIUC coder
> has a novel solution to one of our problems, but it relies on the use
> of Omnibase or Gemstone OO databases. Lispers seem to mainly use just
> relational or "object-relational" databases...presumably because of the
> multi-paradigm approach to coding?
Maybe you don't need a database. Google for "object prevalence" - in
short: most databases fit in RAM nowadays, so store them in RAM. That's
easier. Next, if they don't fit in RAM, it may still be a better idea to
store the date in text files (for example as s-expressions), because the
data is easier to maintain and fix in case of a bug. Just use a text editor.
> Can anyone compare and contrast UCW and Seaside for me?
Continuations are overrated. ;)
Pascal
From: Ralph Richard Cook
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <41f9b65a.9526087@newsgroups.bellsouth.net>
>> Can anyone compare and contrast UCW and Seaside for me?
>
>Continuations are overrated. ;)
>
>Pascal
I'll chime in with a slightly longer answer. Continuations in Web
programming is supposed to take care of the whole
"stateless/page/batch" issue with browsers and servers. Well, with the
XMLHTTPRequest objects available in the latest Internet Explorer,
FireFox and Safari you can do a lot of back and forth to your server
while staying on the same page, so in my opinion that cuts down on the
need for continuations.
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <2TjKd.193134$8l.126653@pd7tw1no>
Ralph Richard Cook wrote:
>>>Can anyone compare and contrast UCW and Seaside for me?
>>
>>Continuations are overrated. ;)
>>
>>Pascal
>
> I'll chime in with a slightly longer answer. Continuations in Web
> programming is supposed to take care of the whole
> "stateless/page/batch" issue with browsers and servers.
Huh?
> Well, with the
> XMLHTTPRequest objects available in the latest Internet Explorer,
> FireFox and Safari you can do a lot of back and forth to your server
> while staying on the same page, so in my opinion that cuts down on the
> need for continuations.
How exactly do you figure this works? You are still going to have to
deal with the back button, session clones and the stateless nature of
HTTP. You still have stateless requests going to and from the server
that you have to track somehow. "staying on the same page" does not mean
you never make another HTTP request (with a different URL .. so a
different "page" is retrieved from the server).
The only thing XMLHTTPRequest does is allows you to send your request in
the background and redraw only a portion of the page once you have
recieved your data. You still have to keep state somewhere. Are you
proposing that we keep state in the html document? not going to work
with the back button, or session cloning. Not to mention the security
risks.
This has nothing to to with continuations, nor does it make any sense at
all to assume it does. Continuations are a way to track and maintain
state over a series of stateless, non-sequential page requests.
XMLHTTPRequest is just another way to make an HTTP connection.
Could you elaborate as to how XMLHTTPRequest will eliminate the
stateless nature of http, and therefore reduce the need for
continuations on the serverside? Maybe i'm missing something obvious here.
drewc
From: Ralph Richard Cook
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <41fc115b.1584227@newsgroups.bellsouth.net>
drewc <·····@rift.com> wrote:
>Ralph Richard Cook wrote:
>>>>Can anyone compare and contrast UCW and Seaside for me?
>>>
>>>Continuations are overrated. ;)
>>>
>>>Pascal
>>
>> I'll chime in with a slightly longer answer. Continuations in Web
>> programming is supposed to take care of the whole
>> "stateless/page/batch" issue with browsers and servers.
>
>Huh?
>
>> Well, with the
>> XMLHTTPRequest objects available in the latest Internet Explorer,
>> FireFox and Safari you can do a lot of back and forth to your server
>> while staying on the same page, so in my opinion that cuts down on the
>> need for continuations.
>
>How exactly do you figure this works? You are still going to have to
>deal with the back button, session clones and the stateless nature of
>HTTP. You still have stateless requests going to and from the server
>that you have to track somehow. "staying on the same page" does not mean
>you never make another HTTP request (with a different URL .. so a
>different "page" is retrieved from the server).
>
>The only thing XMLHTTPRequest does is allows you to send your request in
>the background and redraw only a portion of the page once you have
>recieved your data. You still have to keep state somewhere. Are you
>proposing that we keep state in the html document? not going to work
>with the back button, or session cloning. Not to mention the security
>risks.
>
>This has nothing to to with continuations, nor does it make any sense at
>all to assume it does. Continuations are a way to track and maintain
>state over a series of stateless, non-sequential page requests.
>XMLHTTPRequest is just another way to make an HTTP connection.
>
>Could you elaborate as to how XMLHTTPRequest will eliminate the
>stateless nature of http, and therefore reduce the need for
>continuations on the serverside? Maybe i'm missing something obvious here.
>
>drewc
Hey, at least it was a longer answer than "Continuations are
overrated" :)
No, XMLHTTPRequest doesn't handle back buttons and session cloning.
However, I would say that most people don't have multiple sessions
with 'state' (form data to send to a server) opened to the same page,
and good use of XMLHTTPRequests can cut down on needing the back
button.
I'm using this at work right now, doing web admin for a product. A
user can put in parameters for a MQSeries queue, and hit a 'test'
button. The page, via XMLHTTPRequest, sends the queue parameters to a
server program that tests for the existence of the queue and sends
back a 'successful' or 'unsuccessful' to the web page, so the user can
change a parameter if he needs to. Before, doing that kind of test
would mean leaving that page, and you'd need a continuation or cookie
to keep the parameters between pages.
From: Randall Randall
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <41fc3c8d$1_3@alt.athenanews.com>
Ralph Richard Cook wrote:
> I'm using this at work right now, doing web admin for a product. A
> user can put in parameters for a MQSeries queue, and hit a 'test'
> button. The page, via XMLHTTPRequest, sends the queue parameters to a
> server program that tests for the existence of the queue and sends
> back a 'successful' or 'unsuccessful' to the web page, so the user can
> change a parameter if he needs to. Before, doing that kind of test
> would mean leaving that page, and you'd need a continuation or cookie
> to keep the parameters between pages.
"continuation or cookie"? Perhaps you meant "need a cookie, form
variable or path information to store a pointer to a continuation"?
Frankly, given macros and the fact that state will be stored on
the server, I don't understand the point of using CPS for web
applications; sure, you get the ability to sort of write as if you
were simply calling methods or functions in order, but you can do
the same thing without the underlying complexity that seems wed to
the continuation abstraction, using relatively simple macros to
hide the web-specific parts of what you're doing. I find handling
forms in a sane manner to be more difficult than creating the
illusion of a straight-through application.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
From: Rob Warnock
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <s4qdna-szY3hwmHcRVn-tA@speakeasy.net>
Randall Randall <·······@randallsquared.com> wrote:
+---------------
| Ralph Richard Cook wrote:
| > change a parameter if he needs to. Before, doing that kind of test
| > would mean leaving that page, and you'd need a continuation or cookie
| > to keep the parameters between pages.
|
| "continuation or cookie"? Perhaps you meant "need a cookie, form
| variable or path information to store a pointer to a continuation"?
+---------------
Cookies aren't useful in keeping track of multiple browser windows,
since they're limited to only one per server per key, and there's
no easy way to tie browser windows to keys.
+---------------
| Frankly, given macros and the fact that state will be stored on
| the server, I don't understand the point of using CPS for web
| applications...
+---------------
You really don't need CPS *per se*, but constructing your web app
in CPS *style* enormously simplifies the handling of multiple
simultaneous sessions from the same client host [note that *all*
the hosts behind a NAT gateway appear to the server to be a single
"host"!], not to mention multiple windows from a single browser.
[See multiple papers on the "Web Continuation" approach by Queinnec's
and Felleisen's teams.]
As an end-user, I really get frustrated when services offered on
the Web get this wrong. When I'm browsing some vendor's site, I
*often* click a link with middle-mouse to get a parallel exploration
started, so I can look at alternatives before committing myself,
and am enormously irritated when something I do in the new window
messes up the state in the old one!
[Analogy: When you're browsing a physical bookstore, you don't have
to commit to a decision on whether you're going to buy the first book
you looked at before you can go leaf through a different one. So why
should buying on-line be different?]
As a web implementor, I also find it amazing that other implementors
don't bother to get it right, since it's really not all that hard --
just use a small amount of "hidden form data" [compressed/encrypted/
timestamped/nonced/authenticated to whatever extent the application
absolutely requires (but usually simple cleartext is fine)] to encode
the state or a representation of the server-side state into the each
HTML form. [And forget cookies altogether.] Problem solved. Multiple
windows (including "forks" of a session created by using a middle-click)
now work correctly, and the "Back" button now works reliably in the
intuitively-correct way in each one.
At that point the only problem remaining is the proper strategy to
"garbage collect" the server-side state [if any], but that's a problem
one always has when there is *any* server-side state (including a
database, by the way!) -- it's not unique to the "web continuation"
approach. In fact, by keeping most of the volatile state of the
user interaction history in the browser window, the CPS-like style
minimizes the amount of the server-side state to be managed!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Randall Randall
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <41fccaa5$1_1@alt.athenanews.com>
Rob Warnock wrote:
> Randall Randall <·······@randallsquared.com> wrote:
> +---------------
> |
> | "continuation or cookie"? Perhaps you meant "need a cookie, form
> | variable or path information to store a pointer to a continuation"?
> +---------------
>
> Cookies aren't useful in keeping track of multiple browser windows,
> since they're limited to only one per server per key, and there's
> no easy way to tie browser windows to keys.
It's true that cookies are a poor way to manage per-window
state, but as a way to keep track of everything "this user"
needs unobtrusively, they're superb.
> +---------------
> | Frankly, given macros and the fact that state will be stored on
> | the server, I don't understand the point of using CPS for web
> | applications...
> +---------------
>
> You really don't need CPS *per se*, but constructing your web app
> in CPS *style* enormously simplifies the handling of multiple
> simultaneous sessions from the same client host
...and this is what I haven't seen.
>[note that *all*
> the hosts behind a NAT gateway appear to the server to be a single
> "host"!],
What? Are you really suggesting that anyone would try to track
sessions by IP address?
> not to mention multiple windows from a single browser.
I think this is a good case where continuations (as I understand them)
lose. More below.
> [See multiple papers on the "Web Continuation" approach by Queinnec's
> and Felleisen's teams.]
I'll look.
> As an end-user, I really get frustrated when services offered on
> the Web get this wrong. When I'm browsing some vendor's site, I
> *often* click a link with middle-mouse to get a parallel exploration
> started, so I can look at alternatives before committing myself,
> and am enormously irritated when something I do in the new window
> messes up the state in the old one!
I do that, too, but I think we have different ideas of "messes up".
If I middle-click to get a new tab or window with that link, and
later add a book to my cart, or change my preferences, or do basically
anything else, I don't want to find that I have two inconsistent sets
of attributes. Having to pick a window and then laboriously hunt down
each item I added in all other windows on this site doesn't strike me
as a good time.
If I add an item to a cart, it should show up in my cart display in
the other window the next time I get a new page.
> [Analogy: When you're browsing a physical bookstore, you don't have
> to commit to a decision on whether you're going to buy the first book
> you looked at before you can go leaf through a different one. So why
> should buying on-line be different?]
Neither do you find that you're suddenly pushing two seperate shopping
carts because you chose to look at multiple items simultaneously.
> As a web implementor, I also find it amazing that other implementors
> don't bother to get it right, since it's really not all that hard --
> just use a small amount of "hidden form data" [compressed/encrypted/
> timestamped/nonced/authenticated to whatever extent the application
> absolutely requires (but usually simple cleartext is fine)] to encode
> the state or a representation of the server-side state into the each
> HTML form. [And forget cookies altogether.] Problem solved. Multiple
> windows (including "forks" of a session created by using a middle-click)
> now work correctly, and the "Back" button now works reliably in the
> intuitively-correct way in each one.
If you added an item to your cart, and hit back to follow another link,
it would seem to me that, in CPS, the "normal" thing to have happen is
that you've "unadded" the item. This seems plausible, since I've been
on sites that worked this way, but it's quite contrary to what you'd
expect: turning around and going back to an interesting link or item
shouldn't implicitly unwind the actions you've already taken.
> At that point the only problem remaining is the proper strategy to
> "garbage collect" the server-side state [if any], but that's a problem
> one always has when there is *any* server-side state (including a
> database, by the way!) -- it's not unique to the "web continuation"
> approach. In fact, by keeping most of the volatile state of the
> user interaction history in the browser window, the CPS-like style
> minimizes the amount of the server-side state to be managed!
Does that matter? There's lots of space on the server-side, but there
are still many people who use 56K or worse connections. I think the
easy thing to do would be to keep as much as possible on the server,
and use a simple token to track the server side store in question. In
any case, that's what I do now, though of course the vast majority of
my code doesn't have to know anything about that, since setup and
management of the session is the job of the framework. For the single
good thing (as I understand it) about CPS, I can use a macro that
transforms my code into a "wizard" (a sequence of forms).
There's a whole 'nother problem with what you describe, which is that
while passing around encrypted data works okay for POST forms, it
results in unmemorable, unbookmarkable URLs when used with links. For
that reason, you'll want to use cookies anyway; there's no sense in
making your users fight with your implementation details by creating
URLs that look like:
http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/71907/wo/DZ6siY15SgYE2mwwPvvccUK3myk/0.0.11.1.0.6.21.1.0.1.0.0.0.1.0
or
http://www.fractalconcept.com/asp/jmD3/sdataQ1ZXnSEItuheDM==/sdataQuvY9x3g$ecX
(sorry, Marc! :). When the URL clearly contains lots of information
about the user, users will be reluctant to share links (I spent 30
minutes recently trying to figure out how to remove any personal
information from a fractalconcepts url I wanted to post publicly, and
am not sure I managed it).
Anyway, hope I didn't overwhelm you with negativity. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall <·······@randallsquared.com> schrieb:
> If I middle-click to get a new tab or window with that link, and later
> add a book to my cart, or change my preferences, or do basically
> anything else, I don't want to find that I have two inconsistent sets
> of attributes.
Data can belong to world, user, and browser/window levels. Nobody
disagrees that there should be only one shopping cart per user. But
*some* data should be per-browser-window, and continuations are perfect
for that. Why? Because the interaction history represented by a browser
window maps nicely to the computation history represented by a
continuation. It's not like you no longer need databases, but simple
single-threaded interactions can be directly programmed as such.
For example, there's a somewhat popular bug-tracking system called
Mantis that uses cookies to keep track of session data. It happens that
which project's bugs you're looking at is part of that data, so if you
have two windows open to different projects, and try and edit bugs in
both windows, Mantis gets confused and one of your edits will silently
not work. This is obviously a bug which could be fixed by a better
design. CPS is such a design, which eliminates this whole class of bugs
and lets you structure your program more naturally to boot!
Adrian Kubala <······@sixfingeredman.net> writes:
> Randall Randall <·······@randallsquared.com> schrieb:
> > If I middle-click to get a new tab or window with that link, and later
> > add a book to my cart, or change my preferences, or do basically
> > anything else, I don't want to find that I have two inconsistent sets
> > of attributes.
>
> Data can belong to world, user, and browser/window levels. Nobody
> disagrees that there should be only one shopping cart per user.
You're assuming too much. On the AppleStore, users can save shopping
carts, and therefore there may be several shopping carts per user.
Also, what's a "user"? The same person can well have several
accounts, and try to shop from several of its accounts at the same
time from the same browser. eg: she may have a personnal account and
an enterprise account, and while she's shopping a new MacMini for her,
her boss could ask her to shop a new Xserver RAID for the developpers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
From: Marc Battyani
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <ctrk2r$i22@library2.airnews.net>
"Randall Randall" <·······@randallsquared.com> wrote
> There's a whole 'nother problem with what you describe, which is that
> while passing around encrypted data works okay for POST forms, it
> results in unmemorable, unbookmarkable URLs when used with links. For
> that reason, you'll want to use cookies anyway; there's no sense in
> making your users fight with your implementation details by creating
> URLs that look like:
>
http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/71907/wo/DZ6
siY15SgYE2mwwPvvccUK3myk/0.0.11.1.0.6.21.1.0.1.0.0.0.1.0
> or
>
http://www.fractalconcept.com/asp/jmD3/sdataQ1ZXnSEItuheDM==/sdataQuvY9x3g$e
cX
> (sorry, Marc! :). When the URL clearly contains lots of information
> about the user, users will be reluctant to share links (I spent 30
> minutes recently trying to figure out how to remove any personal
> information from a fractalconcepts url I wanted to post publicly, and
> am not sure I managed it).
Well, it's easy enough, the URL does not contain any user info :
CL-USER 3 > (interface::decode-session-url
"http://www.fractalconcept.com/asp/jmD3/sdataQ1ZXnSEItuheDM==/sdataQuvY9x3g$
ecX")
=> (:page "mod_lisp" :session "v0uXt8kW")
Which is aliased as http://www.fractalconcept.com/asp/html/mod_lisp.html
Of course, this URL this is just a key in an hashtable.
All the state is stored on the server. Meaningful URI are only meaningful in
limited cases anyway (typically documents and structured content).
Marc
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <4MjMd.259206$Xk.134284@pd7tw3no>
Randall Randall wrote:
[snip]
>
>
> I do that, too, but I think we have different ideas of "messes up".
> If I middle-click to get a new tab or window with that link, and
> later add a book to my cart, or change my preferences, or do basically
> anything else, I don't want to find that I have two inconsistent sets
> of attributes. Having to pick a window and then laboriously hunt down
> each item I added in all other windows on this site doesn't strike me
> as a good time.
>
> If I add an item to a cart, it should show up in my cart display in
> the other window the next time I get a new page.
In UCW, this behaviour is configurable. the default is the behavior you
describe, but you can set the :backtrack option on a slot to have the
back button roll back the value. If you set the HTTP or META tags to
inhibit caching, every magically works just as you'd expect.
If you want to see a demo of this, check out the clipboard demo i have
put up at :
http://merlin.tech.coop:8080/geo-db/index.ucw
just hit "go", add a result to the clipboard, then hit back, and reload
and you'll see the exact behaviour you wanted. Open new windows,
whatever you want.. it should Just Work (tm).
drewc
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <jk4ekfxk2q4.fsf@W003275.na.alarismed.com>
drewc <·····@rift.com> writes:
> http://merlin.tech.coop:8080/geo-db/index.ucw
>
> just hit "go", add a result to the clipboard, then hit back, and reload
> and you'll see the exact behaviour you wanted.
If I follow these steps, but hit Back /twice/, taking me back to the
first root URL, it seems that my session state is lost. Is that
intentional?
Also, if I add an entry to the clipboard, then open a new window, the
same entry gets added again, once for each time that same URL gets
hit. It seems that these operations or "actions" are not
idempotent. Is that intentional?
--
Steven E. Harris
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <SIFMd.265865$8l.117489@pd7tw1no>
Steven E. Harris wrote:
> drewc <·····@rift.com> writes:
>
>
>>http://merlin.tech.coop:8080/geo-db/index.ucw
>>
>>just hit "go", add a result to the clipboard, then hit back, and reload
>>and you'll see the exact behaviour you wanted.
>
>
> If I follow these steps, but hit Back /twice/, taking me back to the
> first root URL, it seems that my session state is lost. Is that
> intentional?
Of course it is. That URL is the entry point to the application, it's
like "www.google.ca". I would certainly dislike it if i went to google
and saw somebody elses search results. same thing.
If i wanted, i could have dynamic activity on that page, and relate it
to a users cookie if i so desired. but that is not what ths demo is
about. When you hit that URL you are creating a new session (like double
cliking on an application). That is how the web works.
Note that if you do as you describe, and enter another search term, your
clipboard retains it's earlier value. This is the desired behaviour IMO.
> Also, if I add an entry to the clipboard, then open a new window, the
> same entry gets added again, once for each time that same URL gets
> hit. It seems that these operations or "actions" are not
> idempotent. Is that intentional?
Nope, thats a bug. I'm not sure if UCW has any specific provisions for
this sort of thing, but it was trivial to add. i just created a memoize
mixin and a defaction-memoize macro. This makes sure that an action is
only called once, so reload and page cloning and the like do not add
another value to the clipboard. It also caches the return value of the
action, so that it still appears to work (ie reload or cloning does not
pop up some "already perfored action STOP" error.)
(with thanks to On Lisp :
(defclass memoize-component ()
((memos :initarg :memos :accessor memos :initform (make-hash-table
:test #'equalp)))
(:metaclass standard-component-class))
(defaction run-memo ((m memoize-component) fun &rest args)
(let* ((memo-id
(concatenate 'string
(ucw::find-session-id *context*)
(ucw::find-frame-id *context*)
(ucw::find-action-id *context*)))
(memo (gethash memo-id (memos m))))
(or memo
(setf (gethash memo-id (memos m)) (apply fun args)))))
(defmacro defaction-memoize (name args &body body)
(let ((fun (concatenate 'string
(string name)
"-"
(string (gensym)))))
`(progn
(defaction ,(intern fun) ,args
,@body)
(defaction ,name ,args
(run-memo ,(caar args) #',(intern fun) ,(caar args) ,@(cdr args))))))
with that done i just add the mixin to my SEARCH-BOX class, and use
DEFACTION-MEMOIZE rather than DEFACTION for any destructive actions that
manpulate global state:
(defaction-memoize add-to-clipboard ((search-box
search-box-with-clipboard) item)
(setf (clipboard search-box) (cons item (clipboard search-box))))
Which expands like to :
RR-GEO> (macroexpand-1 '(defaction-memoize add-to-clipboard ((search-box
search-box-with-clipboard) item)
(call 'info-message :message (ucw::find-action-id *context*))
(setf (clipboard search-box) (cons item (clipboard search-box)))
))
(PROGN
(DEFACTION ADD-TO-CLIPBOARD-G9697
((SEARCH-BOX SEARCH-BOX-WITH-CLIPBOARD) ITEM)
(CALL 'INFO-MESSAGE
:MESSAGE
(IT.BESE.UCW::FIND-ACTION-ID *CONTEXT*))
(SETF (CLIPBOARD SEARCH-BOX) (CONS ITEM (CLIPBOARD
SEARCH-BOX))))
(DEFACTION ADD-TO-CLIPBOARD
((SEARCH-BOX SEARCH-BOX-WITH-CLIPBOARD) ITEM)
(RUN-MEMO SEARCH-BOX #'ADD-TO-CLIPBOARD-G9697 SEARCH-BOX
ITEM)))
T
I had to create a named function because of the CPS transformer, but
it's essentially Paul Grahams memoize macro, only keyed on a
continuation id rather than the arguments. This way the action will can
be called multiple times, just not from the exact same page. This
prevents all manner of bugs.. and if there is not something similar in
UCW already, there will be shortly.)
Thanks for the bug report, so far using c.l.l as a QA service has worked
quite well.. This was a big one... keep 'em coming. :).
drewc
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <jk41xbwi8ri.fsf@W003275.na.alarismed.com>
drewc <·····@rift.com> writes:
> Of course it is. That URL is the entry point to the application,
> it's like "www.google.ca". I would certainly dislike it if i went to
> google and saw somebody elses search results. same thing.
Not quite the same thing. I was reading Queinnec's "Inverting back the
inversion of control" paper yesterday, and in his summing calculator
example, he shows how it may make sense to assume that a person
returning to the first page -- the entry point, as you say -- is
trying to start over (Section 5.2) or perhaps trying to continue
(Section 5.1). His ideal solution is similar to yours: fork off a new
session upon repeated submissions from the first page. I was just
checking to see if you had made this choice deliberately.
I was also pointing out what may be considered a deficiency in your
server's cache instructions to the browser: different behavior upon
returning to the root URL by way of the Back button depending on
whether one returns and immediately moves forward again (possibly
submitting another search query), or whether one returns, refreshes
the page, and then moves forward.
It's not enough to say that any query submitted from the first page
starts a distinct session. As it works now, any query submitted from a
/distinctly served/ first page starts a new session, or rather that
page is the first step in the new session. One can return to a cached
first page and continue forward again in an existing session.
The distinction is subtle and could be missed by many users. Forcing
the client to always request a fresh copy of the first page is one
possible solution, unless you're comfortable with the ambiguity
described above.
> If i wanted, i could have dynamic activity on that page, and relate it
> to a users cookie if i so desired. but that is not what ths demo is
> about. When you hit that URL you are creating a new session (like double
> cliking on an application). That is how the web works.
Sure, I know that. But your users may not see the distinction between
"hitting the URL" with an actual cache-ignorant GET request and
returning to that first page with the Back button, displaying a cached
view that's indistinguishable from a freshly requested page.
> Note that if you do as you describe, and enter another search term,
> your clipboard retains it's earlier value. This is the desired
> behaviour IMO.
Provided that I don't refresh that first page after returning to it
with the Back button, yes.
--
Steven E. Harris
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the freshblood)
Date:
Message-ID: <5gUMd.272416$Xk.63963@pd7tw3no>
Steven E. Harris wrote:
> drewc <·····@rift.com> writes:
>
>
>>Of course it is. That URL is the entry point to the application,
>>it's like "www.google.ca". I would certainly dislike it if i went to
>>google and saw somebody elses search results. same thing.
>
>
> Not quite the same thing. I was reading Queinnec's "Inverting back the
> inversion of control" paper yesterday, and in his summing calculator
> example, he shows how it may make sense to assume that a person
> returning to the first page -- the entry point, as you say -- is
> trying to start over (Section 5.2) or perhaps trying to continue
> (Section 5.1). His ideal solution is similar to yours: fork off a new
> session upon repeated submissions from the first page. I was just
> checking to see if you had made this choice deliberately.
Not entirely deliberatly, as it's technically impossible to do it any
other way (without resorting to cookies). there is no way to encode any
state when none has been recieved from the browser.
>
> I was also pointing out what may be considered a deficiency in your
> server's cache instructions to the browser: different behavior upon
> returning to the root URL by way of the Back button depending on
> whether one returns and immediately moves forward again (possibly
> submitting another search query), or whether one returns, refreshes
> the page, and then moves forward.
I don't actually have any cache instructions being sent right now, so
that is just the standard behavior. I admit it is less than ideal, but t
is consistent with my view of the entry point being the "application
startup".
When i delver these applications, i present my users with a little icon
on the desktop to start it up in a web browser. Clients see that first
page as the "application startup", and expect the behavior of hitting
that page to be "starting the application".
>
> It's not enough to say that any query submitted from the first page
> starts a distinct session. As it works now, any query submitted from a
> /distinctly served/ first page starts a new session, or rather that
> page is the first step in the new session. One can return to a cached
> first page and continue forward again in an existing session.
Any distinct session will serve up a distinct session. If i were to
remove the cacheing ability then that first page would always start a
new session. if one of my users gave me the complaint that you just did,
that would be the solution. I prefer to give them the option (and it's
in the manual, which i sit down and read with any new users of my
applications.)
How do you solve these issues in a standard web app?
>
> The distinction is subtle and could be missed by many users. Forcing
> the client to always request a fresh copy of the first page is one
> possible solution, unless you're comfortable with the ambiguity
> described above.
I'm not entirely, but like i said i don't have the cache manpulation
heaeder being sent out on that server, so the problem is mostly solved.
>
>
>>If i wanted, i could have dynamic activity on that page, and relate it
>>to a users cookie if i so desired. but that is not what ths demo is
>>about. When you hit that URL you are creating a new session (like double
>>cliking on an application). That is how the web works.
>
>
> Sure, I know that. But your users may not see the distinction between
> "hitting the URL" with an actual cache-ignorant GET request and
> returning to that first page with the Back button, displaying a cached
> view that's indistinguishable from a freshly requested page.
Right, hence the "starting over" approach, which you were critical of in
your first post, is probably the best behavior... non? Tell me what you
think.
>
> Provided that I don't refresh that first page after returning to it
> with the Back button, yes.
If the user hits 'refresh' they should expect a 'fresh page'. While i
agree that some of these problems are tough (web programming is a new
field after all), I have managed to solve them pretty well. (the refresh
bug you mentioned probably exists in 90%+ of webapps. the fact that i
was able to curb it in about 20 LOC says something about the
continations approach, does it not?)
How do you prevent page refreshes and the session clone from doing
similar things in a finite-state-machine application? Post a clipboard
demo in your favorite framework (it only took me 1/2 hour or so) and
i'll try to break it. We'll race to add new features and prove once and
for all if continuations, or a finite-state-machine, are the better
method for producing bug-free web apps :)
Infact i notice you didn't even mention my memoize hack... Come on man!
that was amazing. I've been fighting page refreshes my entire career,
and we made the problem go away. This will become part of UCW proper in
the near future as a pseudo 'method combination' :
(defaction foo :isolate ((...)) ())
The patch has been sent to the mailing list. and will probably be a part
of UCW 0.4.
Please keep pointing out these flaws, it makes for bettter software. If
we can please a critic like yourself, we can certianly please our
customer and users!
drew/cc :)
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <8EWKd.209632$6l.186343@pd7tw2no>
Ralph Richard Cook wrote:
[snip]
> Hey, at least it was a longer answer than "Continuations are
> overrated" :)
I'll take the shorter version over the inacurate one :P
>
> No, XMLHTTPRequest doesn't handle back buttons and session cloning.
> However, I would say that most people don't have multiple sessions
> with 'state' (form data to send to a server) opened to the same page,
> and good use of XMLHTTPRequests can cut down on needing the back
> button.
"State" is much more than "form data". In your simple example there is
only one request/response, so no need to store state. But what if after
i get an "unsuccessful" i was to redirect the user to a debugger or
something. How am i to know, without storing some kind of state, where
in the control flow the user should be at any given moment? I'll need a
"use-debugger" variable or something .. right? How am i to know which
user is logged in? Unless you are just displaying single pages or
responses (like a REST application), then you have to keep track of
state somehow.
> I'm using this at work right now, doing web admin for a product. A
> user can put in parameters for a MQSeries queue, and hit a 'test'
> button. The page, via XMLHTTPRequest, sends the queue parameters to a
> server program that tests for the existence of the queue and sends
> back a 'successful' or 'unsuccessful' to the web page, so the user can
> change a parameter if he needs to. Before, doing that kind of test
> would mean leaving that page, and you'd need a continuation or cookie
> to keep the parameters between pages.
"Pages" have nothing to do with it. I'm talking about http requests. You
still have to make an HTTP request right? to a server that is
stateless... correct? how are you telling that server which queue to
test for, from which user, without maintaining state of some sort.
Yes, you can do ths all on the same page, and keep all state client-side
in the DOM or in a javascript data structure, but that presents all the
same problems as cookies or server-side sessions.
You might want to have a look at:
http://lisp.tech.coop/Web%2FContinuation
It explains the difference between the state-machine model and the
continuation model with some sample code. XMLHTTPRequest and
Continuations are not mutually exclusive concepts, and they don't solve
the same problems.
Check out :
········································@irGjTuYdBOcLOFYC/TgryPlPX
It contains a demonstration using XMLHTTPRequest with a continuation
framework.
You are dismissing continuations without knowing much about them. I hope
this can clear up some confusion.
drewc
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <nHWKd.208558$8l.84715@pd7tw1no>
drewc wrote:
> Ralph Richard Cook wrote:
> [snip]
>
>> Hey, at least it was a longer answer than "Continuations are
>> overrated" :)
>
>
> I'll take the shorter version over the inacurate one :P
>
I meant inaccurate of course. Gotta see the humour in that!
drewc
drewc <·····@rift.com> wrote:
...
>"State" is much more than "form data". In your simple example there is
>only one request/response, so no need to store state. But what if after
>i get an "unsuccessful" i was to redirect the user to a debugger or
>something. How am i to know, without storing some kind of state, where
>in the control flow the user should be at any given moment? I'll need a
>"use-debugger" variable or something .. right? How am i to know which
>user is logged in? Unless you are just displaying single pages or
>responses (like a REST application), then you have to keep track of
>state somehow.
>
>> I'm using this at work right now, doing web admin for a product. A
>> user can put in parameters for a MQSeries queue, and hit a 'test'
>> button. The page, via XMLHTTPRequest, sends the queue parameters to a
>> server program that tests for the existence of the queue and sends
>> back a 'successful' or 'unsuccessful' to the web page, so the user can
>> change a parameter if he needs to. Before, doing that kind of test
>> would mean leaving that page, and you'd need a continuation or cookie
>> to keep the parameters between pages.
>
>"Pages" have nothing to do with it. I'm talking about http requests. You
>still have to make an HTTP request right? to a server that is
>stateless... correct? how are you telling that server which queue to
>test for, from which user, without maintaining state of some sort.
>
>Yes, you can do ths all on the same page, and keep all state client-side
>in the DOM or in a javascript data structure, but that presents all the
>same problems as cookies or server-side sessions.
...
I'm keeping all the data in DOM/javascript structures, and sending all
the parameters to the server each time via the XMLHTTPRequest, either
in a GET or for more complicated data I can build a SOAP messages and
send it with a POST. The response back from the server is XML, which
gets parsed by the XMLHTTPRequest object and I get the responses back
that I want via DOM methods, then change the page by changing the
innerHTML in div elements. This can be done several times on the same
page.
No, I can't put the user in a debugger or anything like that, but I
don't need that for my purposes. This reminds me of the quote that XML
gives you 80% of the functionality of SGML for only 20% of the pain.
XMLHTTPRequests can give you part of what people want to use
continuation-based servers for, without the continuation-based
servers. This is real handy when the web developer can't dictate what
the server is, even if it means some less-than-ideal practices like
having some of the state and flow logic in the client pages.
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <4RlLd.229119$6l.138348@pd7tw2no>
Ralph Richard Cook wrote:
> drewc <·····@rift.com> wrote:
> ...
> I'm keeping all the data in DOM/javascript structures, and sending all
> the parameters to the server each time via the XMLHTTPRequest, either
> in a GET or for more complicated data I can build a SOAP messages and
> send it with a POST. The response back from the server is XML, which
> gets parsed by the XMLHTTPRequest object and I get the responses back
> that I want via DOM methods, then change the page by changing the
> innerHTML in div elements. This can be done several times on the same
> page.
How can you possibly secure this? This is fine if you have a _very_
trivial application, but for anything you have to allow actual users to
access...? You could write Mozilla in bash if you wanted to... I'm just
not sure it's a valid approach.
There is nothing that precludes the use of continuations with a client
side interface, and i can see the utility of the methods you mention,
but you can't try and tell me you'd ever develop a real web application
like that.. the first script kiddie who comes across it is going to own you.
> No, I can't put the user in a debugger or anything like that, but I
> don't need that for my purposes. This reminds me of the quote that XML
> gives you 80% of the functionality of SGML for only 20% of the pain.
But XMLHTTPRequest does not share ANY functionality with a continuation
based server. I don't think you actually know what continuations offer
to a web developer, or you wouldn't be arguing that you can replace them
wth XMLHTTPRequest.
Lisp offers an order of magnitude greater functionality than
javascript+xml for 20% of the pain.
> XMLHTTPRequests can give you part of what people want to use
> continuation-based servers for, without the continuation-based
> servers.
If you find your methods sufficient, that is your perogative. Some
people write their web applications in php. This is the
turing-equivalent argument, and in c.l.l of all places! Shouldn't lisp
users know better?
> This is real handy when the web developer can't dictate what
> the server is, even if it means some less-than-ideal practices like
> having some of the state and flow logic in the client pages.
Sure, but your original statement was "the
XMLHTTPRequest objects available [...] cuts down on the
need for continuations."
You have failed to assert this. Granted, XMLHTTPRequest can reduce the
need to store state on the server. But continuation are much more than
just state, they also represent the compuation to be performed. they are
executable state. As soon as you need to store state on the server
(which is for anything but the most trivial applications), continuations
offer the best way of managing that state.
So, a more accurate statement would be "If you don't need to store state
on your server, and you trust the client(??), then XMLHTTPRequest is
enough for your needs, and you don't need continuations".
What you are doing with the javascript and the XML and the SOAP and all
sounds really cool, but it does not sound any easier than writing a
method. Infact is sounds signficantly more complex. and it still doesn't
deal with the back button or wanting to use multiple copies of the
application.
I'll stick with continuations for now.
drewc
From: Ralph Richard Cook
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <41ffe1ec.7166955@newsgroups.bellsouth.net>
drewc <·····@rift.com> wrote:
>So, a more accurate statement would be "If you don't need to store state
>on your server, and you trust the client(??), then XMLHTTPRequest is
>enough for your needs, and you don't need continuations".
>
Thank you, that sums it up pretty well. That's all I need to do in my
case, and all I really meant in my followup to "Continuations are
overrated".
drewc <·····@rift.com> wrote:
>> Hey, at least it was a longer answer than "Continuations are
>> overrated" :)
>
>I'll take the shorter version over the inacurate one :P
Pascal, would you please elaborate on "Continuations are overrated?"
From: Pascal Costanza
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctog12$ipq$1@snic.vub.ac.be>
Ralph Richard Cook wrote:
> drewc <·····@rift.com> wrote:
>
>>>Hey, at least it was a longer answer than "Continuations are
>>>overrated" :)
>>
>>I'll take the shorter version over the inacurate one :P
>
> Pascal, would you please elaborate on "Continuations are overrated?"
OK, I'll give it a try. I have seen the light when I have seen Marc
Battyani's framework as a live demo at one of last year's Amsterdam Lisp
meetings. I don't know whether I am actually able to communicate this
well...
The back button and cloning pages is good for static web content. The
WWW was originally meant for static content, that's why the back button
and cloning pages were added. (Unfortunately, bidirectional links were
left out which was a mistake, but that's a different story.)
Adding continuations to web applications is motivated by the question
"What are we going to do with the damn back button and the damn
cloning-pages facilities?" It's a solution driven by a technical
accident that wasn't meant for the dynamicity of real applications in
the first place.
The problem is this: Continuations for user interfaces suggest to build
a) modal dialog boxes, or b) wizard-style interfaces. The problem with
those is that a) you are not allowed to check the state of something
else in the background of your application before continuing with a
modal dialog because there is a danger that the dialog doesn't reflect
the current state anymore, and that b) when you have advanced to some
late step in a wizard going back to some early step means that you have
to repeat all the intermediate steps again, which is very
user-unfriendly. If I understand correctly, it has been known in the HCI
community for a long time that modal dialogs and wizard-style interfaces
should be avoided like the plague.
Instead one should design applications according to the needs of users.
This involves asking oneself for what purpose users actually use back
buttons and page cloning, what it is that they _actually_ want to do. I
use the back button and page cloning regularly for checking different
entries in a list of search results one by one. This could be handled in
much simpler ways, for example by adding a container that I can drag and
drop search results into for later review, instead of using an
accidental user-interface element.
What you actually want is a distributed model-view-controller model
where the client presents you the current state of the application and
is updated according to changes in the state. It shouldn't matter how I
got to the page that I am currently viewing.
Pascal
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <az2Md.250922$8l.7015@pd7tw1no>
Pascal Costanza wrote:
> The back button and cloning pages is good for static web content. The
> WWW was originally meant for static content, that's why the back button
> and cloning pages were added. (Unfortunately, bidirectional links were
> left out which was a mistake, but that's a different story.)
> Adding continuations to web applications is motivated by the question
> "What are we going to do with the damn back button and the damn
> cloning-pages facilities?"
I might disagree here. A Continuation based framework happens to solve
those big problems along the way, but the real reason I use
continuations is that it allows me to write my applications using a
'normal' code flow rather then having to create a new state for every
little piece of functionality in a finite state machine model.
> It's a solution driven by a technical
> accident that wasn't meant for the dynamicity of real applications in
> the first place.
This much is very true. The WWW was not designed as a application
delivery medium. not at all.
>
> The problem is this: Continuations for user interfaces suggest to build
> a) modal dialog boxes, or b) wizard-style interfaces.
I've been working using continuations for about 6 months now full time,
and i have yet to build a wizard. A dialogue box yes, but how else is one
to ask the user "are you sure you want to do this (yes/cancel)"?
The Fact that continuations allow one to build a wizard (which i think
of as a "transaction") does not mean one is forced to. For the most
part, a continuation-based application feels the same, to the user, as a
normal web application, only it works.
>The problem with
> those is that a) you are not allowed to check the state of something
> else in the background of your application before continuing with a
> modal dialog because there is a danger that the dialog doesn't reflect
> the current state anymore,
I'll agree that this can be a problem, although i'm not sure what you
mean by "not allowed". In UCW, when a previous continuation is reloaded,
it will reflect the current value of any variables in the component
(unless the slot has its :backtrack set to T). The browser tends to
cache the page, but there are http headers and META tags to help prevent
this. I always try to make sure that the currently displayed page
reflects the state of the underlying application. This can be difficult,
but no more than, say, thread safety. It's just something you have to be
aware of.
> and that b) when you have advanced to some
> late step in a wizard going back to some early step means that you have
> to repeat all the intermediate steps again, which is very
> user-unfriendly.
Why must it be this way? the user can just hit the back button, or you
can have a "back" link that will take you back the the previous step.
These are the problems that CPS solves, not ones it creates.
I know there are some frameworks that simple ignore the back button and
display the same page again when it is used, and that is silly. I've
heard arguments that this is an artefact of using _actual_ first class
continuations (like in scheme) rather than the CPS transforming and the
"partial continuations" (which are really just closures) that we use in
CL, which lacks the real deal. If this is the case, i'll agree with
'continuations are overrated', as all i'm really using is simple
closures and some macros to transform to CPS. I'm not clear on the issue
as i've only ever used UCW.
> If I understand correctly, it has been known in the HCI
> community for a long time that modal dialogs and wizard-style interfaces
> should be avoided like the plague.
A lot of the HCI conclusions are based on research from 20-30 years ago.
People are more comfortable with computers now... and some newer studies
show that people actually prefer the web over traditional applications.
The web, for the most part, has a very simple interface. you click on
the link that says "do something" and something is done. Its not ideal,
but it sure is easy to deliver a web app.
None the less, i agree with you that wizards are ugly (dialogues i'm not
so sure, i've found them quite useful), and should be avoided. But you
can make wizards without continuations, and nothing in CPS forces the
wizard approach.
> Instead one should design applications according to the needs of users.
> This involves asking oneself for what purpose users actually use back
> buttons and page cloning, what it is that they _actually_ want to do.
The back button and session clones are not meant to replace good design.
But, in that absence of it, they can be a convenience. Trying to guess
what your users actually want to do is not an easy undertaking :)
I'd just as soon lose these features when developing applications, but
we are stuck with them. At least CPS makes it somewhat workable.
> I
> use the back button and page cloning regularly for checking different
> entries in a list of search results one by one. This could be handled in
> much simpler ways, for example by adding a container that I can drag and
> drop search results into for later review, instead of using an
> accidental user-interface element.
I thought this was absolute genius, so i stole it outright. I was
working on a search module for a database anyway, so i hacked this idea
into it. Somewhat ironically, it uses a continuation framework. It was
actually quite simple to add this to my exisiting app... just a subclass
really.
There is no drag and drop, but i'm sure it could be hacked up with some
fancy-shmancy javascript. Drag and Drop doesn't work so well with the
keyboard either, so i'd leave the link in as is anyway. :)
If you want to take a look at the idea (which i've called a
'clipboard'), check out:
http://merlin.tech.coop:8080/geo-db/index.ucw
just hit "go" with no search string. this URL should answer for a couple
days.
Here is the all the source i needed to add this functionality. Full
source to the entire application is available as well, just email me.
(defclass search-box-with-clipboard (search-box)
((clipboard :accessor clipboard :initform nil)
(visible :accessor visible :initform t))
(:metaclass standard-component-class))
(defaction add-to-clipboard ((search-box search-box-with-clipboard) item)
(setf (clipboard search-box) (cons item (clipboard search-box))))
(defaction toggle-visible ((s search-box))
(setf (visible s) (not (visible s))))
(defmethod render-on :after ((res response) (search-box
search-box-with-clipboard))
(when (clipboard search-box)
;;clipboard header
(<:h3 (<:as-html "clipboard: ")
(<:as-html (format nil "~A items. " (length (clipboard search-box))))
(<ucw:a :action (toggle-visible search-box)
(<:as-html
(if (visible search-box)
"(hide)"
"(show)"))))
;;clipboard contents
(when (visible search-box)
(<:ul
(dolist (result (clipboard search-box))
(<:li (<ucw:a
:action (view-search-result search-box (second result)
:action (third result))
(<:as-html (first result)))))))))
And i had to add the following to my component for rendering search
results :
(when (slot-exists-p (search-box self) 'clipboard)
(<ucw:a :action (add-to-clipboard (search-box self) result)
(<:as-html " <add to clipboard>")))
>
> What you actually want is a distributed model-view-controller model
> where the client presents you the current state of the application and
> is updated according to changes in the state. It shouldn't matter how I
> got to the page that I am currently viewing.
That sounds like a description of UCW to me ;). I wish that HTTP was
like the X window system and HTML was GTK, but we're stuck with the
current system, which has a lot of advantages outside the application
space. Since i make my living doing mostly web interfaces to databases,
anything that makes this easier is a boon to me, so i will continue to
worship at the altar of CPS :).
drewc
> Pascal
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <jk4y8e6lwhv.fsf@W003275.na.alarismed.com>
drewc <·····@rift.com> writes:
> (<:li (<ucw:a
> :action (view-search-result search-box (second result)
> :action (third result))
^^^^^^^
What does this extra :action keyword argument do? What is the third
element of "result"?
--
Steven E. Harris
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <wlcMd.253446$8l.94185@pd7tw1no>
Steven E. Harris wrote:
> drewc <·····@rift.com> writes:
>
>
>> (<:li (<ucw:a
>> :action (view-search-result search-box (second result)
>> :action (third result))
>
> ^^^^^^^
>
> What does this extra :action keyword argument do? What is the third
> element of "result"?
>
In UCW, 'actions' are methods. My search function returns a list :
'(<description-of-result> <component to 'call' when viewing result>
<action to preform on component prior to calling>)
So the action keyword is just to pass that function. In this case,
(second result) is the result of "(make-instance 'view-component :record
<clsql-view-class>)" and :action is #'view-record.
the definition of VIEW-SEARCH-RESULT:
(defaction view-search-result ((s search-box) component &key (action
nil) (call-component t))
(when action
(funcall action component))
(when call-component
(call-component (find-component (output-container s)
(container.current-component-name
(output-container s)))
component)))
drewc
In article <·····················@pd7tw1no>, drewc wrote:
> Steven E. Harris wrote:
> > drewc <·····@rift.com> writes:
> >
> >
> >> (<:li (<ucw:a
> >> :action (view-search-result search-box (second result)
> >> :action (third result))
[...]
>
> In UCW, 'actions' are methods. My search function returns a list :
>
> '(<description-of-result> <component to 'call' when viewing result>
> <action to preform on component prior to calling>)
>
> So the action keyword is just to pass that function. In this case,
> (second result) is the result of "(make-instance 'view-component :record
> <clsql-view-class>)" and :action is #'view-record.
[...]
UCW looks very, very nice. I'm currently stuck using PHP for web
applications. I've been progressively leaning towards the continuations
(or more precisely closures) style of web programming, but doing this
in PHP is awkward. However looking at UCW is giving me some insight
towards solving my PHP problems.
--
Eric Daniel
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <jk4u0oulwb3.fsf@W003275.na.alarismed.com>
drewc <·····@rift.com> writes:
> Full source to the entire application is available as well, just
> email me.
If you have this all wrapped up in a bundle, I'd like to take a
look. I found your posted code very easy to understand and it piqued
my interest in UCW. Unfortunately, it looks like UCW does not work
with CLISP, my one CL implementation that I could deploy to easily.
--
Steven E. Harris
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <jk4pszilw91.fsf@W003275.na.alarismed.com>
"Steven E. Harris" <···@panix.com> writes:
> If you have this all wrapped up in a bundle, I'd like to take a
> look.
So much for my mastery of private e-mail. Thanks, Gnus.
--
Steven E. Harris
From: Alan Shutko
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87acqm9846.fsf@vera.springies.com>
"Steven E. Harris" <···@panix.com> writes:
> Unfortunately, it looks like UCW does not work with CLISP, my one CL
> implementation that I could deploy to easily.
Actually, ucw has recently added support for clisp with araneida in
the development source. Take a look at the threads
http://common-lisp.net/pipermail/bese-devel/2005-January/thread.html
--
Alan Shutko <···@acm.org> - I am the rocks.
Remember when safe sex was waiting for parents to be away?
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <EK2Md.252028$Xk.25204@pd7tw3no>
drewc wrote:
> Pascal Costanza wrote:
>> and that b) when you have advanced to some late step in a wizard going
>> back to some early step means that you have to repeat all the
>> intermediate steps again, which is very user-unfriendly.
>
>
> Why must it be this way? the user can just hit the back button, or you
> can have a "back" link that will take you back the the previous step.
> These are the problems that CPS solves, not ones it creates.
I misread your paragraph, so my answer here is a little off. feel free
to ignore it as i agree with you completely WRT wizards :)
drewc
From: Pascal Costanza
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctqnrb$rta$1@snic.vub.ac.be>
drewc wrote:
> I've been working using continuations for about 6 months now full time,
> and i have yet to build a wizard. A dialogue box yes, but how else is one
> to ask the user "are you sure you want to do this (yes/cancel)"?
Don't. It's better to allow users to "undo" operations, instead of
asking them whether they are sure and only later let them find out that
they actually weren't.
> I know there are some frameworks that simple ignore the back button and
> display the same page again when it is used, and that is silly. I've
> heard arguments that this is an artefact of using _actual_ first class
> continuations (like in scheme) rather than the CPS transforming and the
> "partial continuations" (which are really just closures) that we use in
> CL, which lacks the real deal. If this is the case, i'll agree with
> 'continuations are overrated', as all i'm really using is simple
> closures and some macros to transform to CPS. I'm not clear on the issue
> as i've only ever used UCW.
I also recall reading somewhere that there's a difference between web
interactions based on first-class continuations and those based on CPS,
but I really don't have such a deep knowledge about the details.
> None the less, i agree with you that wizards are ugly (dialogues i'm not
> so sure, i've found them quite useful), and should be avoided. But you
> can make wizards without continuations, and nothing in CPS forces the
> wizard approach.
My impression is that it suggests it. I don't know whether it's forced.
But there are quite a few web applications where you get wizard-style
interfaces and I find that ugly. First you check out your shopping cart,
then you type in your address, then your credit card details, then you
confirm again - oops, I have forgotten about the other thing that I
wanted to buy, so back to the start again...). My impression is that
continuation-based web frameworks try specifically to ease that
interaction style. At least, that's what I have got from the few papers
that I have read about them.
The following statements:
> The back button and session clones are not meant to replace good design.
> But, in that absence of it, they can be a convenience. Trying to guess
> what your users actually want to do is not an easy undertaking :)
>
> I'd just as soon lose these features when developing applications, but
> we are stuck with them. At least CPS makes it somewhat workable.
...and...
> I wish that HTTP was
> like the X window system and HTML was GTK, but we're stuck with the
> current system
[...]
...are probably the heart of the problem, AFAICT.
Pascal
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <rc6Md.251602$8l.5095@pd7tw1no>
Just noticed some hits to that demo URL (was that you Pascal?), while i
was recompiling it. It was probably broken for you as my slime debugger
popped up a few times, but it's fixed now an i'm going to bed! I'm sure
you'll find another creative way to break it ;))
drewc
From: Marc Battyani
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctrl79$cpu@library2.airnews.net>
"Pascal Costanza" <··@p-cos.net> wrote
> > Pascal, would you please elaborate on "Continuations are overrated?"
I agree ;-)
> OK, I'll give it a try. I have seen the light when I have seen Marc
> Battyani's framework as a live demo at one of last year's Amsterdam Lisp
> meetings. I don't know whether I am actually able to communicate this
> well...
>
> The back button and cloning pages is good for static web content. The
> WWW was originally meant for static content, that's why the back button
> and cloning pages were added. (Unfortunately, bidirectional links were
> left out which was a mistake, but that's a different story.)
Here I don't fully agree, I like a lot the back button and cloning
especially in complex applications. My framework works with them without
using continuations. It also works with multipages and tabs.
> Adding continuations to web applications is motivated by the question
> "What are we going to do with the damn back button and the damn
> cloning-pages facilities?" It's a solution driven by a technical
> accident that wasn't meant for the dynamicity of real applications in
> the first place.
And it's a wrong solution IMO.
When I hit the back button I want to go back to the place where I was but
not into the state I was at that time.
As an example, suppose I'm looking at a page displaying a list of objects.
On that page I have a "add an object" button. I click on it, this brings me
in the page to fill the new object. Now when I click on the back button, I
obviously want to see my list with the new object not the previous list.
Also having the state in the client mean that other users or the server
can't see the actual state of the system. So collaborative work on the same
objects is impossible.
> The problem is this: Continuations for user interfaces suggest to build
> a) modal dialog boxes, or b) wizard-style interfaces. The problem with
> those is that a) you are not allowed to check the state of something
> else in the background of your application before continuing with a
> modal dialog because there is a danger that the dialog doesn't reflect
> the current state anymore, and that b) when you have advanced to some
> late step in a wizard going back to some early step means that you have
> to repeat all the intermediate steps again, which is very
> user-unfriendly. If I understand correctly, it has been known in the HCI
> community for a long time that modal dialogs and wizard-style interfaces
> should be avoided like the plague.
>
> Instead one should design applications according to the needs of users.
> This involves asking oneself for what purpose users actually use back
> buttons and page cloning, what it is that they _actually_ want to do. I
> use the back button and page cloning regularly for checking different
> entries in a list of search results one by one. This could be handled in
> much simpler ways, for example by adding a container that I can drag and
> drop search results into for later review, instead of using an
> accidental user-interface element.
I do that too ;-) My framework displays a list then I open a new window/tab
and drag/drop the links to sub-objects in them. I'm even implementing the
cut and paste of objects in lists now.
> What you actually want is a distributed model-view-controller model
> where the client presents you the current state of the application and
> is updated according to changes in the state. It shouldn't matter how I
> got to the page that I am currently viewing.
Exactly! And several users looking at the same objects should see the same
state. (not the same view is they have different authorization levels/roles)
Marc
From: Antonio Menezes Leitao
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87brb1keg8.fsf@gia.ist.utl.pt>
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Pascal Costanza" <··@p-cos.net> wrote
>> Adding continuations to web applications is motivated by the question
>> "What are we going to do with the damn back button and the damn
>> cloning-pages facilities?" It's a solution driven by a technical
>> accident that wasn't meant for the dynamicity of real applications in
>> the first place.
I don't think that's the main reason for having continuations in web
applications. In fact, even if there wasn't the back and clone
buttons, I still think that continuations would still be useful to
structure web applications.
>
> And it's a wrong solution IMO.
> When I hit the back button I want to go back to the place where I was but
> not into the state I was at that time.
I would say that there isn't a unique solution. In fact, sometimes "I
want to go back to the place where I was but not into the state I was
at that time" and some other times "I want to go back to the place
where I was and into the state I was at that time". UCW allows both
and it's very simple to choose one or the other.
> As an example, suppose I'm looking at a page displaying a list of objects.
> On that page I have a "add an object" button. I click on it, this brings me
> in the page to fill the new object. Now when I click on the back button, I
> obviously want to see my list with the new object not the previous list.
That's what UCW will give you by default, _unless_ you ask it to allow
the state to backtrack.
> Also having the state in the client mean that other users or the server
> can't see the actual state of the system. So collaborative work on the same
> objects is impossible.
That's not a problem for UCW. The state is in the server (although,
conceptually, you can have many possible states if you choose to have
them).
>> What you actually want is a distributed model-view-controller model
>> where the client presents you the current state of the application and
>> is updated according to changes in the state. It shouldn't matter how I
>> got to the page that I am currently viewing.
>
> Exactly! And several users looking at the same objects should see the same
> state. (not the same view is they have different authorization levels/roles)
That's something that I'm currently doing with UCW without any
problems.
Ant�nio Leit�o.
From: Pascal Costanza
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <cttnag$flt$1@snic.vub.ac.be>
Antonio Menezes Leitao wrote:
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
>>"Pascal Costanza" <··@p-cos.net> wrote
>
>>>Adding continuations to web applications is motivated by the question
>>>"What are we going to do with the damn back button and the damn
>>>cloning-pages facilities?" It's a solution driven by a technical
>>>accident that wasn't meant for the dynamicity of real applications in
>>>the first place.
>
> I don't think that's the main reason for having continuations in web
> applications. In fact, even if there wasn't the back and clone
> buttons, I still think that continuations would still be useful to
> structure web applications.
What for?
Pascal
From: Antonio Menezes Leitao
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87brb1xyyg.fsf@gia.ist.utl.pt>
Pascal Costanza <··@p-cos.net> writes:
> Antonio Menezes Leitao wrote:
>
>> "Marc Battyani" <·············@fractalconcept.com> writes:
>>
>>>"Pascal Costanza" <··@p-cos.net> wrote
>>
>>>>Adding continuations to web applications is motivated by the question
>>>>"What are we going to do with the damn back button and the damn
>>>>cloning-pages facilities?" It's a solution driven by a technical
>>>>accident that wasn't meant for the dynamicity of real applications in
>>>>the first place.
>> I don't think that's the main reason for having continuations in web
>> applications. In fact, even if there wasn't the back and clone
>> buttons, I still think that continuations would still be useful to
>> structure web applications.
>
> What for?
>
To allow you to program in direct style while allowing your flow of
control to suspend while you wait for some information that you
requested from the user.
Let me give you one example in UCW. Here are two hypotetical actions:
(defaction list-current-applications ((w foo-window))
(let ((applications (mapcan #'unit-applications
(select-units w (units (user w))))))
(if (endp applications)
(window-warn w "There are no approved applications.")
(show-applications w applications))))
The idea is that list-current-applications will show (in a tabular
form) a list of approved applications but, first, it is necessary to
choose a unit to work with. That's the purpose of the select-units
call. Here is its definition:
(defaction select-units ((w foo-window) units)
(cond ((endp (rest units))
(list (first units)))
(t
(call 'choose-subset
:title "Choose the units you want to see"
:set units
:item-view #'name))))
The intended behavior is:
- in case the user belongs to a single unit, the action returns it and
list-current-applications proceeds just like if the call was made to
a regular Common Lisp function.
- in case the user belongs to more than one, we present him with a
page where he can choose among its units the ones he wants to use
(that's the (call 'choose-subset ...)). When he makes his choice,
the choosen units are returned to the (suspended) action
list-current-applications that will then proceed.
If there are simpler or better ways to achieve this I would love to
see them.
Ant�nio Leit�o.
From: Marc Battyani
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctu9ns$8fn@library2.airnews.net>
"Antonio Menezes Leitao" <···@aleph.local> wrote
> Pascal Costanza <··@p-cos.net> writes:
>
> > Antonio Menezes Leitao wrote:
> >
> >> "Marc Battyani" <·············@fractalconcept.com> writes:
> >>
> >>>"Pascal Costanza" <··@p-cos.net> wrote
> >>
> >>>>Adding continuations to web applications is motivated by the question
> >>>>"What are we going to do with the damn back button and the damn
> >>>>cloning-pages facilities?" It's a solution driven by a technical
> >>>>accident that wasn't meant for the dynamicity of real applications in
> >>>>the first place.
> >> I don't think that's the main reason for having continuations in web
> >> applications. In fact, even if there wasn't the back and clone
> >> buttons, I still think that continuations would still be useful to
> >> structure web applications.
> >
> > What for?
> >
>
> To allow you to program in direct style while allowing your flow of
> control to suspend while you wait for some information that you
> requested from the user.
>
> Let me give you one example in UCW. Here are two hypotetical actions:
>
> (defaction list-current-applications ((w foo-window))
> (let ((applications (mapcan #'unit-applications
> (select-units w (units (user w))))))
> (if (endp applications)
> (window-warn w "There are no approved applications.")
> (show-applications w applications))))
>
> The idea is that list-current-applications will show (in a tabular
> form) a list of approved applications but, first, it is necessary to
> choose a unit to work with. That's the purpose of the select-units
> call. Here is its definition:
>
> (defaction select-units ((w foo-window) units)
> (cond ((endp (rest units))
> (list (first units)))
> (t
> (call 'choose-subset
> :title "Choose the units you want to see"
> :set units
> :item-view #'name))))
>
> The intended behavior is:
>
> - in case the user belongs to a single unit, the action returns it and
> list-current-applications proceeds just like if the call was made to
> a regular Common Lisp function.
>
> - in case the user belongs to more than one, we present him with a
> page where he can choose among its units the ones he wants to use
> (that's the (call 'choose-subset ...)). When he makes his choice,
> the choosen units are returned to the (suspended) action
> list-current-applications that will then proceed.
>
> If there are simpler or better ways to achieve this I would love to
> see them.
OK you are showing what Pascal Costanza wrote in some earlier post,
continuations are good for modal stuff.
The question is why use continuations for all when they are only useful in
modal processing.
Marc
From: Antonio Menezes Leitao
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87r7jxunlf.fsf@gia.ist.utl.pt>
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Antonio Menezes Leitao" <···@aleph.local> wrote
>>
>> - in case the user belongs to a single unit, the action returns it and
>> list-current-applications proceeds just like if the call was made to
>> a regular Common Lisp function.
>>
>> - in case the user belongs to more than one, we present him with a
>> page where he can choose among its units the ones he wants to use
>> (that's the (call 'choose-subset ...)). When he makes his choice,
>> the choosen units are returned to the (suspended) action
>> list-current-applications that will then proceed.
>>
>> If there are simpler or better ways to achieve this I would love to
>> see them.
>
> OK you are showing what Pascal Costanza wrote in some earlier post,
> continuations are good for modal stuff.
> The question is why use continuations for all when they are only useful in
> modal processing.
The problem is that when I'm prototyping my web application, I have
some difficulty anticipating the places where I'll need modal stuff.
In the above example, in the first version of the application users
belonged to a single unit so there was no problem about choosing its
unit. Latter on, I decided that users could belong to more than one
unit, requiring a bit of modality to choose among different units.
Would it be equally easy to include that bit of modality in the middle
of the control flow if I wasn't using continuations for the entire set
of actions?
As I said previously, I'm really interested in simpler solutions to
this problem. And knowing more about your framework is also on my
list.
Ant�nio Leit�o.
From: Pascal Costanza
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <cu0ec1$c5$1@snic.vub.ac.be>
Antonio Menezes Leitao wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Antonio Menezes Leitao wrote:
>>
>>>"Marc Battyani" <·············@fractalconcept.com> writes:
>>>
>>>>"Pascal Costanza" <··@p-cos.net> wrote
>>>
>>>>>Adding continuations to web applications is motivated by the question
>>>>>"What are we going to do with the damn back button and the damn
>>>>>cloning-pages facilities?" It's a solution driven by a technical
>>>>>accident that wasn't meant for the dynamicity of real applications in
>>>>>the first place.
>>>
>>>I don't think that's the main reason for having continuations in web
>>>applications. In fact, even if there wasn't the back and clone
>>>buttons, I still think that continuations would still be useful to
>>>structure web applications.
>>
>>What for?
>
> To allow you to program in direct style while allowing your flow of
> control to suspend while you wait for some information that you
> requested from the user.
The only thing I am concerned about is that both the web application
"metaphor" and continuation-based web frameworks encourage to code the
user interaction in the wizard style of "first you have to do this, then
you have to do that". They seem to specifically discourage people to
think of better alternatives that may be more interactive and more
user-friendly.
For example, I am pretty sure that this is the main reason why Apple
didn't implement iTunes as a web application - although I also think
that searching in the iTunes Music Store is still too web-like.
I am not saying that, given that a wizard-style interaction is the best
interaction model for your specific application, you shouldn't implement
your app as a wizard and shouldn't use the best available approach for
doing that. I am saying that web applications seem to be developed
foremostly along the technical limitations of web browsers instead of
what would actually be better for users. And continuation-based web
application frameworks do not improve that situation.
But maybe this is just another instance of worse is better...
Pascal
From: Antonio Menezes Leitao
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <878y64126n.fsf@gia.ist.utl.pt>
Pascal Costanza <··@p-cos.net> writes:
> The only thing I am concerned about is that both the web application
> "metaphor" and continuation-based web frameworks encourage to code the
> user interaction in the wizard style of "first you have to do this,
> then you have to do that".
You can code that way but you don't need to and I'm sure you will not
do it unless you really need it. I can confirm your feeling that,
sometimes, wizard style forms are annoying as I have just changed one
such form to become less wizard style. But that's just one example of
the different styles that you can explore. Sometimes, it's useful to
be modal, sometimes it's not. Continuation-based web frameworks allow
both.
> They seem to specifically discourage people to think of better
> alternatives that may be more interactive and more user-friendly.
I agree that most demos of continuation-based web frameworks present
examples of wizard-style forms, but that's because that's what makes
then different from other frameworks. However, that's not the end of
the story. If you have a more interactive and/or more user-friendly
alternative, there's nothing that prevents you to integrate it in a
continuation-based web framework. The opposite (i.e., including
modality in non-continuation-based web frameworks) looks to me as a
much harder task.
> For example, I am pretty sure that this is the main reason why Apple
> didn't implement iTunes as a web application - although I also think
> that searching in the iTunes Music Store is still too web-like.
We agree. Unfortunately, even when it was obvious that a 'normal'
application would give you a much better user experience, I saw
several clients demanding the web application: "that's what everybody
is doing so it must be the right choice", they say :-(
> I am not saying that, given that a wizard-style interaction is the
> best interaction model for your specific application, you shouldn't
> implement your app as a wizard and shouldn't use the best available
> approach for doing that. I am saying that web applications seem to be
> developed foremostly along the technical limitations of web browsers
> instead of what would actually be better for users. And
> continuation-based web application frameworks do not improve that
> situation.
Yes. But they make my life a bit easier. That's good, IMHO.
> But maybe this is just another instance of worse is better...
:-)
Ant�nio.
From: Marco Baringer
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <m2fz0dh5np.fsf@soma.local>
Pascal Costanza <··@p-cos.net> writes:
> Antonio Menezes Leitao wrote:
>
>> "Marc Battyani" <·············@fractalconcept.com> writes:
>>
>>>"Pascal Costanza" <··@p-cos.net> wrote
>>
>>>>Adding continuations to web applications is motivated by the question
>>>>"What are we going to do with the damn back button and the damn
>>>>cloning-pages facilities?" It's a solution driven by a technical
>>>>accident that wasn't meant for the dynamicity of real applications in
>>>>the first place.
>> I don't think that's the main reason for having continuations in web
>> applications. In fact, even if there wasn't the back and clone
>> buttons, I still think that continuations would still be useful to
>> structure web applications.
>
> What for?
clarity.
using continuations allow you to code a web app in the same way you
think about it. instead of having to think in terms of pages and
requests and response you can think in terms of user actions and how
these are tied together.
this, and not so much the back button stuff, was the focus of a talk i
gave about ucw a while ago. if you'd like the (short and brief) slides
are available: http://common-lisp.net/project/ucw/docs/UCW-en.pdf
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
From: Marc Battyani
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctube0$1pa@library2.airnews.net>
"Marco Baringer" <··@bese.it> wrote
> Pascal Costanza <··@p-cos.net> writes:
>
> > Antonio Menezes Leitao wrote:
> >
> >> "Marc Battyani" <·············@fractalconcept.com> writes:
> >>
> >>>"Pascal Costanza" <··@p-cos.net> wrote
> >>
> >>>>Adding continuations to web applications is motivated by the question
> >>>>"What are we going to do with the damn back button and the damn
> >>>>cloning-pages facilities?" It's a solution driven by a technical
> >>>>accident that wasn't meant for the dynamicity of real applications in
> >>>>the first place.
> >> I don't think that's the main reason for having continuations in web
> >> applications. In fact, even if there wasn't the back and clone
> >> buttons, I still think that continuations would still be useful to
> >> structure web applications.
> >
> > What for?
>
> clarity.
>
> using continuations allow you to code a web app in the same way you
> think about it. instead of having to think in terms of pages and
> requests and response you can think in terms of user actions and how
> these are tied together.
Well this implies that actions are linked together and that there is some
order (like choose articles, checkout, payment, confirmation) but this is
only the case in simple applications. In a complex application with 100's of
CLOS classes there is no such ordering except locally for "are you sure ?"
questions which are so simple that they don't need continuations either.
> this, and not so much the back button stuff, was the focus of a talk i
> gave about ucw a while ago. if you'd like the (short and brief) slides
> are available: http://common-lisp.net/project/ucw/docs/UCW-en.pdf
OK I read it. I've also read Queinnec's paper about the web and
continuations. But he has a very narrow view of web applications that does
not fit complex collaborative applications IMO.
Note that I'm not discussing UCW which seems very nice. ;-)
I'm just making the point that continuations are not the ultimate solution
for complex web applications.
Marc
From: Alan Shutko
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87is59xedl.fsf@vera.springies.com>
"Marc Battyani" <·············@fractalconcept.com> writes:
> In a complex application with 100's of CLOS classes there is no such
> ordering except locally for "are you sure ?" questions which are so
> simple that they don't need continuations either.
It depends on the application. In the call center application I
develop at work (about 100KLOC of java, with about 200 separate pages)
there's a fairly large amount of ordered operations which this would
help with. If we were to refactor it to actually be task-oriented (to
speed call handling) the number of ordered operations would go up a
lot.
Naturally, the benefit a project would get from continuations is
dependent on the application, but there are complex applications out
there which would benefit. Alas, we now have tons of code so we won't
be switching to UCW any time soon.
--
Alan Shutko <···@acm.org> - I am the rocks.
:) :( :) :( :) :( :) Facial Isometrics
From: Marco Baringer
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <m28y64d32o.fsf@soma.local>
"Marc Battyani" <·············@fractalconcept.com> writes:
>> > What for?
>>
>> clarity.
>>
>> using continuations allow you to code a web app in the same way you
>> think about it. instead of having to think in terms of pages and
>> requests and response you can think in terms of user actions and how
>> these are tied together.
>
> Well this implies that actions are linked together and that there is some
> order (like choose articles, checkout, payment, confirmation) but this is
> only the case in simple applications.
i don't agree.
> In a complex application with 100's of
> CLOS classes there is no such ordering except locally for "are you sure ?"
> questions which are so simple that they don't need continuations either.
i'll concede that confirmation dialogs are banal, and if you're
application only ever presents a couple forms at a time, and never
does more than ask 'are you sure?' then continuations are overkill.
maybe what i'm talking about are just glorified wizards (for lack of a
better word), but they're wizards which require 20 to a hundred
"pages", can take anywhere from 10 minutes to an hour to complete and
are not formed by a linear 1-2-3 step process but have many different
branches. these "wizards" are hundreds of times easier to code and
maintain using continuations than without them.
>> this, and not so much the back button stuff, was the focus of a talk i
>> gave about ucw a while ago. if you'd like the (short and brief) slides
>> are available: http://common-lisp.net/project/ucw/docs/UCW-en.pdf
>
> OK I read it. I've also read Queinnec's paper about the web and
> continuations. But he has a very narrow view of web applications that does
> not fit complex collaborative applications IMO.
>
> Note that I'm not discussing UCW which seems very nice. ;-)
> I'm just making the point that continuations are not the ultimate solution
> for complex web applications.
there is no "ultimate solution" to complex web applications. however,
simply because there is no ultimate solution does not imply that all
solutions and tools are equal. continuations are a powerfull tool
which solve a problem i happen to have, i don't expect everyone to
have the same problem.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
From: Steven E. Harris
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <jk4acqkia52.fsf@W003275.na.alarismed.com>
"Marco Baringer" <··@bese.it> writes:
> maybe what i'm talking about are just glorified wizards (for lack of
> a better word), but they're wizards which require 20 to a hundred
> "pages", can take anywhere from 10 minutes to an hour to complete
> and are not formed by a linear 1-2-3 step process but have many
> different branches.
Intuit's "TurboTax for the Web" comes to mind.
--
Steven E. Harris
From: Marc Battyani
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <ctu9n0$ng1@library2.airnews.net>
"Antonio Menezes Leitao" <···@aleph.local> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > "Pascal Costanza" <··@p-cos.net> wrote
>
> > And it's a wrong solution IMO.
> > When I hit the back button I want to go back to the place where I was
but
> > not into the state I was at that time.
>
> I would say that there isn't a unique solution. In fact, sometimes "I
> want to go back to the place where I was but not into the state I was
> at that time" and some other times "I want to go back to the place
> where I was and into the state I was at that time". UCW allows both
> and it's very simple to choose one or the other.
>
> > As an example, suppose I'm looking at a page displaying a list of
objects.
> > On that page I have a "add an object" button. I click on it, this brings
me
> > in the page to fill the new object. Now when I click on the back button,
I
> > obviously want to see my list with the new object not the previous list.
>
> That's what UCW will give you by default, _unless_ you ask it to allow
> the state to backtrack.
>
> > Also having the state in the client mean that other users or the server
> > can't see the actual state of the system. So collaborative work on the
same
> > objects is impossible.
>
> That's not a problem for UCW. The state is in the server (although,
> conceptually, you can have many possible states if you choose to have
> them).
Uh? I though that the continuation paradigm was to have the state in the
client ?
Note that we are not discussing UCW but continuations for web applications.
> >> What you actually want is a distributed model-view-controller model
> >> where the client presents you the current state of the application and
> >> is updated according to changes in the state. It shouldn't matter how I
> >> got to the page that I am currently viewing.
> >
> > Exactly! And several users looking at the same objects should see the
same
> > state. (not the same view is they have different authorization
levels/roles)
>
> That's something that I'm currently doing with UCW without any
> problems.
You mean that if a user changes a value in a slot then all the views reflect
that new value ?
I don't see how continuations will help for that.
Marc
From: Antonio Menezes Leitao
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <87mzulum9a.fsf@gia.ist.utl.pt>
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Antonio Menezes Leitao" <···@aleph.local> wrote
>> "Marc Battyani" <·············@fractalconcept.com> writes:
>>
>> > Also having the state in the client mean that other users or the
>> > server can't see the actual state of the system. So collaborative
>> > work on the same objects is impossible.
>>
>> That's not a problem for UCW. The state is in the server (although,
>> conceptually, you can have many possible states if you choose to have
>> them).
>
> Uh? I though that the continuation paradigm was to have the state in
> the client ? Note that we are not discussing UCW but continuations
> for web applications.
>
OK. I was thinking about continuations in general.
If, by "continuations for web applications paradigm", you mean the
funny examples of applications where the back button makes you travel
in time, then I agree with you that they are not very useful. I made
a few of them just for fun and that's it: they are fun. End of story.
But I thinks that's a very restricted view of the usefulness of
continuations. It is perfectly possible to have state on the server
and, at the same time, use continuations to code you program in direct
style (while allowing it to be suspended and resumed acording to the
user interaction).
Maybe it's overkill to use continuations in this case but they really
make the code look cleaner and more maintainable. OTOH, I'm a bit
concerned about performance problems. I'll have to stress test my
application to see what happens.
> You mean that if a user changes a value in a slot then all the views
> reflect that new value ? I don't see how continuations will help
> for that.
That has nothing to do with continuations. If you invoke a
continuation that was captured before some side-effects where done,
those side-effects will not be undone (unless you code in advance for
that behavior). This means that you can have state on the server and
that all clients can modify that state and see the modifications.
But, as you said, maybe we are talking about different meanings for
the word "continuation".
Ant�nio Leit�o.
On Wed, 26 Jan 2005 20:33:57 -0800, devmail wrote:
> Has UnCommon SQL reached the functional level or Common SQL, or is it
> necessary to buy Common SQL (LW Enterprise) if you are doing lots of DB
> work?
UncommonSQL isn't being maintained any longer. Kevin Rosenberg's CLSQL
obsoletes it. See http://clsql.b9.com/ . I use CLSQL a lot for work. It's
a lot closer to the CommonSQL spec, much more reliable and of course is
still under active maintenance.
·······@runbox.com writes:
> All of the examples of domain specific languages I have seen in Lisp
> keep the lispy syntax. Can anyone point me to examples of a DSL that
> uses, say, a BASIC or C-style syntax (or is that even possible)?
This paper by Olin Shivers:
A Universal Scripting Framework
or
Lambda: the ultimate "little language"
http://citeseer.ist.psu.edu/607803.html
provides some insight on why Lispers prefer DSLs with Lispy syntax.
The paper focuses on Scheme examples, but the ideas apply also to
other languages in the Lisp family.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
The paper "Continuations continued: the REST of the computation"
by Anton van Straaten explores both the traditional and
the continuation approach in
<http://ll4.csail.mit.edu/slides/rest-slides.pdf>
The presentation at LL4 was caught on video (skip the first 29 min)
<http://web.mit.edu/webcast/csail/mit-csail-lwl-04dec2004-afternoon1-80k.ram>
--
Jens Axel Søgaard
From: drewc
Subject: Re: Specific questions from Lisp newbie (Please don't taunt the fresh blood)
Date:
Message-ID: <MjUMd.272241$6l.76680@pd7tw2no>
Jens Axel S�gaard wrote:
> The paper "Continuations continued: the REST of the computation"
> by Anton van Straaten explores both the traditional and
> the continuation approach in
I saw this a few months ago, and i really enjoyed it. I love the REST
approach for its pureness, but i like Continuations for the ease of
development. This talk attempts to unify the approaches (or at least
show that they are not mutually exclusive). I must see for anybody
developing web applications!
Two Thumbs Up!
drewc
>
> <http://ll4.csail.mit.edu/slides/rest-slides.pdf>
>
> The presentation at LL4 was caught on video (skip the first 29 min)
>
> <http://web.mit.edu/webcast/csail/mit-csail-lwl-04dec2004-afternoon1-80k.ram>
>
>
>