Summary: I have recently tried to inquire about Common Lisp web
frameworks vs Scheme web frameworks on #lisp (I know, it smells like a
flamebait, but I really didn't mean that). This post is a summary of my
experiences, as well as a restatement of my questions.
I originally learned Lisp at age 10 (about 20 years ago), used it in
college (about 10 years ago) ant only returned to it about a year ago
due to Paul Graham's recent advocacy. Naturally, I figured that the
best hacker real estate is in web programming because this is the only
way to escape the long shadow of C/C++/Java. I settled on Scheme after
seeing that it has built-in continuations, and at least one
well-documented framework. I am currently working on web applications,
using a Scheme framework (SISCweb, if anyone cares).
Before settling on Scheme, I have tried to learn UCW, but found the
lack of detailed documentation troubling (no, I haven't seen the recent
50-meg video). However, I feel bad about choosing a language based
mostly on the documentation volume.
So today, I worked my courage up, posted a big disclaimer, and asked
the folks on #lisp about Scheme vs Lisp, especially as it relates to
webapp frameworks. I got banned within 5 minutes (thanks Xophe !) and
never really learned much, other than being pointed to SBCL (which, as
far as I can tell, is a CMUCL fork that still has threading and Mac OSX
bugs).
So, to anyone who has looked at both CL and Scheme recently: are there
any well-documented, thread-safe, more-featureful-than-Scheme CL web
frameworks? And please don't label me a troll again; occasionally,
cross-language, cross-newsgroup concerns are valid issues.
-- Dan
<········@yahoo.com> wrote:
+---------------
| ...never really learned much, other than being pointed to SBCL
| (which, as far as I can tell, is a CMUCL fork that still has
| threading and Mac OSX bugs).
|
| So, to anyone who has looked at both CL and Scheme recently: are there
| any well-documented, thread-safe, more-featureful-than-Scheme CL web
| frameworks?
+---------------
If you don't want to jump all the way to UCW at once, try some of
the other, simpler packages listed on <http://www.cliki.net/web>.
Personally, I wrote my own web framework, very simple, something
a bit more than <http://www.cliki.net/cl-modlisp> but quite a bit
less than <http://www.cliki.net/araneida>, which sits behind Apache,
communicating through a C-based CGI that using "mod_lisp" protocol
[but which is not <http://www.cliki.net/mod_lisp> per se]. I run
it on CMUCL on top of both Linux & FreeBSD, using CMUCL's "green"
threads[1], with a new thread for each HTTP request, and have never
had any trouble with the threading aspects. YMMV.
-Rob
[1] Which CMUCL calls "multiprocessing" ("MP" package), but it's
really just within-process co-routining or multiprogramming.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christophe Rhodes
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <sqmzh4p0e0.fsf@cam.ac.uk>
········@yahoo.com writes:
> So today, I worked my courage up, posted a big disclaimer, and asked
> the folks on #lisp about Scheme vs Lisp, especially as it relates to
> webapp frameworks. I got banned within 5 minutes (thanks Xophe !).
<http://meme.b9.com/cview.html?channel=lisp&start=3348251388&end=3348252232>
contains a log of the discussion, in case anyone wishes to draw their
own conclusions.
Christophe
(In case any onlooker is in any doubt: "Xophe" is me)
Cristophe, since you are reading this, what's a good way to discuss
the issue that I have raised? I feel that this topic has some worth,
even if perhaps #lisp is not the best medium for discussing it. I am
genuinely curious. Perhaps UCW is only for hackers who "don't need no
stinking docs". Or perhaps not.
In any case, I enjoy(ed) reading #lisp in the past and see no reason
why cross-lisp questions (such as CL vs Scheme) shouldn't have take
place. Would you agree with that?
-- Dan
········@yahoo.com wrote:
> Cristophe, since you are reading this, what's a good way to discuss
> the issue that I have raised? I feel that this topic has some worth,
That Common Lisp sucks because it has NIL instead of #f and
false?
Christophe Rhodes wrote:
> ········@yahoo.com writes:
>
>
>>So today, I worked my courage up, posted a big disclaimer, and asked
>>the folks on #lisp about Scheme vs Lisp, especially as it relates to
>>webapp frameworks. I got banned within 5 minutes (thanks Xophe !).
>
>
> <http://meme.b9.com/cview.html?channel=lisp&start=3348251388&end=3348252232>
> contains a log of the discussion, in case anyone wishes to draw their
> own conclusions.
>
Thanks. Let's see how greenash does on c.l.l and we can compare and
contrast.
kenny
On Mon, 06 Feb 2006 22:50:47 +0000, Christophe Rhodes
<·····@cam.ac.uk> wrote:
>contains a log of the discussion, in case anyone wishes to draw their
>own conclusions.
Scheme vs CL vs whatever, is an issue worth periodic discussion.
Where is the best place for such discussions? It should be an obvious
place, so people who want to participate in such discussions will know
where to look for them. And/or maybe some kind of autoresponder could
be installed in places where such discussions aren't wanted, which
would automatically respond to such discussions with directions to the
correct place for them.
Kicking people off a forum without plenty of clear warning seems rude.
Warnings that may seem clear to locals aren't clear to newbies. The
warning should say explicitly that if he continues to discuss the
particular topic he will be banned. You can't assume that a person
with an unwanted topic is never going to have any wanted topics.
····@unreal.uncom wrote:
> On Mon, 06 Feb 2006 22:50:47 +0000, Christophe Rhodes
> <·····@cam.ac.uk> wrote:
>
> >contains a log of the discussion, in case anyone wishes to draw their
> >own conclusions.
>
> Scheme vs CL vs whatever, is an issue worth periodic discussion.
> Where is the best place for such discussions? It should be an obvious
> place, so people who want to participate in such discussions will know
> where to look for them. And/or maybe some kind of autoresponder could
> be installed in places where such discussions aren't wanted, which
> would automatically respond to such discussions with directions to the
> correct place for them.
Hi,
The problem is a little deeper than it seems, and not unique to Lisp.
Due to various pressures.
One of the first questions I asked here was about the flaws of Lisp. (I
wanted to be able to evaluate it better; one good way to do this is by
understanding its flaws.) People clammed up and suspiciously asked my
motives; I later learned this happened because of the enormous scale of
disinformation and hostility directed against Lisp. The small benefits
of telling some curious newbie the disadvantages paled in comparison
with the disadvantages of giving people "ammo" to shoot down Lisp some
more.
Now, these flaws would've probably applied to other languages as well,
assuming they were even powerful enough to suffer from them. But
remember, this is the profession which considers gotos harmful based on
some editor changing a paper's title from its original. You can imagine
everyone's reticence of simply giving away free ammo like it was a
flamewarrior's Christmas.
Am I saying this as a Lisp programmer? No, I'm saying this as a
programmer. The entire profession is warped away from technical issues;
I certainly feel these pressures. People actually go around speaking of
the "Lisp community" as some homogenous entity which thinks the same
things and has the same motivations. Motivations which these people
invent. And they are not drawn to Lisp by technical issues; the tech
industry is about technology probably as much as the music industry is
about music.
So yeah, banning the guy was unpleasant, but the problem isn't the
semi-mythical "Lisp community." The situation is so bad, that I used to
turn to the Java BileBlog for serious Java commentary, frothing as it
is.
Even worse, I have no forum to mention my real thoughts about Common
Lisp. I've read enough history to vaguely help answer my question about
Lisp's flaws. But there is simply no place where I can seriously
discuss this, because today's languages are so grotesquely malformed
and there's so much competitive pressure to be some "ambassador" that
technical discussion seems impossible.
Enough to make anyone grumpy.
Tayssir
OK. Forget what people might or might not do, and let's have a
technical discussion. What am I missing by using Scheme (and Scheme web
frameworks in particular) instead of Lisp?
I could easily point out what people miss by using Lisp instead of
Scheme: continuations. Yes, theoretically a CPS-transforming
code-walker would make the distinction irrelevant, but I haven't seen
this mythical beast.
Secondly, going back to my original question: are there any
well-documented Lisp-based web frameworks? If not, then perhaps UCW has
some "hidden" features that would make it worth switching to? Again, I
am currently using a well-documented, Scheme-based,
continuations-wielding framework.
Thirdly, it seems like everytime someone tries to get c.l.l to look a
bit outside, or talk about Lisp vs something else, the discussion
becomes poisoned. Guys, is this really necessary?
········@yahoo.com writes:
> Thirdly, it seems like everytime someone tries to get c.l.l to look a
> bit outside, or talk about Lisp vs something else, the discussion
> becomes poisoned. Guys, is this really necessary?
That reminds me of this joke:
"Laurie was offended by the word 'puke', but to me, that's what her
dinner tasted like."
Zach
········@yahoo.com writes:
> OK. Forget what people might or might not do, and let's have a
> technical discussion. What am I missing by using Scheme (and Scheme web
> frameworks in particular) instead of Lisp?
Common Lisp? I find myself greenspuning quite an amount when I try to
write Scheme. On the contrary, when writting Common Lisp program, the
only time I miss a feature from Scheme is when I want to implement a
web site with continuations, and this is already implemented in CL in
ARNESI, so no inverse-greenspuning here.
> I could easily point out what people miss by using Lisp instead of
> Scheme: continuations. Yes, theoretically a CPS-transforming
> code-walker would make the distinction irrelevant, but I haven't seen
> this mythical beast.
It is implemented in ARNESI, used by UCW.
> Secondly, going back to my original question: are there any
> well-documented Lisp-based web frameworks? If not, then perhaps UCW has
> some "hidden" features that would make it worth switching to? Again, I
> am currently using a well-documented, Scheme-based,
> continuations-wielding framework.
Well I agree that it could be nice to have a _reference_ _manual_ for
UCW. But it probably doesn't matter, because to become proficient
with it, you'd probably need to know its sources in and out anyways.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
Pascal, thanks for pointing me to ARNESI, I'll take a look at that.
I'm curious, what are you greenspunning about in Scheme? The large
standard library of CL?
-- Dan
········@yahoo.com writes:
> Pascal, thanks for pointing me to ARNESI, I'll take a look at that.
>
> I'm curious, what are you greenspunning about in Scheme? The large
> standard library of CL?
Yes, somewhat, and basic stuff like first and rest when all I have is
a R4RS for example (lispme on Palm, PseudoScheme on CL, etc).
Perhaps it's just me being a CL programmer, not a Scheme programmer...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
True, a lot of stuff is not built-in. The large number of SRFI's
alleviates the problem to a great extent though (e.g. first and second
are in srfi-1). You can create your own standard prelude and include it
(or copy/paste it) in all your programs.
I thought that greenspunning was about re-inventing high-level concepts
(like GC), though. Re-inventing the wheel, but making it a square.
-- Dan
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44rsroF3kqeeU1@individual.net>
········@yahoo.com wrote:
> True, a lot of stuff is not built-in. The large number of SRFI's
> alleviates the problem to a great extent though (e.g. first and second
> are in srfi-1). You can create your own standard prelude and include it
> (or copy/paste it) in all your programs.
Apparently, you have already made up your mind. You criticize UCW for
not having good documentation, but you defend Scheme in spite of having
a much smaller standard library. This smells a lot like having made up
your mind.
From http://public.research.att.com/~bs/bs_faq.html#compare :
"I also worry about a phenomenon I have repeatedly observed in honest
attempts at language comparisons. The authors try hard to be impartial,
but are hopelessly biased by focusing on a single application, a single
style of programming, or a single culture among programmers. Worse, when
one language is significantly better known than others, a subtle shift
in perspective occurs: Flaws in the well-known language are deemed minor
and simple workarounds are presented, whereas similar flaws in other
languages are deemed fundamental. Often, the workarounds commonly used
in the less-well-known languages are simply unknown to the people doing
the comparison or deemed unsatisfactory because they would be unworkable
in the more familiar language."
Doesn't match completely, but you get the idea.
If posting your questions is about becoming more self-confident about
your decision, then you should realize that this won't help you. Many
people around here have chosen to use Common Lisp, at least for some
projects, for good reasons. Many people in comp.lang.scheme have chosen
Scheme for other reasons. Some of them will probably disagree with the
others. Eventually, you will have to make your own decision.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
As I said, I just want to know what I am missing by not using UCW. I am
not attacking or defending anything. I don't want to persuade anyone of
anything. I am not selling anything. I don't want to piss anyone off.
Perhaps I should clarify my original question: what are some things
that make UCW stand out? Some features not likely to be found
elsewhere? Some innovations?
Instead of anyone addressing my question, lots of people started
questioning my motives for asking the question. Some folks defended me,
and I thank them.
I am not interested in a general Lisp vs Scheme comparison. Yes, I am
stuck in my own little niche and my judgement will be biased -- so
what? I am not trying to change my life, just to choose a webapp
framework.
As far as Pascal's comment about defending Scheme: I wasn't defending
Scheme's size. I was just offering advice on how to alleviate it (a
standard prelude). Whether that piece of advice is useful or wanted is
a different topic. But to Pascal's eyes, a two-sentence paragraph
becomes material for psychoanalysis. He can smell that I have made up
my mind. He further deduces that I am posting on c.l.l just to aid my
weak self-confidence. Wow!
And suppose I did make up my mind and prefer Scheme over Lisp: would
that upset anyone? I would still want to know about cool features being
invented in UCW. Perhaps I want to port them to my favorite Scheme
framework -- would that be bad for Lisp? Will you not talk about a
piece of Lisp code (UCW) with someone who prefers a different flavor of
Lisp?
-- Dan
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44s0v1F3lji6U1@individual.net>
········@yahoo.com wrote:
> Perhaps I should clarify my original question: what are some things
> that make UCW stand out? Some features not likely to be found
> elsewhere? Some innovations?
See http://common-lisp.net/project/ucw/features.html
If you want to know more details, you should probably ask questions in
the UCW mailing list.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
········@yahoo.com writes:
> As far as Pascal's comment about defending Scheme: I wasn't defending
> Scheme's size. I was just offering advice on how to alleviate it (a
> standard prelude). Whether that piece of advice is useful or wanted is
> a different topic. But to Pascal's eyes, a two-sentence paragraph
> becomes material for psychoanalysis. He can smell that I have made up
> my mind. He further deduces that I am posting on c.l.l just to aid my
> weak self-confidence. Wow!
Beware, there are two Pascals in c.l.lisp :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
"Joe Marshall" <··········@gmail.com> wrote in message ····························@o13g2000cwo.googlegroups.com...
>
> Pascal Bourguignon wrote:
>>
>> Beware, there are two Pascals in c.l.lisp :-)
>>
>
> This is a low-pressure group.
Agggggh! My eyes, my eyes, I can't see! 8-)
--
Geoff
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44s1p6F3n3q5U1@individual.net>
Pascal Bourguignon wrote:
> ········@yahoo.com writes:
>
>>As far as Pascal's comment about defending Scheme: I wasn't defending
>>Scheme's size. I was just offering advice on how to alleviate it (a
>>standard prelude). Whether that piece of advice is useful or wanted is
>>a different topic. But to Pascal's eyes, a two-sentence paragraph
>>becomes material for psychoanalysis. He can smell that I have made up
>>my mind. He further deduces that I am posting on c.l.l just to aid my
>>weak self-confidence. Wow!
>
> Beware, there are two Pascals in c.l.lisp :-)
At least. ;)
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Alexander Schmolck
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <yfs1wyff2ix.fsf@oc.ex.ac.uk>
········@yahoo.com writes:
> OK. Forget what people might or might not do, and let's have a
> technical discussion. What am I missing by using Scheme (and Scheme web
> frameworks in particular) instead of Lisp?
From the top of my head:
- a powerful interactive environment (docstrings, slime, images, hot-patching
etc.)
- the common lisp condition system
- a sane way to pass and receive multiple arguments to and from proedures
(keyword arguments and multiple-value-*)
- a powerful and efficient multiple-dispatch object system
- a programmable reader
- a package system
- arrays, hash-tables and structures
- the sequence dictionary
- the ability to name your lists "list"
- declarations and compiler-macros for more efficient code
- the ability to switch between implementations, even if your code does
something non-trivial
- commercial vendors and commercial support (there is Cadence Research with
Chez scheme, but that doesn't seem directly comparable, to say Franz and
Allegro Common Lisp)
You can have some subset of the above using one specific scheme implementation
+ srfis (albeit what you get from srfis is often more limited in funcitonality
due to gcd-itis; e.g. the functions in srfi-1 are less featureful than their
CL counterparts). Even with PLT, which is presumably the most featureful
scheme implementation you won't get all of the above. Of course you do get
some other things instead, depends what you care about most. Personally I
wouldn't want to use a language for a real project that doesn't give you
something roughly equivalent to 1-3.
If you really want to know, sitting down and spending some time with
sbcl+emacs+slime and e.g. practical common lisp or some UCW tutorial beats
asking vague questions along the lines "is there really any point in using
lisp/UCW?" on comp.lang.lisp.
> I could easily point out what people miss by using Lisp instead of
> Scheme: continuations.
Well done.
> Yes, theoretically a CPS-transforming code-walker would make the distinction
> irrelevant, but I haven't seen this mythical beast.
Only because you apparently didn't bother to google "Continuations in Common
Lisp".
> Secondly, going back to my original question: are there any
> well-documented Lisp-based web frameworks?
I don't know, never used any -- having said that, on first sight I don't see a
problem with UCW's documentation. The website is well designed, there is a
feature overview, as well as several tutorials (including a video) and an
apparently comprehensive java-doc like documentation with the additional
benefit of linking to the source code. Did you actually try using that
existing documentation to accomplish something and then got stuck?
> If not, then perhaps UCW has some "hidden" features that would make it worth
> switching to? Again, I am currently using a well-documented, Scheme-based,
> continuations-wielding framework.
Probably not -- if you're happy with what you're using and prefer scheme to CL
why switch? It seems unlikely to me that UCW has some carefully "hidden"
killer features (and if it did, why would anyone tell you?).
> Thirdly, it seems like everytime someone tries to get c.l.l to look a
> bit outside, or talk about Lisp vs something else, the discussion
> becomes poisoned. Guys, is this really necessary?
Maybe you should just learn how to ask intelligent questions on usenet.
'as
Thanks for the very detailed reply, Alexander, although I don't
appreciate some of the overtones.
> Personally I
> wouldn't want to use a language for a real project that doesn't give you
> something roughly equivalent to 1-3.
1-3 in your list of features?
By the way, this is what I wanted to know: what people find the most
compelling reasons to use Common Lisp. Not a list of 1001 differences.
> If you really want to know, sitting down and spending some time with
> sbcl+emacs+slime and e.g. practical common lisp or some UCW tutorial beats
> asking vague questions along the lines "is there really any point in using
> lisp/UCW?" on comp.lang.lisp.
I will pass the emacs+slime+sbcl part up, given the people who hang out
in this group. I don't want to be called a troll again.
I will just say that, in the first stage, I intented to spend on UCW no
more than the time required to go on IRC and chat about it. It's my
time budget and I can spend it however I see fit. If UCW did turn out
interesting, then perhaps I would have implemented your plan in stage
two.
> Only because you apparently didn't bother to google "Continuations in Common Lisp".
I did. About a month ago. Of course, I didn't stumble upon that magic
search string, I just used "continuations" "lisp".
> benefit of linking to the source code. Did you actually try using that
> existing documentation to accomplish something and then got stuck?
You are the first one to say that UCW documentation is sufficient. I
was hoping for a reference manual.
> Probably not -- if you're happy with what you're using and prefer scheme to CL
> why switch? It seems unlikely to me that UCW has some carefully "hidden"
> killer features (and if it did, why would anyone tell you?).
I obviously didn't mean my question that way, but thanks for distorting
it. Some features grow on you and turn out to be real productivity
boosters. They are not necessarily advertised on the overview page.
> Maybe you should just learn how to ask intelligent questions on usenet.
Nice.
-- Dan
········@yahoo.com wrote:
>
> > If you really want to know, sitting down and spending some time with
> > sbcl+emacs+slime and e.g. practical common lisp or some UCW tutorial beats
> > asking vague questions along the lines "is there really any point in using
> > lisp/UCW?" on comp.lang.lisp.
>
> I will pass the emacs+slime+sbcl part up, given the people who hang out
> in this group. I don't want to be called a troll again.
>
> I will just say that, in the first stage, I intented to spend on UCW no
> more than the time required to go on IRC and chat about it. It's my
> time budget and I can spend it however I see fit. If UCW did turn out
> interesting, then perhaps I would have implemented your plan in stage
> two.
Well, then a better strategy (for you, given your tight time
constraints) is probably to wait a year, maybe scan the situation
rather quickly every half-year. Another thing is to visit a Lisp
meeting in your area, which will provide whatever non-verbal cues make
conversation more congenial, and there is more bandwidth for the
detailed interaction you might want.
This of course assumes you're still interested in using Lisp despite
whatever unpleasant experiences you #lisp guys seemed to mutually have.
(In fact, the MIT management school did study on Common Lisp
discussions: "Knee-jerk Anti-LOOPism and other E-mail Phenomena". It
incidentally turns out one of the Lispers invented the smiley, clearly
another first for Lisp, and probably demonstrates that Lisp was the
first computer language tradition to actually make people smile. Of
course, I'm sure the frowny face was invented after a Naggum-era
comp.lang.lisp flame.)
http://ccs.mit.edu/papers/CCSWP150.html
Mailing lists probably tend to be a much better source for detailed
info than general forums such as this, such as that of UnCommon Web...
odd as it is to say, Common Lisp appears to be in "early adopter mode".
(Yes, I know that's ironic; Lisp probably has a business cycle of
alternating golden/dark ages or something.) So getting good information
might require a bit of targetting.
http://software.ericsink.com/Act_Your_Age.html
Tayssir
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44shtdF3ochhU1@individual.net>
········@yahoo.com wrote:
> By the way, this is what I wanted to know: what people find the most
> compelling reasons to use Common Lisp. Not a list of 1001 differences.
My personal opinion:
- The basic design decisions are better than in Scheme. Especially,
Lisp-2 and full support for s-expressions (any object can be part of
your program source, and the combination of symbols and the package system).
- The Common Lisp Object System is the most complete object system that
I am aware of. Swindle, which is part of PLT Scheme, comes close, but
misses a few features (full support for user-defined method
combinations, user-defined argument precedence order and a specified
metaobject protocol). The protocol for slot accesses seems to be better
in Swindle, though. (I am not 100% convinced that it's the optimal
solution, though.)
- Finally, Common Lisp certainly has its flaws. (Although it's probably
impossible to find two or more Lispers who will agree on a particular
set of what they consider flaws. ;) However, I am not aware of any
language that allows you to work around those flaws as seemlessly, and
still make your solution look as clean as if the flaws didn't exist in
the first place. Again, the package system and its ways to shadow
symbols and replace them with new ones, and user-programmable reader
macros are extremely handy in this regard. I am not aware of any Scheme
system that provides reader macros, for example. (Maybe MIT Scheme...)
Just my 0.02�
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> ········@yahoo.com wrote:
>
> > By the way, this is what I wanted to know: what people find the
> > most compelling reasons to use Common Lisp. Not a list of 1001
> > differences.
>
> My personal opinion:
>
> - The basic design decisions are better than in Scheme. Especially,
> Lisp-2 and full support for s-expressions (any object can be part
> of your program source, and the combination of symbols and the
> package system).
(2x"Heh...")
> - The Common Lisp Object System is the most complete object system
> that I am aware of. Swindle, which is part of PLT Scheme, comes
> close, but misses a few features (full support for user-defined
> method combinations, user-defined argument precedence order and a
> specified metaobject protocol).
Um, that requires some corrections/clarifications. There is support
for user-defined method combinations -- but it is a functional
interface rather than constructing a body from little pieces of code
(and I consider this a feature). For example, this is the `or'
combination:
(define* generic-or-combination
(make-generic-combination
:init #f
:control (lambda (loop val this tail) (or (this) (loop #f tail)))))
I don't remember any user-defined argument precedence order in CLOS,
but Swindle does provide the usual MOP generics, like
`compute-methods', `compute-method-more-specific?', and
`compute-apply-generic'. The MOP is as specified as it needs to be,
perhaps not as well documented, but it's basically the same as the one
in Tiny-CLOS, with a few non-generics that I turned into generics.
> The protocol for slot accesses seems to be better in Swindle,
> though. (I am not 100% convinced that it's the optimal solution,
> though.)
The protocol for accessing slots is, I think, much slower than CLOS,
and (IIRC) is not better than CLOS. There is some improvement in the
code that avoids a certain grounding case, but there is also an
assumption that the meta-hierarchy does not use multiple inheritance.
> - Finally, Common Lisp certainly has its flaws. (Although it's
> probably impossible to find two or more Lispers who will agree on
> a particular set of what they consider flaws. ;) However, I am not
> aware of any language that allows you to work around those flaws
> as seemlessly, and still make your solution look as clean as if
> the flaws didn't exist in the first place. Again, the package
> system and its ways to shadow symbols and replace them with new
> ones,
A good module system should allow you to do that in a cleaner way.
Here is an example for using a specific module in PLT:
| > (require (lib "lazy.ss" "CSU660"))
| > (define ones (cons 1 ones))
| > ones
| #0=(1 . #0#)
| > (define fibs (list* 1 1 (map + fibs (cdr fibs))))
| > (take 10 fibs)
| (1 1 2 3 5 8 13 21 34 55)
> and user-programmable reader macros are extremely handy in
> this regard. I am not aware of any Scheme system that provides
> reader macros, for example. (Maybe MIT Scheme...)
This is one of the points that I (implicitly) said *are* included in
PLT.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44snrlF3qud2U1@individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>········@yahoo.com wrote:
>>
>>>By the way, this is what I wanted to know: what people find the
>>>most compelling reasons to use Common Lisp. Not a list of 1001
>>>differences.
>>
>>My personal opinion:
>>
>>- The basic design decisions are better than in Scheme. Especially,
>> Lisp-2 and full support for s-expressions (any object can be part
>> of your program source, and the combination of symbols and the
>> package system).
>
> (2x"Heh...")
;)
>>- The Common Lisp Object System is the most complete object system
>> that I am aware of. Swindle, which is part of PLT Scheme, comes
>> close, but misses a few features (full support for user-defined
>> method combinations, user-defined argument precedence order and a
>> specified metaobject protocol).
>
> Um, that requires some corrections/clarifications. There is support
> for user-defined method combinations -- but it is a functional
> interface rather than constructing a body from little pieces of code
> (and I consider this a feature). For example, this is the `or'
> combination:
>
> (define* generic-or-combination
> (make-generic-combination
> :init #f
> :control (lambda (loop val this tail) (or (this) (loop #f tail)))))
Hmmm...
(define-method-combination or ()
((methods (or)))
`(or ,@(loop for method in methods
collect `(call-method ,method))))
> I don't remember any user-defined argument precedence order in CLOS,
> but Swindle does provide the usual MOP generics, like
> `compute-methods', `compute-method-more-specific?', and
> `compute-apply-generic'.
(defgeneric do-something (a b c)
(:argument-precedence-order c b a))
...means that the c argument is more important in determining the list
of applicable methods than the b and a arguments.
Typical use case:
(defgeneric (setf do-it) (new-value a b c)
(:argument-precedence-order a b c new-value))
...because the new-value must be passed as the first parameter, but has
least precedence.
> The MOP is as specified as it needs to be,
> perhaps not as well documented, but it's basically the same as the one
> in Tiny-CLOS, with a few non-generics that I turned into generics.
Tiny CLOS lacks a specification what kinds of optimizations an
implementation is allowed to perform and what behavior a user can rely
on. I think that's an important element of the CLOS MOP specification.
>> The protocol for slot accesses seems to be better in Swindle,
>> though. (I am not 100% convinced that it's the optimal solution,
>> though.)
>
> The protocol for accessing slots is, I think, much slower than CLOS,
> and (IIRC) is not better than CLOS. There is some improvement in the
> code that avoids a certain grounding case, but there is also an
> assumption that the meta-hierarchy does not use multiple inheritance.
Hm, interesting. Gregor Kiczales has announced TinyCLOS (back in the
good old days ;) with the claim that slot access can be implemented more
efficiently than using the CLOS MOP specification. Given what has
reported what a typical CLOS implementation has to do, I now have
started to tend to believe this. See
http://www.sbcl.org/sbcl-internals/Slot_002dValue.html#Slot_002dValue
The standard case (when a class is a direct instance of standard-class
and/or the slots are direct instances of
standard-effective-slot-definition) are indeed probably more efficient
than in the TinyCLOS / Swindle implementation. However, the protocol
seems to be nicer in that regard for user-defined extensions /
user-defined slot kinds.
>>- Finally, Common Lisp certainly has its flaws. (Although it's
>> probably impossible to find two or more Lispers who will agree on
>> a particular set of what they consider flaws. ;) However, I am not
>> aware of any language that allows you to work around those flaws
>> as seemlessly, and still make your solution look as clean as if
>> the flaws didn't exist in the first place. Again, the package
>> system and its ways to shadow symbols and replace them with new
>> ones,
>
> A good module system should allow you to do that in a cleaner way.
> Here is an example for using a specific module in PLT:
>
> | > (require (lib "lazy.ss" "CSU660"))
> | > (define ones (cons 1 ones))
> | > ones
> | #0=(1 . #0#)
> | > (define fibs (list* 1 1 (map + fibs (cdr fibs))))
> | > (take 10 fibs)
> | (1 1 2 3 5 8 13 21 34 55)
"Clean" is a personal opinion (ha! ;). IIUC, you have to override apply
>> and user-programmable reader macros are extremely handy in
>> this regard. I am not aware of any Scheme system that provides
>> reader macros, for example. (Maybe MIT Scheme...)
>
> This is one of the points that I (implicitly) said *are* included in
> PLT.
OK
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
> > Um, that requires some corrections/clarifications. There is
> > support for user-defined method combinations -- but it is a
> > functional interface rather than constructing a body from little
> > pieces of code (and I consider this a feature). For example, this
> > is the `or' combination:
> > (define* generic-or-combination
> > (make-generic-combination
> > :init #f
> > :control (lambda (loop val this tail) (or (this) (loop #f tail)))))
>
> Hmmm...
>
> (define-method-combination or ()
> ((methods (or)))
> `(or ,@(loop for method in methods
> collect `(call-method ,method))))
I don't get what you're trying to say. So I'll reply to a few
interpretations that I see:
* "That's possible in CL" -- I never said it wasn't, only that I'm
using a function where CL uses a form that is assembled into running
code elsewhere. (And that I consider the form spec a misfeature.)
* "The CL specification is better (elegant, faster, whatever)" -- OK,
that's subjective anyway.
* "You didn't implement method-group-specifier" -- Right, but most of
the functionality is there...
> > I don't remember any user-defined argument precedence order in CLOS,
> > but Swindle does provide the usual MOP generics, like
> > `compute-methods', `compute-method-more-specific?', and
> > `compute-apply-generic'.
>
> (defgeneric do-something (a b c)
> (:argument-precedence-order c b a))
>
> ...means that the c argument is more important in determining the
> list of applicable methods than the b and a arguments.
Ah, I forgot about that. (It's been a few years...) Given that there
is a generic that sorts the methods, it doesn't look like it would
take much to implement, but my hacking plate is full.
> > The MOP is as specified as it needs to be, perhaps not as well
> > documented, but it's basically the same as the one in Tiny-CLOS,
> > with a few non-generics that I turned into generics.
>
> Tiny CLOS lacks a specification what kinds of optimizations an
> implementation is allowed to perform and what behavior a user can
> rely on. I think that's an important element of the CLOS MOP
> specification.
Once I made it more realistic by adding caches in various places, I
did need to specify certain assumptions like functionality of
meta-generics etc. In any case, your original claim was that Swindle
lacks "a specified metaobject protocol" not a specification of
possible optimizations.
> >> The protocol for slot accesses seems to be better in Swindle,
> >> though. (I am not 100% convinced that it's the optimal solution,
> >> though.)
> > The protocol for accessing slots is, I think, much slower than
> > CLOS, and (IIRC) is not better than CLOS. There is some
> > improvement in the code that avoids a certain grounding case, but
> > there is also an assumption that the meta-hierarchy does not use
> > multiple inheritance.
>
> Hm, interesting. Gregor Kiczales has announced TinyCLOS (back in the
> good old days ;) with the claim that slot access can be implemented
> more efficiently than using the CLOS MOP specification.
Yes, it's at the top of the file:
;;; While the MOP is simple, it is essentially equal in power to
;;; both MOPs in AMOP. This implementation is not at all optimized,
;;; but the MOP is designed so that it can be optimized. In fact,
;;; this MOP allows better optimization of slot access extenstions
;;; than those in AMOP.
> Given what has reported what a typical CLOS implementation has to
> do, I now have started to tend to believe this. See
> http://www.sbcl.org/sbcl-internals/Slot_002dValue.html#Slot_002dValue
> [...]
You mean that the CLOS case is harder because it is forced to use
generics? -- I did consider that, but given that I'm not using some
strong compiler and that I'm not doing any tricks to compile generics
given their methods, I thought that would make things too slow to be
realistic. (Actually, PLT was recently extended with a native code
JIT, it would be interesting to see if it leads to better performace
boost in Swindle (due to caching) than it is in plain Scheme code.)
> > A good module system should allow you to do that in a cleaner way.
> > Here is an example for using a specific module in PLT:
> > | > (require (lib "lazy.ss" "CSU660"))
> > | > (define ones (cons 1 ones))
> > | > ones
> > | #0=(1 . #0#)
> > | > (define fibs (list* 1 1 (map + fibs (cdr fibs))))
> > | > (take 10 fibs)
> > | (1 1 2 3 5 8 13 21 34 55)
>
> "Clean" is a personal opinion (ha! ;). IIUC, you have to override
> apply
Right -- but the module system should allow you to write a new apply
that itself uses the built-in one.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
PLT is much slower than decent Lisps. That's its biggest problem. On
Linux at least, PLT's ancient wx binding looks terrible. The licensing
of produced executables is moot to me. Lastly, I had a hard time
producing a stand-alone executable with PLT. When I asked it to do so,
it coughed up a shell script with my whole Scheme code directly
embedded in it as a string (the script would call a scheme interpreter,
giving this string as an argument - isn't that gross?)
·········@gmail.com writes:
> PLT is much slower than decent Lisps. That's its biggest problem.
Yes, that's a problem. It's improving though.
> On Linux at least, PLT's ancient wx binding looks terrible.
That's two misconceptions -- (1) the wx part is much more than just
`bindings' (bindings are easy to generate and there are at least two
sets of gtk bindings). (2) It's true that MrEd was based on an old wx
version, in fact it was a major contributor at the time -- but it has
forked off and is now an independent project.
> The licensing of produced executables is moot to me.
PLT is all LGPL, what issues could there be with produced executables?
> Lastly, I had a hard time producing a stand-alone executable with
> PLT. When I asked it to do so, it coughed up a shell script with my
> whole Scheme code directly embedded in it as a string
| winooski:~/tmp eli> cat > z.ss
| (module z mzscheme (printf "foo\n"))
| winooski:~/tmp eli> mzc --exe z z.ss
| mzc version 301.5, Copyright (c) 2004-2006 PLT Scheme Inc.
| [output to "z"]
| winooski:~/tmp eli> file z
| z: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
| GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
| winooski:~/tmp eli> ./z
| foo
> (the script would call a scheme interpreter, giving this string as
> an argument - isn't that gross?)
Whatever you did was not right.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
·········@gmail.com wrote:
> I had a hard time
> producing a stand-alone executable with PLT. When I asked it to do so,
> it coughed up a shell script with my whole Scheme code directly
> embedded in it as a string (the script would call a scheme interpreter,
> giving this string as an argument - isn't that gross?)
Yeah, how lame is *that*....
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44tptsF3tk81U1@individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Eli Barzilay wrote:
>>
>>>Um, that requires some corrections/clarifications. There is
>>>support for user-defined method combinations -- but it is a
>>>functional interface rather than constructing a body from little
>>>pieces of code (and I consider this a feature). For example, this
>>>is the `or' combination:
>>> (define* generic-or-combination
>>> (make-generic-combination
>>> :init #f
>>> :control (lambda (loop val this tail) (or (this) (loop #f tail)))))
>>
>>Hmmm...
>>
>>(define-method-combination or ()
>> ((methods (or)))
>> `(or ,@(loop for method in methods
>> collect `(call-method ,method))))
>
> I don't get what you're trying to say.
I was just thinking out loud. I wanted to claim that the
macro-expansion-style method combinations in CL is easier to understand,
but then realized that this is probably a matter of getting used to. I
didn't understand the various kinds of constructing method combinations
in Swindle, but I also didn't seriously try them out, so I can't really
tell the difference, to be honest.
>>>I don't remember any user-defined argument precedence order in CLOS,
>>>but Swindle does provide the usual MOP generics, like
>>>`compute-methods', `compute-method-more-specific?', and
>>>`compute-apply-generic'.
>>
>>(defgeneric do-something (a b c)
>> (:argument-precedence-order c b a))
>>
>>...means that the c argument is more important in determining the
>>list of applicable methods than the b and a arguments.
>
> Ah, I forgot about that. (It's been a few years...) Given that there
> is a generic that sorts the methods, it doesn't look like it would
> take much to implement, but my hacking plate is full.
I think this isn't in TinyCLOS because Scheme neither has setf-style
writers nor keyword arguments (although it has rest arguments), and
foremostly because it was supposed to be used for pedagogical purposes.
I also think that CLOS has this right: It's not something that you need
often, but if you need it, you don't want to start hacking the MOP for it.
>>>The MOP is as specified as it needs to be, perhaps not as well
>>>documented, but it's basically the same as the one in Tiny-CLOS,
>>>with a few non-generics that I turned into generics.
>>
>>Tiny CLOS lacks a specification what kinds of optimizations an
>>implementation is allowed to perform and what behavior a user can
>>rely on. I think that's an important element of the CLOS MOP
>>specification.
>
> Once I made it more realistic by adding caches in various places, I
> did need to specify certain assumptions like functionality of
> meta-generics etc. In any case, your original claim was that Swindle
> lacks "a specified metaobject protocol" not a specification of
> possible optimizations.
I think that's an integral part of such a specification. This is
explained in the AMOP book in more detail. TinyCLOS and Swindle "only"
explains which functions call which other functions, but it doesn't
state anything about guarantees whether they always call each other,
whether overriding methods have to return the original values or not,
etc. If you don't know about these issues, writing your own metaclasses
probably requires you to inspect the source code of TinyCLOS to see
what's really going on. Again, that's sufficient for pedagogical
purposes, but not for production code IMHO.
>>Given what has reported what a typical CLOS implementation has to
>>do, I now have started to tend to believe this. See
>>http://www.sbcl.org/sbcl-internals/Slot_002dValue.html#Slot_002dValue
>>[...]
>
> You mean that the CLOS case is harder because it is forced to use
> generics? -- I did consider that, but given that I'm not using some
> strong compiler and that I'm not doing any tricks to compile generics
> given their methods, I thought that would make things too slow to be
> realistic. (Actually, PLT was recently extended with a native code
> JIT, it would be interesting to see if it leads to better performace
> boost in Swindle (due to caching) than it is in plain Scheme code.)
It's probably hard to measure this anyway. You either need an
alternative and well-optimized CLOS-style implementation of slot access
in PLT Scheme, or a TinyCLOS-style implementation in CLOS, and then
measure the effects the alternative implementations have in large
programs. That's a lot of work...
>>>A good module system should allow you to do that in a cleaner way.
>>>Here is an example for using a specific module in PLT:
>>>| > (require (lib "lazy.ss" "CSU660"))
>>>| > (define ones (cons 1 ones))
>>>| > ones
>>>| #0=(1 . #0#)
>>>| > (define fibs (list* 1 1 (map + fibs (cdr fibs))))
>>>| > (take 10 fibs)
>>>| (1 1 2 3 5 8 13 21 34 55)
>>
>>"Clean" is a personal opinion (ha! ;). IIUC, you have to override
>>apply
>
> Right -- but the module system should allow you to write a new apply
> that itself uses the built-in one.
Sorry, I wanted to delete my remark about apply, but obviously forgot to
do so. But as a sidenote, it's interesting that PLT Scheme has added a
kind of prototype-based object-oriented system with their module system
through the backdoor, together with a metaobject protocol for function
application. This seems to me quite heavy-weight for the simple task of
changing the semantics of built-in operators.
I also wonder what the implications of this approach are: In CLOS /
TinyCLOS you have the approach that compute-discriminating-function /
compute-apply-generic can produce the actual, and optimized, version of
what it means to call a generic function. Compared to this, the approach
for the PLT Scheme module system looks quite naive...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
>
> I was just thinking out loud. I wanted to claim that the
> macro-expansion-style method combinations in CL is easier to
> understand, but then realized that this is probably a matter of
> getting used to. I didn't understand the various kinds of
> constructing method combinations in Swindle, but I also didn't
> seriously try them out, so I can't really tell the difference, to be
> honest.
In that case my first point holds: I think that using a function is
clearer since its binding structure is clear, and since it does not
require any extra lingustic constructs I see
(lambda (loop val this tail) (or (this) (loop #f tail)))
and I can easily tell what it does, and given the interface, I can see
how the method combination mechanism uses it. But when I look at:
((methods (or)))
`(or ,@(loop for method in methods
collect `(call-method ,method))))
I need to know how `methods' is bound, I need to know what
`call-method' is, I need to know that it's an s-expression that I'm
supposed to construct, and I need to know the syntax of that first
part. The only advantage that I see for the CL form is that it will
not require an extra function call for each method -- but given the
already big overhead of using generics, this looks pointless.
(And now take all that and qualify it with a big YMMV -- perhaps you
were able to write all that without looking at the manual.)
> > Ah, I forgot about that. (It's been a few years...) Given that
> > there is a generic that sorts the methods, it doesn't look like it
> > would take much to implement, but my hacking plate is full.
>
> I think this isn't in TinyCLOS because Scheme neither has setf-style
> writers nor keyword arguments (although it has rest arguments),
(Swindle does have both.)
> and foremostly because it was supposed to be used for pedagogical
> purposes. [...]
This is a completely bogus point. Scheme did not start as an exercise
in pedagogy, and implementations are not actively used today for
teaching. It has been a by-product of cleaner semantics, and
SICP/6.001 made it popular for teaching. I don't think that I ever
saw a scheme-implementation make any design decision due to
pedagogical reason -- including DrScheme which has extensive support
for students yet none of that made any difference in the core
language. (I thought that you were aware of all that.)
> > Once I made it more realistic by adding caches in various places,
> > I did need to specify certain assumptions like functionality of
> > meta-generics etc. In any case, your original claim was that
> > Swindle lacks "a specified metaobject protocol" not a
> > specification of possible optimizations.
>
> I think that's an integral part of such a specification. This is
> explained in the AMOP book in more detail. TinyCLOS and Swindle
> "only" explains which functions call which other functions, but it
> doesn't state anything about guarantees whether they always call
> each other, whether overriding methods have to return the original
> values or not, etc.
How can you confuse CLOS (a spec), Tiny-CLOS (a demonstrational tool),
and Swindle (an implementation)? If I had intentions to make Swindle
into something that is implemented by other people, I would definitely
need to document this, and I certainly need to document it for users
who may want to use the MOP. If there are facts that are not
documented, it is only due to the lack of manpower.
> If you don't know about these issues, writing your own metaclasses
> probably requires you to inspect the source code of TinyCLOS to see
> what's really going on.
>
> Again, that's sufficient for pedagogical purposes, but not for
> production code IMHO.
...and here we go again. FWIW, Swindle was used in one course which
did not discuss its implementation or the MOP (or *any* MOP). There
was no MOP design decision whatsoever that was made for any form of
teaching. None. Take the MOP out, and that course would change one
bit.
> Sorry, I wanted to delete my remark about apply, but obviously
> forgot to do so. But as a sidenote, it's interesting that PLT Scheme
> has added a kind of prototype-based object-oriented system with
> their module system through the backdoor, together with a metaobject
> protocol for function application. This seems to me quite
> heavy-weight for the simple task of changing the semantics of
> built-in operators.
You lost me here. The module system has no relation to prototype
based OOs, and no meta objects of any form. The module system is a
syntactic tool (resolving and linking names, separate compilation
phases, etc). When I write a module that redefines function
application, I'm only translating code -- for example, if I write
(module foo mzscheme
(provide (all-from-except mzscheme #%app)
(rename foo-app #%app))
(define-syntax foo-app
(syntax-rules (+)
[(_ x + y) (+ x y)]
[(_ x . xs) (x . xs)])))
and use it like this:
(1 + 2)
then this form is expanded to
(#%app 1 + 2)
and this `#%app' is my own `foo-app' syntax above, which means that it
gets expanded to
(#%app + 1 2)
and this is the built-in `#%app' that is implicit in that `(+ x y)'
pattern. No objects, and no protocol beyond macro expansion.
> I also wonder what the implications of this approach are: In CLOS /
> TinyCLOS you have the approach that compute-discriminating-function
> / compute-apply-generic can produce the actual, and optimized,
> version of what it means to call a generic function. Compared to
> this, the approach for the PLT Scheme module system looks quite
> naive...
It's not naive -- it's unrelated. You can use both mechanisms to
redefine `application' but the resemblence ends there. (BTW, the
macro is lighter in that it does not lead to additional run-time costs
like a MOP.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
> Pascal Costanza <··@p-cos.net> writes:
> >
> > I think this isn't in TinyCLOS because Scheme neither has setf-style
> > writers nor keyword arguments (although it has rest arguments),
Eli Barzilay wrote:
> (Swindle does have both.)
So does Common Larceny (the port of Larceny that runs on .NET). I
ported the guts of Swindle to Larceny and used the Swindle MOP to hook
together the Larceny and the .NET type systems (I believe it is
somewhat similar to Edi Weitz's RDNZL).
Incidentally, the MOP in Swindle may not be all that well documented,
but it is pretty straightforward. Anyone with experience in the CLOS
MOP should have no problem finding their way around.
From: Edi Weitz
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <uoe1h7n9a.fsf@agharta.de>
On 8 Feb 2006 09:42:37 -0800, "Joe Marshall" <··········@gmail.com> wrote:
> So does Common Larceny (the port of Larceny that runs on .NET). I
> ported the guts of Swindle to Larceny and used the Swindle MOP to
> hook together the Larceny and the .NET type systems (I believe it is
> somewhat similar to Edi Weitz's RDNZL).
It's probably similar to the RDNZL version I demoed in Amsterdam in
2004. For the current release I've thrown out the MOP stuff in favor
of a smaller code base and better support for application delivery.
If someone's interested in the old code I can dig it out from my CVS
repository. It was good enough to crash reproducibly during the
demo... :)
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44ur0nF3li0nU1@individual.net>
Joe Marshall wrote:
>>Pascal Costanza <··@p-cos.net> writes:
>>
>>>I think this isn't in TinyCLOS because Scheme neither has setf-style
>>>writers nor keyword arguments (although it has rest arguments),
>
> Eli Barzilay wrote:
>
>>(Swindle does have both.)
>
> So does Common Larceny (the port of Larceny that runs on .NET). I
> ported the guts of Swindle to Larceny and used the Swindle MOP to hook
> together the Larceny and the .NET type systems (I believe it is
> somewhat similar to Edi Weitz's RDNZL).
Hm, I have just checked the Swindle documentation. I see that setf-style
assignments expand to function calls where the new value is the last
argument, not the first one as in Common Lisp. I would expect this to
pose problems with rest lists and especially with keyword arguments,
doesn't it?
> Incidentally, the MOP in Swindle may not be all that well documented,
> but it is pretty straightforward. Anyone with experience in the CLOS
> MOP should have no problem finding their way around.
I agree.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Hm, I have just checked the Swindle documentation. I see that
> setf-style assignments expand to function calls where the new value
> is the last argument, not the first one as in Common Lisp. I would
> expect this to pose problems with rest lists and especially with
> keyword arguments, doesn't it?
I had a long dilemma over which side to choose. Eventually, it was
easier to put it last since that's the way that existing Scheme
setters tend to be defined. (CL use `(setf foo)' as setter names,
Swindle uses `set-foo!', which just works for many built-in setters.)
It was inconvenient in a few cases.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Christophe Rhodes
Subject: generic function overhead (was Re: Cross-lisp questions and my #lisp experience)
Date:
Message-ID: <sqek2e40k1.fsf_-_@cam.ac.uk>
Eli Barzilay <···@barzilay.org> writes:
> I need to know how `methods' is bound, I need to know what
> `call-method' is, I need to know that it's an s-expression that I'm
> supposed to construct, and I need to know the syntax of that first
> part. The only advantage that I see for the CL form is that it will
> not require an extra function call for each method -- but given the
> already big overhead of using generics, this looks pointless.
This is perhaps tangential to the rest of this thread, but I would
dispute that there is necessarily a big overhead to using generic
functions: simple experiments seem to show that in Common Lisp
implementations the amortized function call overhead of a generic
function is something of the order of a factor of two (smaller -- down
to about 1.3 -- for the very simplest cases, larger for complex
discriminating functions).
Christophe
From: Eli Barzilay
Subject: Re: generic function overhead (was Re: Cross-lisp questions and my #lisp experience)
Date:
Message-ID: <m3u0baxgxb.fsf@winooski.ccs.neu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Eli Barzilay <···@barzilay.org> writes:
>
> > I need to know how `methods' is bound, I need to know what
> > `call-method' is, I need to know that it's an s-expression that I'm
> > supposed to construct, and I need to know the syntax of that first
> > part. The only advantage that I see for the CL form is that it will
> > not require an extra function call for each method -- but given the
> > already big overhead of using generics, this looks pointless.
>
> This is perhaps tangential to the rest of this thread, but I would
> dispute that there is necessarily a big overhead to using generic
> functions: simple experiments seem to show that in Common Lisp
> implementations the amortized function call overhead of a generic
> function is something of the order of a factor of two (smaller -- down
> to about 1.3 -- for the very simplest cases, larger for complex
> discriminating functions).
Not with my simple test --
(defun fib1 (n)
(if (<= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 2)))))
(defmethod fib2 ((n integer))
(if (<= n 1) n (+ (fib2 (- n 1)) (fib2 (- n 2)))))
and I'm getting:
CL-USER(14): (time (fib1 36))
; cpu time (non-gc) 540 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 540 msec user, 0 msec system
; real time 548 msec
; space allocation:
; 1 cons cell, 0 other bytes, 0 static bytes
CL-USER(15): (time (fib2 36))
; cpu time (non-gc) 3,060 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 3,060 msec user, 0 msec system
; real time 3,155 msec
; space allocation:
; 20 cons cells, 184 other bytes, 0 static bytes
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> This is perhaps tangential to the rest of this thread, but I would
>> dispute that there is necessarily a big overhead to using generic
>> functions: simple experiments seem to show that in Common Lisp
>> implementations the amortized function call overhead of a generic
>> function is something of the order of a factor of two (smaller -- down
>> to about 1.3 -- for the very simplest cases, larger for complex
>> discriminating functions).
>
> Not with my simple test --
>
> (defun fib1 (n)
> (if (<= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 2)))))
>
> (defmethod fib2 ((n integer))
> (if (<= n 1) n (+ (fib2 (- n 1)) (fib2 (- n 2)))))
>
> and I'm getting:
>
> CL-USER(14): (time (fib1 36))
> ; cpu time (total) 540 msec user, 0 msec system
> CL-USER(15): (time (fib2 36))
> ; cpu time (total) 3,060 msec user, 0 msec system
> ; 20 cons cells, 184 other bytes, 0 static bytes
On my system (SBCL 0.9.9.x on an 1.8GHz x86-64) these times are,
respectively, 1.6 seconds and 2.3 seconds, for a factor of 1.4 (as I
said). Similar results (1.9s and 2.4s) are obtained on SBCL on a
2.7GHz G5, so this isn't just the SBCL x86 calling convention[*] being
weird.
The fact that (I presume, from its time output format) Allegro only
generates 184 bytes (and 20 cons cells) of garbage from the generic
call might indicate that it isn't cacheing effective methods very
aggressively (I can only speculate, as I am not privy to the internal
workings of Allegro). Nevertheless, I stand by my claim of small
factors for generic function overhead.
Christophe
[*] See
<http://jsnell.iki.fi/blog/archive/2006-02-06-re-calling-convention.html>
and references therein for some more information.
Pascal Costanza <··@p-cos.net> writes:
> You're not testing generic function overhead, you're testing type
> testing overhead.
That was intentional, of course.
Christophe Rhodes <·····@cam.ac.uk> writes:
>
> On my system (SBCL 0.9.9.x on an 1.8GHz x86-64) these times are,
> respectively, 1.6 seconds and 2.3 seconds, for a factor of 1.4 (as I
> said). Similar results (1.9s and 2.4s) are obtained on SBCL on a
> 2.7GHz G5, so this isn't just the SBCL x86 calling convention[*]
> being weird.
I assume that SBCL was able to analyze the type check away, so that's
not too surprising.
(In any case, I assume that everyone involved know the bogosity of
talking about this -- consider that in Swindle the speed loss for the
same code is about a factor of 40. (And using the new JIT it is a bit
better -- x30, but still plenty of room for optimizing.))
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> writes:
> Pascal Costanza <··@p-cos.net> writes:
>
>> You're not testing generic function overhead, you're testing type
>> testing overhead.
>
> That was intentional, of course.
If that was your intent, it wasn't terribly apposite, nor did you
achieve it. (If your intent was to demonstrate the possibility of
measuring the wrong thing in simple tests, you of course have a fair
point: to make precise claims without an equally-detailed description
of the universe under consideration leads to confusion at best.)
FIB1 disassembles to the following:
; 02711BBF: L0: 488975E0 MOV [RBP-32], RSI ; no-arg-parsing entry point
; BC3: BF08000000 MOV EDI, 8
; BC8: 488BD6 MOV RDX, RSI
; BCB: 4C8D1C250D050020 LEA R11, [#x2000050D] ; GENERIC->
; BD3: 41FFD3 CALL R11
; BD6: 488BE3 MOV RSP, RBX
; BD9: 488B75E0 MOV RSI, [RBP-32]
; BDD: 4881FA17000040 CMP RDX, 1073741847
; BE4: 750E JNE L2
; BE6: 488BCE MOV RCX, RSI
; BE9: L1: 488D65F0 LEA RSP, [RBP-16]
; BED: 488B6DF8 MOV RBP, [RBP-8]
; BF1: C20800 RET 8
; BF4: L2: 488975E0 MOV [RBP-32], RSI
; BF8: BF08000000 MOV EDI, 8
; BFD: 488BD6 MOV RDX, RSI
; C00: 4C8D1C25CA020020 LEA R11, [#x200002CA] ; GENERIC--
; C08: 41FFD3 CALL R11
; C0B: 488BE3 MOV RSP, RBX
; C0E: 488BC5 MOV RAX, RBP
; C11: 488BCC MOV RCX, RSP
; C14: 4883EC40 SUB RSP, 64
; C18: 488BF2 MOV RSI, RDX
; C1B: 488941F8 MOV [RCX-8], RAX
; C1F: 488BE9 MOV RBP, RCX
; C22: 488D0506000000 LEA RAX, [RIP+6]
; C29: 488945F0 MOV [RBP-16], RAX
; C2D: EB90 JMP L0
; C2F: 488B75E0 MOV RSI, [RBP-32]
; C33: 48894DE8 MOV [RBP-24], RCX
; C37: BF10000000 MOV EDI, 16
; C3C: 488BD6 MOV RDX, RSI
; C3F: 4C8D1C25CA020020 LEA R11, [#x200002CA] ; GENERIC--
; C47: 41FFD3 CALL R11
; C4A: 488BE3 MOV RSP, RBX
; C4D: 488BC5 MOV RAX, RBP
; C50: 488BCC MOV RCX, RSP
; C53: 4883EC40 SUB RSP, 64
; C57: 488BF2 MOV RSI, RDX
; C5A: 488941F8 MOV [RCX-8], RAX
; C5E: 488BE9 MOV RBP, RCX
; C61: 488D0509000000 LEA RAX, [RIP+9]
; C68: 488945F0 MOV [RBP-16], RAX
; C6C: E94EFFFFFF JMP L0
; C71: 488B55E8 MOV RDX, [RBP-24]
; C75: 488BF9 MOV RDI, RCX
; C78: 4C8D1C2540020020 LEA R11, [#x20000240] ; GENERIC-+
; C80: 41FFD3 CALL R11
; C83: 488BE3 MOV RSP, RBX
; C86: 488BCA MOV RCX, RDX
; C89: E95BFFFFFF JMP L1
; C8E: 90 NOP
; C8F: 90 NOP
The relevant features here are the four calls to generic arithmetic
routines, and the fact that we have inlined some the self calls.
The function for (method fib2 (integer)) disassembles to
; 0271271B: 488B55E8 MOV RDX, [RBP-24] ; no-arg-parsing entry point
; 1F: BF08000000 MOV EDI, 8
; 24: 4C8D1C250D050020 LEA R11, [#x2000050D] ; GENERIC->
; 2C: 41FFD3 CALL R11
; 2F: 488BE3 MOV RSP, RBX
; 32: 4881FA17000040 CMP RDX, 1073741847
; 39: 7518 JNE L1
; 3B: 488B55E8 MOV RDX, [RBP-24]
; 3F: L0: 488B4DF0 MOV RCX, [RBP-16]
; 43: 488B45F8 MOV RAX, [RBP-8]
; 47: 4883C103 ADD RCX, 3
; 4B: 488BE5 MOV RSP, RBP
; 4E: 488BE8 MOV RBP, RAX
; 51: FFE1 JMP RCX
; 53: L1: 488B55E8 MOV RDX, [RBP-24]
; 57: BF08000000 MOV EDI, 8
; 5C: 4C8D1C25CA020020 LEA R11, [#x200002CA] ; GENERIC--
; 64: 41FFD3 CALL R11
; 67: 488BE3 MOV RSP, RBX
; 6A: 488BDC MOV RBX, RSP
; 6D: 4883EC18 SUB RSP, 24
; 71: 488B0558FFFFFF MOV RAX, [RIP-168] ; #<FDEFINITION object for FIB2>
; 78: B908000000 MOV ECX, 8
; 7D: 48896BF8 MOV [RBX-8], RBP
; 81: 488BEB MOV RBP, RBX
; 84: FF5009 CALL QWORD PTR [RAX+9]
; 87: 488BE3 MOV RSP, RBX
; 8A: 488955E0 MOV [RBP-32], RDX
; 8E: 488B55E8 MOV RDX, [RBP-24]
; 92: BF10000000 MOV EDI, 16
; 97: 4C8D1C25CA020020 LEA R11, [#x200002CA] ; GENERIC--
; 9F: 41FFD3 CALL R11
; A2: 488BE3 MOV RSP, RBX
; A5: 488BDC MOV RBX, RSP
; A8: 4883EC18 SUB RSP, 24
; AC: 488B051DFFFFFF MOV RAX, [RIP-227] ; #<FDEFINITION object for FIB2>
; B3: B908000000 MOV ECX, 8
; B8: 48896BF8 MOV [RBX-8], RBP
; BC: 488BEB MOV RBP, RBX
; BF: FF5009 CALL QWORD PTR [RAX+9]
; C2: 488BE3 MOV RSP, RBX
; C5: 488BFA MOV RDI, RDX
; C8: 488B55E0 MOV RDX, [RBP-32]
; CC: 4C8D1C2540020020 LEA R11, [#x20000240] ; GENERIC-+
; D4: 41FFD3 CALL R11
; D7: 488BE3 MOV RSP, RBX
; DA: E960FFFFFF JMP L0
; DF: 90 NOP
We have the same four calls to generic arithmetic, while we have full
calls to the generic function FIB2. The type testing differences
between FIB1 and FIB2 are, I believe, negligible, while the essential
difference lies in the fact that this method function is called from
the generic function's discriminating function.
It is possibly true that the amount of work done in the _body_ of the
fibonacci function, apart from the function call, is moderating the
effect of the different function call sequences; making more precise
claims would involve more measurements, and more experiments.
> Christophe Rhodes <·····@cam.ac.uk> writes:
>>
>> On my system (SBCL 0.9.9.x on an 1.8GHz x86-64) these times are,
>> respectively, 1.6 seconds and 2.3 seconds, for a factor of 1.4 (as I
>> said). Similar results (1.9s and 2.4s) are obtained on SBCL on a
>> 2.7GHz G5, so this isn't just the SBCL x86 calling convention[*]
>> being weird.
>
> I assume that SBCL was able to analyze the type check away, so that's
> not too surprising.
There is rather more than one type check involved here, but I think
that the number of type checks performed in your FIB1 and FIB2 is in
fact not the major determinant of the time difference. (I'm not
certain; I'd have to perform more measurements than I have time for
right now; anyone interested can start up the statistical profiler and
collect data about where the hotspots are.
> (In any case, I assume that everyone involved know the bogosity of
> talking about this -- consider that in Swindle the speed loss for the
> same code is about a factor of 40. (And using the new JIT it is a bit
> better -- x30, but still plenty of room for optimizing.))
I maintain that this is evidence in favour of my assertion that the
overhead of generics need not be terribly high. Whether that's
bogosity in your view I leave for you to clarify.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Eli Barzilay <···@barzilay.org> writes:
>
> > Pascal Costanza <··@p-cos.net> writes:
> >
> >> You're not testing generic function overhead, you're testing type
> >> testing overhead.
> >
> > That was intentional, of course.
>
> If that was your intent, it wasn't terribly apposite, nor did you
> achieve it. [...]
The origin of this sub^n thread was whether optimization is a good
excuse to avoid using a function for creating new method combinations
-- I said that optimization seems like a bad excuse for avoiding
functions since interesting cases of using generics are ones where you
pay a speed penalty in any case. The point -- IMO -- of CLOS (or any
object system) is making it easier to manage code, not getting things
to run faster.
You seem to be trying to show me how CL compilers are so great that
the speed loss is minimal, but I never disputed this. I know that
there are some excellent compilers that do some amazing things with
generics, but these compilers are also very good at optimizing
closures and function calls, so the cleaner approach of using a
function for specifying combinations should be just as good.
(If you believe that using functions is not cleaner, then I'm
obviously talking to myself here.)
> There is rather more than one type check involved here, but I think
> that the number of type checks performed in your FIB1 and FIB2 is in
> fact not the major determinant of the time difference. (I'm not
> certain; I'd have to perform more measurements than I have time for
> right now; anyone interested can start up the statistical profiler
> and collect data about where the hotspots are. [...]
(I hope that the above clarifies the point, I did not mean for anyone
to waste good hacking time on profiling silly examples.) (Unless you
want to further show how good CL compilers are, which could be a good
cause irrelevant of the thread.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Christophe Rhodes <·····@cam.ac.uk> writes:
> > (defun fib1 (n)
> > (if (<= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 2)))))
> > (defmethod fib2 ((n integer))
> > (if (<= n 1) n (+ (fib2 (- n 1)) (fib2 (- n 2)))))
> On my system (SBCL 0.9.9.x on an 1.8GHz x86-64) these times are,
> respectively, 1.6 seconds and 2.3 seconds, for a factor of 1.4 (as I
> said).
On my 4? year old PC, the factor is 1.63 for CLISP-2.38. And nobody
shall accuse CLISP of doing type inference ;) (it does none)
Eli Barzilay wrote:
>The origin of this sub^n thread was whether optimization is a good
>excuse to avoid using a function for creating new method combinations
A valid point.
>-- I said that optimization seems like a bad excuse for avoiding
>functions since interesting cases of using generics are ones where you
>pay a speed penalty in any case.
Possibly irrelevant argumentation (I don't know).
IMHO, better speed can be obtained by doing the optimization, but
experience with CL-PPCRE shows that it's not necessary in order to be
fast enough.
When Edi Weitz developed CL-PPCRE, he initially caused regexps to
compile to lots of closures funcall'ing each other. He found out that
it's already faster than the Perl regex engine (on Lisp compiling to
native code), so there was no interest to move even further.
I had expected cl-ppcre to compile to compilable Lisp code to achieve
its speed, but it does not. It's just closures and FUNCALL.
Similarly, a MOP based on user-composed closures to achieve method
combination may be fast enough. No perceived need for additional
macro-based inlining.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Pascal Costanza
Subject: Re: generic function overhead (was Re: Cross-lisp questions and my #lisp experience)
Date:
Message-ID: <44u23nF3sfe8U1@individual.net>
Eli Barzilay wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>>Eli Barzilay <···@barzilay.org> writes:
>>
>>
>>>I need to know how `methods' is bound, I need to know what
>>>`call-method' is, I need to know that it's an s-expression that I'm
>>>supposed to construct, and I need to know the syntax of that first
>>>part. The only advantage that I see for the CL form is that it will
>>>not require an extra function call for each method -- but given the
>>>already big overhead of using generics, this looks pointless.
>>
>>This is perhaps tangential to the rest of this thread, but I would
>>dispute that there is necessarily a big overhead to using generic
>>functions: simple experiments seem to show that in Common Lisp
>>implementations the amortized function call overhead of a generic
>>function is something of the order of a factor of two (smaller -- down
>>to about 1.3 -- for the very simplest cases, larger for complex
>>discriminating functions).
>
> Not with my simple test --
>
> (defun fib1 (n)
> (if (<= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 2)))))
>
> (defmethod fib2 ((n integer))
> (if (<= n 1) n (+ (fib2 (- n 1)) (fib2 (- n 2)))))
>
> and I'm getting:
>
> CL-USER(14): (time (fib1 36))
> ; cpu time (non-gc) 540 msec user, 0 msec system
> ; cpu time (gc) 0 msec user, 0 msec system
> ; cpu time (total) 540 msec user, 0 msec system
> ; real time 548 msec
> ; space allocation:
> ; 1 cons cell, 0 other bytes, 0 static bytes
>
> CL-USER(15): (time (fib2 36))
> ; cpu time (non-gc) 3,060 msec user, 0 msec system
> ; cpu time (gc) 0 msec user, 0 msec system
> ; cpu time (total) 3,060 msec user, 0 msec system
> ; real time 3,155 msec
> ; space allocation:
> ; 20 cons cells, 184 other bytes, 0 static bytes
You're not testing generic function overhead, you're testing type
testing overhead. You have to make one of the following two changes. Either:
(defun fib1 (n)
(check-type n integer))
...)
Or:
(defmethod fib2 (n)
...)
There could also be subtle issues because one of the recursive calls is
in a tail position. I don't think that tail calls are optimized in
generic functions (but this is just a guess). Better use an example in
which this cannot possibly interfere with your test results.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44u1ifF40g0jU1@individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>I was just thinking out loud. I wanted to claim that the
>>macro-expansion-style method combinations in CL is easier to
>>understand, but then realized that this is probably a matter of
>>getting used to. I didn't understand the various kinds of
>>constructing method combinations in Swindle, but I also didn't
>>seriously try them out, so I can't really tell the difference, to be
>>honest.
>
> In that case my first point holds: I think that using a function is
> clearer since its binding structure is clear, and since it does not
> require any extra lingustic constructs I see
>
> (lambda (loop val this tail) (or (this) (loop #f tail)))
>
> and I can easily tell what it does, and given the interface, I can see
> how the method combination mechanism uses it. But when I look at:
>
> ((methods (or)))
> `(or ,@(loop for method in methods
> collect `(call-method ,method))))
>
> I need to know how `methods' is bound, I need to know what
> `call-method' is, I need to know that it's an s-expression that I'm
> supposed to construct, and I need to know the syntax of that first
> part.
You also need to know a few things in your case: What is val? Why is it
not used? How is loop bound? What do I need to pass? What does the first
parameter #f mean?
I would rather think that both approaches are more or less on par.
> The only advantage that I see for the CL form is that it will
> not require an extra function call for each method -- but given the
> already big overhead of using generics, this looks pointless.
Christophe already explained that generic functions don't lead to a
serious overhead. This is the case for all of the CLOS implementations I
have checked. Apparently, the design of CLOS hits the right balance in
this regard.
> (And now take all that and qualify it with a big YMMV -- perhaps you
> were able to write all that without looking at the manual.)
No, I wasn't. I always pick one of the examples in the HyperSpec and
modify it according to my needs. I find define-method-combination overly
complicated. It would be absolutely sufficient to define methods on
compute-effective-method to get exactly the same effects, but
define-method-combination is the standardized means to do this.
>>>Ah, I forgot about that. (It's been a few years...) Given that
>>>there is a generic that sorts the methods, it doesn't look like it
>>>would take much to implement, but my hacking plate is full.
>>
>>I think this isn't in TinyCLOS because Scheme neither has setf-style
>>writers nor keyword arguments (although it has rest arguments),
>
> (Swindle does have both.)
...and that's why, IMHO, Swindle should add user-defined argument
precedence orders.
>>and foremostly because it was supposed to be used for pedagogical
>>purposes. [...]
>
> This is a completely bogus point. Scheme did not start as an exercise
> in pedagogy, and implementations are not actively used today for
> teaching. It has been a by-product of cleaner semantics, and
> SICP/6.001 made it popular for teaching. I don't think that I ever
> saw a scheme-implementation make any design decision due to
> pedagogical reason -- including DrScheme which has extensive support
> for students yet none of that made any difference in the core
> language. (I thought that you were aware of all that.)
I am aware of that, and it's a misunderstanding. (Sorry, if I have
caused it.) What I meant was that TinyCLOS was supposed to be used for
pedagogical purposes.
From the original TinyCLOS announcement:
"One stumbling block for people interested in playing with the
metaobject protocol (MOP) ideas has been the relative complexity of
working in Common Lisp. This has been a particular obstacle for
undergraduates and others who normally work in Scheme (or a very reduced
Common Lisp). To try and address this, we have designed and implemented
a Scheme embedding of a core subset of CLOS, with a corresponding core MOP.
Since our primary goal is pedagogical in nature, we have been able to
produce an extremely lean language, MOP and implementation. The
implementation is even simpler than the simple CLOS found in `The Art of
the Metaobject Protocol,' weighing in at around 850 lines of code,
including (some) comments and documentation."
See ftp://parcftp.xerox.com/pub/mops/
>>>Once I made it more realistic by adding caches in various places,
>>>I did need to specify certain assumptions like functionality of
>>>meta-generics etc. In any case, your original claim was that
>>>Swindle lacks "a specified metaobject protocol" not a
>>>specification of possible optimizations.
>>
>>I think that's an integral part of such a specification. This is
>>explained in the AMOP book in more detail. TinyCLOS and Swindle
>>"only" explains which functions call which other functions, but it
>>doesn't state anything about guarantees whether they always call
>>each other, whether overriding methods have to return the original
>>values or not, etc.
>
> How can you confuse CLOS (a spec), Tiny-CLOS (a demonstrational tool),
> and Swindle (an implementation)?
I don't. The claim that Swindle's "MOP is as specified as it needs to
be" was yours. I just pointed out what elements are missing that I think
are important in a specification.
> If I had intentions to make Swindle
> into something that is implemented by other people, I would definitely
> need to document this, and I certainly need to document it for users
> who may want to use the MOP. If there are facts that are not
> documented, it is only due to the lack of manpower.
I didn't mean to attack you. I think Swindle is very good - it would be
the first candidate to port ContextL to, which I actually have thought
about a few times.
>>If you don't know about these issues, writing your own metaclasses
>>probably requires you to inspect the source code of TinyCLOS to see
>>what's really going on.
>>
>>Again, that's sufficient for pedagogical purposes, but not for
>>production code IMHO.
>
> ...and here we go again. FWIW, Swindle was used in one course which
> did not discuss its implementation or the MOP (or *any* MOP). There
> was no MOP design decision whatsoever that was made for any form of
> teaching. None. Take the MOP out, and that course would change one
> bit.
I was talking about TinyCLOS here, not about Scheme and not about Swindle.
>>Sorry, I wanted to delete my remark about apply, but obviously
>>forgot to do so. But as a sidenote, it's interesting that PLT Scheme
>>has added a kind of prototype-based object-oriented system with
>>their module system through the backdoor, together with a metaobject
>>protocol for function application. This seems to me quite
>>heavy-weight for the simple task of changing the semantics of
>>built-in operators.
>
> You lost me here. The module system has no relation to prototype
> based OOs, and no meta objects of any form.
I think it's possible to regard modules as prototypes (i.e., objects ex
nihilo that are not instances of any class). They define inheritance
relationships to other prototypes to which messages are delegated if
they cannot respond to them by themselves. PLT Scheme's module system
also allows you to define inheritance relationships between modules and
redefine operators from other modules.
The ability to redefine method / procedure / function application is
typically considered a feature of metaobject / reflective protocols of
prototype-based languages.
It really seems to me that the ingredients are all there.
> The module system is a
> syntactic tool (resolving and linking names, separate compilation
> phases, etc). When I write a module that redefines function
> application, I'm only translating code -- for example, if I write
>
> (module foo mzscheme
> (provide (all-from-except mzscheme #%app)
> (rename foo-app #%app))
> (define-syntax foo-app
> (syntax-rules (+)
> [(_ x + y) (+ x y)]
> [(_ x . xs) (x . xs)])))
>
> and use it like this:
>
> (1 + 2)
>
> then this form is expanded to
>
> (#%app 1 + 2)
>
> and this `#%app' is my own `foo-app' syntax above, which means that it
> gets expanded to
>
> (#%app + 1 2)
>
> and this is the built-in `#%app' that is implicit in that `(+ x y)'
> pattern. No objects, and no protocol beyond macro expansion.
Does this mean that #%app is "only" redefined for the textual scope of
the module in which it is redefined, in the sense that functions
inherited from other modules are not affected?
> BTW, the
> macro is lighter in that it does not lead to additional run-time costs
> like a MOP.
OK, sounds good. (Again, the runtime costs of generic function
application are extremely low in CLOS, but that's not really important
here in this very specific context.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
> > In that case my first point holds: I think that using a function is
> > clearer since its binding structure is clear, and since it does not
> > require any extra lingustic constructs I see
> > (lambda (loop val this tail) (or (this) (loop #f tail)))
> > and I can easily tell what it does, and given the interface, I can see
> > how the method combination mechanism uses it. But when I look at:
> > ((methods (or)))
> > `(or ,@(loop for method in methods
> > collect `(call-method ,method))))
> > I need to know how `methods' is bound, I need to know what
> > `call-method' is, I need to know that it's an s-expression that I'm
> > supposed to construct, and I need to know the syntax of that first
> > part.
>
> You also need to know a few things in your case: What is val? Why is
> it not used? How is loop bound? What do I need to pass? What does
> the first parameter #f mean?
Right -- which is, like I said, the interface that you need to know.
But using a function means that you don't need to use the extra
linguistics -- in the CL case that's completely different.
> > This is a completely bogus point. [...blah...blah...blah...]
>
> I am aware of that, and it's a misunderstanding. (Sorry, if I have
> caused it.) What I meant was that TinyCLOS was supposed to be used
> for pedagogical purposes.
Ah, in that case I agree (that it is pedagogically-oriented).
> > You lost me here. The module system has no relation to prototype
> > based OOs, and no meta objects of any form.
>
> I think it's possible to regard modules as prototypes (i.e., objects
> ex nihilo that are not instances of any class). They define
> inheritance relationships to other prototypes to which messages are
> delegated if they cannot respond to them by themselves. PLT Scheme's
> module system also allows you to define inheritance relationships
> between modules and redefine operators from other modules.
It's easy to talk about this, but to make this a proper analogy you'd
have to work hard.
> The ability to redefine method / procedure / function application is
> typically considered a feature of metaobject / reflective protocols
> of prototype-based languages.
>
> It really seems to me that the ingredients are all there.
(Reflectivity is still there. Meta is there without the object
(ignoring the obvious pun). Prototypeness is not there.)
> > The module system is a syntactic tool (resolving and linking
> > names, separate compilation phases, etc). When I write a module
> > that redefines function application, I'm only translating code --
> > for example, if I write
> > (module foo mzscheme
> > (provide (all-from-except mzscheme #%app)
> > (rename foo-app #%app))
> > (define-syntax foo-app
> > (syntax-rules (+)
> > [(_ x + y) (+ x y)]
> > [(_ x . xs) (x . xs)])))
> > and use it like this:
>
> > (1 + 2)
>
> > then this form is expanded to
>
> > (#%app 1 + 2)
>
> > and this `#%app' is my own `foo-app' syntax above, which means that it
>
> > gets expanded to
> > (#%app + 1 2)
>
> > and this is the built-in `#%app' that is implicit in that `(+ x y)'
>
> > pattern. No objects, and no protocol beyond macro expansion.
>
> Does this mean that #%app is "only" redefined for the textual scope
> of the module in which it is redefined, in the sense that functions
> inherited from other modules are not affected?
Almost -- it means that modules that use `foo' can use *only* what
`foo' gives them, so when you write
(1 + 2)
which is implicitly
(#%app 1 + 2)
the *syntactic* meaning of `#%app' is determined by `foo' -- and that
meaning uses the built in `#%app', but these two identifiers only
look the same -- they are different.
And the main feature is that there is no effect at all on any other
module. In Swindle you can conveniently (set! (car x) y), but that
has no effect on other modules. So you can write a Swindle module
that uses another module or the other way, and the respective
languages would not interfere each other. You could also write code
using Swindle that interacts with code that uses the PLT object
system. You could even do some hackery (instantiate Swindle in a new
namespace) and have "two" swindles, each one seeing the values of the
other as foreign/primitive data.
(Before the PLT module system, I had to hack DrScheme into DrSwindle,
since it was redefining too much to be usable, and this *was*
redefinition. After it, there was no need for this hack since there
is no redefinition in the real sense, it's closer to shadowing in some
sense.)
> > BTW, the macro is lighter in that it does not lead to additional
> > run-time costs like a MOP.
>
> OK, sounds good. (Again, the runtime costs of generic function
> application are extremely low in CLOS, but that's not really
> important here in this very specific context.)
Well, there is *no* runtime cost at all for redefining #%app in PLT.
The two examples below take the same time to run because the code that
is executed is exactly the same in both cases.
> (module foo mzscheme
(provide (all-from-except mzscheme #%app)
(rename foo-app #%app))
(define-syntax foo-app
(syntax-rules (+ -)
[(_ x + y) (+ x y)]
[(_ x - y) (- x y)]
[(_ x . xs) (x . xs)])))
> (module f1 mzscheme (provide fib1)
(define (fib1 n) (if (<= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 2))))))
> (module f2 foo (provide fib2)
(define (fib2 n) (if (<= n 1) n ((fib2 (n - 1)) + (fib2 (n - 2))))))
> (require f1 f2)
> (time (fib1 40))
cpu time: 8768 real time: 9292 gc time: 0
102334155
> (time (fib2 40))
cpu time: 8677 real time: 9365 gc time: 0
102334155
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44uphrF42mpdU1@individual.net>
Eli Barzilay wrote:
>>>You lost me here. The module system has no relation to prototype
>>>based OOs, and no meta objects of any form.
>>
>>I think it's possible to regard modules as prototypes (i.e., objects
>>ex nihilo that are not instances of any class). They define
>>inheritance relationships to other prototypes to which messages are
>>delegated if they cannot respond to them by themselves. PLT Scheme's
>>module system also allows you to define inheritance relationships
>>between modules and redefine operators from other modules.
>
> It's easy to talk about this, but to make this a proper analogy you'd
> have to work hard.
Probably.
> (Before the PLT module system, I had to hack DrScheme into DrSwindle,
> since it was redefining too much to be usable, and this *was*
> redefinition. After it, there was no need for this hack since there
> is no redefinition in the real sense, it's closer to shadowing in some
> sense.)
OK, thanks for the explanation.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Eli Barzilay <···@barzilay.org> writes:
> (module foo mzscheme
> (provide (all-from-except mzscheme #%app)
> (rename foo-app #%app))
> (define-syntax foo-app
> (syntax-rules (+)
> [(_ x + y) (+ x y)]
> [(_ x - y) (- x y)]
> [(_ x . xs) (x . xs)])))
>
> and use it like this:
>
> (1 + 2)
>
> then this form is expanded to
>
> (#%app 1 + 2)
>
> and this `#%app' is my own `foo-app' syntax above, which means that it
> gets expanded to
>
> (#%app + 1 2)
>
> and this is the built-in `#%app' that is implicit in that `(+ x y)'
> pattern. No objects, and no protocol beyond macro expansion.
> (module f2 foo (provide fib2)
> (define (fib2 n) (if (<= n 1) n ((fib2 (n - 1)) + (fib2 (n - 2))))))
This is very cool. It probably derives from Scheme's praised
referential transparency, where new definitions do not supersede old
ones and unrelated functions continue to work as before.
I'm really surprised that every call goes through %app(lication)
(which is needed to make this example work). The (CL) compilers I
know have no single place where they compile function application.
Well, it could be changed, but that won't happen in Common Lisp.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> writes:
> Eli Barzilay <···@barzilay.org> writes:
> > (module foo mzscheme
> > (provide (all-from-except mzscheme #%app)
> > (rename foo-app #%app))
> > (define-syntax foo-app
> > (syntax-rules (+)
> > [(_ x + y) (+ x y)]
> > [(_ x - y) (- x y)]
> > [(_ x . xs) (x . xs)])))
> >
> > and use it like this:
> >
> > (1 + 2)
> >
> > then this form is expanded to
> >
> > (#%app 1 + 2)
> >
> > and this `#%app' is my own `foo-app' syntax above, which means that it
> > gets expanded to
> >
> > (#%app + 1 2)
> >
> > and this is the built-in `#%app' that is implicit in that `(+ x y)'
> > pattern. No objects, and no protocol beyond macro expansion.
>
> > (module f2 foo (provide fib2)
> > (define (fib2 n) (if (<= n 1) n ((fib2 (n - 1)) + (fib2 (n - 2))))))
>
> This is very cool. It probably derives from Scheme's praised
> referential transparency, where new definitions do not supersede old
> ones and unrelated functions continue to work as before.
Yes. (And something like a 2-lisp cannot make up for these kinds of
games. But that's a different story, no bait intended.)
> I'm really surprised that every call goes through %app(lication)
> (which is needed to make this example work).
It's a macro, which means that the "goes" in the above sentence is
strictly at compile-time.
> The (CL) compilers I know have no single place where they compile
> function application. Well, it could be changed, but that won't
> happen in Common Lisp.
Right -- it's good to have the #%app hook, because it makes it very
easy to do things that would require a full code walker otherwise.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Pascal Costanza wrote:
> I am not aware of any Scheme system that provides reader macros,
> for example. (Maybe MIT Scheme...)
The relevant sections of the PLT manual is
11.2.6 Replacing the Reader
11.2.8 Customizing the Reader through Readtables
11.2.9 Reader-Extension Procedures
Readtables were added in august 2005.
<http://docs.plt-scheme.org/mzscheme/mzscheme-Z-H-11.html#node_sec_11.2.6>
<http://docs.plt-scheme.org/mzscheme/mzscheme-Z-H-11.html#node_sec_11.2.8>
<http://docs.plt-scheme.org/mzscheme/mzscheme-Z-H-11.html#node_sec_11.2.8>
Gambit have them too:
<http://www.iro.umontreal.ca/~gambit/doc/gambit-c_17.html>
--
Jens Axel S�gaard
········@yahoo.com wrote:
> Thanks for the very detailed reply, Alexander, although I don't
> appreciate some of the overtones.
uh-oh, provocative language....
>
>
>>Personally I
>>wouldn't want to use a language for a real project that doesn't give you
>>something roughly equivalent to 1-3.
>
>
> 1-3 in your list of features?
>
> By the way, this is what I wanted to know: what people find the most
> compelling reasons to use Common Lisp. Not a list of 1001 differences.
uh-oh, so he /does/ want a Lisp/Scheme flamewar, not info on UCW....
>
>
>>If you really want to know, sitting down and spending some time with
>>sbcl+emacs+slime and e.g. practical common lisp or some UCW tutorial beats
>>asking vague questions along the lines "is there really any point in using
>>lisp/UCW?" on comp.lang.lisp.
>
>
> I will pass the emacs+slime+sbcl part up, given the people who hang out
> in this group.
The Savages of comp.lang.lisp?
> I don't want to be called a troll again.
Troll. :) Looks like the yobs got it right after all.
<snip more hissing one never gets from people really seeking info>
kenny
> > Thanks for the very detailed reply, Alexander, although I don't
> > appreciate some of the overtones.
>
> uh-oh, provocative language....
What, I have no right to mention that I do not like it when someone
implies things I don't agree with about me? Oh, I forgot: I am the
accused.
> > By the way, this is what I wanted to know: what people find the most
> > compelling reasons to use Common Lisp. Not a list of 1001 differences.
>
> uh-oh, so he /does/ want a Lisp/Scheme flamewar, not info on UCW....
How in the world did you jump to that ? I said I liked input from
passionate Lisp users -- because if they really care about something,
there's probably a reason they do. I was actually more interested in
the narrower topic of webapp frameworks, but whatever. And by the way,
thanks to everybody who has responded with a technical post -- it feels
good to be exposed to different opinions.
> Troll. :) Looks like the yobs got it right after all.
Why am I even replying to this? Why have I even posted on c.l.l in the
first place (no offense to the people who provided constructive input
in this thread)? Why do you feel compelled to reply, if you have
nothing to say about the topic, but everything to say about the poster?
-- Dan
·······@gmail.com wrote:
>>>Thanks for the very detailed reply, Alexander, although I don't
>>>appreciate some of the overtones.
>>
>>uh-oh, provocative language....
>
>
> What, I have no right to mention that I do not like it when someone
> implies things I don't agree with about me? Oh, I forgot: I am the
> accused.
Nah, it is just that you are encouraging more tit-for-tat. You are not
trying to avoid this interpersonal crap, you are all over it.
>
>
>>>By the way, this is what I wanted to know: what people find the most
>>>compelling reasons to use Common Lisp. Not a list of 1001 differences.
>>
>>uh-oh, so he /does/ want a Lisp/Scheme flamewar, not info on UCW....
>
>
> How in the world did you jump to that ? I said I liked input from
> passionate Lisp users --
WTF happened to "I do not want to start a flamewar, I just want to know
if UCW has special expressive power."?
>
>
>>Troll. :) Looks like the yobs got it right after all.
>
>
> Why am I even replying to this? Why have I even posted on c.l.l in the
> first place (no offense to the people who provided constructive input
> in this thread)?
Why am I even reading this? Oh, you have a second email I need to add to
my killfile.
> Why do you feel compelled to reply, if you have
> nothing to say about the topic, but everything to say about the poster?
Folks here on c.l.l are in fact a bunch of sweethearts who can take
weeks to realize they are talking to a brick troll.
kenny
From: Alexander Schmolck
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <yfsoe1iei4c.fsf@oc.ex.ac.uk>
········@yahoo.com writes:
> Thanks for the very detailed reply, Alexander, although I don't
> appreciate some of the overtones.
OK, no overtones this time.
> > Personally I
> > wouldn't want to use a language for a real project that doesn't give you
> > something roughly equivalent to 1-3.
>
> 1-3 in your list of features?
Yes.
> By the way, this is what I wanted to know: what people find the most
> compelling reasons to use Common Lisp. Not a list of 1001 differences.
In which case you should look at one of the numerous CL vs scheme
discussions/flamefests that have taken place in the past. If you have already
done that then it would have been good to ask more specific questions (like
"I've heard that slime+cl offers a nicer interactive development environment
than most schemes -- can you give some examples of features you find
particularly neat?").
> I will pass the emacs+slime+sbcl part up, given the people who hang out
> in this group. I don't want to be called a troll again.
That's a non-sequitur. No one will call you a troll if you sit down with
emacs+slime+sbcl. I'm also sure there are plenty of people that do that and
never post to c.l.l. -- so even if you think the residents in this group are a
bunch of jerks this doesn't necessarily prevent you from getting some mileage
out of playing with emacs+slime+sbcl (amongst other things there are at least
2,3 lisp books that might be well worth reading even if you never intend to
use CL afterwards; PAIP for example).
> I will just say that, in the first stage, I intented to spend on UCW no
> more than the time required to go on IRC and chat about it. It's my
> time budget and I can spend it however I see fit.
Sure. However some ways of spending your time budget will be seen as rudeness
by usenet or IRC participants whose time budget you also impinge upon. Whilst
no-one will expect you to read up extensively on something only to decide that
it's useless for you, there is I think some expectation that you do find out
about things that should take you less time to search for than they would for
someone to answer.
Now for example referring to something as a "mythical beast" that a fairly
obvious google search would have turned up in the wild is not necessarily
giving the best impression, right? Especially in view of the fact that we're
talking about something you designated as a desirable feature.
It also is more difficult and time consuming to answer if questions are
imprecise or vague or if the actual needs or preferences of the asker are
somewhat unclear.
> If UCW did turn out interesting, then perhaps I would have implemented your
> plan in stage two.
No worries.
> > Only because you apparently didn't bother to google "Continuations in Common Lisp".
>
> I did. About a month ago. Of course, I didn't stumble upon that magic
> search string, I just used "continuations" "lisp".
So why not write
"I find continuations to be an invaluable abstraction for doing web
applications; since CL has no native continuation support I wondered how well
this style was supported by frameworks like UCW? (I googled for
'continuations' and 'lisp', but didn't find anything useful)."
much less likely to rub people the wrong way, no?
> > benefit of linking to the source code. Did you actually try using that
> > existing documentation to accomplish something and then got stuck?
>
> You are the first one to say that UCW documentation is sufficient. I
> was hoping for a reference manual.
As I said, I haven't used UCW so I'm in no position to judge. However, from
glancing at the website the state of documentation would certainly not prevent
me from turning to UCW if I needed a CL-based webframework -- superficially it
seems quite good to me.
I think there might be a difference in preferences at work though -- by and
large I care much more about having a clear rationale why something is useful
and some practical examples to get you going then a comprehensive and formal
reference manual (as I said, on first sight UCW doesn't seem worse in that
regard than a typical javadoc generated reference doc, either -- plus all this
stuff will be available to you *interactively*).
By contrasts, e.g. swindle's documentation (and a some SRFIs) drive me crazy,
although I assume they're not bad for completeness as references. It's just
often way to difficult to get an overview or feel for how something is
typically used for my taste. Also scheme docs typically don't allow looking up
basic short references on functions or arglist quickly (i.e. subsecond or < 3
secs or so) -- typically due to limitations of the environment and the absence
of docstrings. If you were to use slime+UCW quickly looking up something basic
likely would be much faster.
> > Probably not -- if you're happy with what you're using and prefer scheme
> > to CL why switch? It seems unlikely to me that UCW has some carefully
> > "hidden" killer features (and if it did, why would anyone tell you?).
>
> I obviously didn't mean my question that way, but thanks for distorting
> it.
Your question was phrased in a way that sounded very much like UCW has no
obvious merrits hence the sarcasm.
> Some features grow on you and turn out to be real productivity boosters.
> They are not necessarily advertised on the overview page.
> > Maybe you should just learn how to ask intelligent questions on usenet.
>
> Nice.
I meant to write "ask questions intelligently", which is slighly different,
although you might still not like the tone. Empirically though, you'll have to
admit, the answers you got turned out to be not to your liking -- you can of
course blame that on the residents of this newsgroup, but irregardless of
whether you're or wrong about that or not a more promising approach might be
to adapt your question asking technique. I'd assume had you written something
more like:
I'm currently using the Siscweb webframework for sisc scheme and am fairly
happy with it but was wondering if anyone here could compare it to UCW (or
other popular common lisp webframeworks), since I still haven't ruled out
the possibility of settling for something else. In particular I was
curious as to how well continuations were supported and in what areas
these frameworks excell. I'd also be interest to hear about distinguishing
features of either the particular webframework or Common Lisp (as opposed
to siscweb/scheme development) for web applications long time users have
come to appreciate particularly. Quality of documentation is also very
important to me. For those unfamiliar with Siscweb, it offers blablabla.
You would have gotten better answers.
'as
> In which case you should look at one of the numerous CL vs scheme
> discussions/flamefests that have taken place in the past. If you have already
> done that then it would have been good to ask more specific questions (like
> "I've heard that slime+cl offers a nicer interactive development environment
> than most schemes -- can you give some examples of features you find
> particularly neat?").
I meant Common Lisp webapp frameworks, but I keep forgetting to add
that qualification.
> That's a non-sequitur. No one will call you a troll if you sit down with
> emacs+slime+sbcl. I'm also sure there are plenty of people that do that and
I meant I had issues with slime+sbcl, but I wouldn't discuss them here.
> I meant to write "ask questions intelligently", which is slighly different,
> although you might still not like the tone. Empirically though, you'll have to
> admit, the answers you got turned out to be not to your liking -- you can of
Yes, you are right, I could have formulated my questions better. But
actually I did get some interesting answers (from some point on).
I took in all your other points that I didn't reply to.
-- Dan
From: Alexander Schmolck
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <yfsu0b9cw1d.fsf@oc.ex.ac.uk>
········@yahoo.com writes:
> I meant I had issues with slime+sbcl, but I wouldn't discuss them here.
If you mean that you didn't get it working, maybe you should try
<http://www.gigamonkeys.com/book/lispbox/>.
'as
Alexander Schmolck <··········@gmail.com> writes:
> From the top of my head:
>
> - a powerful interactive environment (docstrings, slime, images,
> hot-patching etc.)
> - the common lisp condition system
> - a sane way to pass and receive multiple arguments to and from
> proedures (keyword arguments and multiple-value-*)
> - a powerful and efficient multiple-dispatch object system
> - a programmable reader
> - a package system
> - arrays, hash-tables and structures
> - the sequence dictionary
> - the ability to name your lists "list"
> - declarations and compiler-macros for more efficient code
> - the ability to switch between implementations, even if your code
> does something non-trivial
> - commercial vendors and commercial support (there is Cadence
> Research with Chez scheme, but that doesn't seem directly
> comparable, to say Franz and Allegro Common Lisp)
>
> [...] Even with PLT, which is presumably the most featureful scheme
> implementation you won't get all of the above.
FWIW, ignoring items that do not apply if you choose PLT (switching
implementations, commercial support, and the 2-lisp flamebait), the
only thing that is missing is declarations and compiler-macros.
> Of course you do get some other things instead, depends what you
> care about most. [...]
If I compare *PLT* (not "Scheme") to CL, there are tons of these, well
beyond continuations.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Edi Weitz
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <ubqxj54h9.fsf@agharta.de>
On 07 Feb 2006 14:16:32 -0500, Eli Barzilay <···@barzilay.org> wrote:
> Alexander Schmolck <··········@gmail.com> writes:
>
>> [...] Even with PLT, which is presumably the most featureful scheme
>> implementation you won't get all of the above.
>
> FWIW, ignoring items that do not apply if you choose PLT (switching
> implementations, commercial support, and the 2-lisp flamebait), the
> only thing that is missing is declarations and compiler-macros.
That's exactly what he said - you won't get all of the above. So,
what was your point?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
The point, I believe, was that, in PLT Scheme at least, you *do* get
multiple values, a package system, arrays, hashtables, structures etc
--things that where listed as a CL advantage in Alex's post.
From: Edi Weitz
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <ulkwm5224.fsf@agharta.de>
On 7 Feb 2006 12:41:21 -0800, ·······@gmail.com wrote:
> The point, I believe, was that, in PLT Scheme at least, you *do* get
> multiple values, a package system, arrays, hashtables, structures
> etc --things that where listed as a CL advantage in Alex's post.
Alexander specifically mentioned PLT and said that it is the most
featureful Scheme implementation. He only said that even in PLT you
don't get /all/ the features he listed. To me, Eli's posting was a
non sequitur.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On 7 Feb 2006 12:41:21 -0800, ·······@gmail.com wrote:
>
> > The point, I believe, was that, in PLT Scheme at least, you *do* get
> > multiple values, a package system, arrays, hashtables, structures
> > etc --things that where listed as a CL advantage in Alex's post.
>
> Alexander specifically mentioned PLT and said that it is the most
> featureful Scheme implementation. He only said that even in PLT you
> don't get /all/ the features he listed. To me, Eli's posting was a
> non sequitur.
The point I made is that most of the listed features you don't get are
due to the different nature of the two languages, like using a `list'
argument name.
Pascal Costanza <··@p-cos.net> writes:
> ·······@gmail.com wrote:
> > The point, I believe, was that, in PLT Scheme at least, you *do*
> > get multiple values, a package system, arrays, hashtables,
> > structures etc --things that where listed as a CL advantage in
> > Alex's post.
>
> - Multiple values in Scheme have slightly different semantics than
> in Common Lisp. Note that he said "sane way" in this context when
> he referred to multiple values in Common Lisp. (Or does PLT Scheme
> deviate here from R5RS?)
It doesn't. "Sane" here is subject to personal opinions, similar to
having a double namespace.
> - I don't know of any Scheme that provides a CL-style package
> system. Many provide module systems, however.
...and I can argue that a (good) module system is a superior solution.
(But I won't.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
> The point I made is that most of the listed features you don't get are
> due to the different nature of the two languages, like using a `list'
> argument name.
This is interesting. Other than Lisp-1 vs 2 and the hygienic macro
system (which I happen to dislike), I didn't think Lisp and Scheme had
different natures. If you admit that they do, then the "Scheme is good
for teaching, not real applications" is only a step away :)
> It doesn't. "Sane" here is subject to personal opinions, similar to
> having a double namespace.
> ...and I can argue that a (good) module system is a superior solution.
> (But I won't.)
I happen to also prefer Lisp-1, Scheme's multiple values and a good
module system, but I was actually looking for personal preferences,
whatever they might be, so Alexander's response was useful to me.
-- Dan
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44si55F3qjfmU1@individual.net>
········@yahoo.com wrote:
>>The point I made is that most of the listed features you don't get are
>>due to the different nature of the two languages, like using a `list'
>>argument name.
>
> This is interesting. Other than Lisp-1 vs 2 and the hygienic macro
> system (which I happen to dislike), I didn't think Lisp and Scheme had
> different natures. If you admit that they do, then the "Scheme is good
> for teaching, not real applications" is only a step away :)
See also http://makeashorterlink.com/?E2E9254F6 and
http://c2.com/cgi/wiki?LispSchemeDifferences
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44sh63F3id20U1@individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>·······@gmail.com wrote:
>>
>>>The point, I believe, was that, in PLT Scheme at least, you *do*
>>>get multiple values, a package system, arrays, hashtables,
>>>structures etc --things that where listed as a CL advantage in
>>>Alex's post.
>>
>>- Multiple values in Scheme have slightly different semantics than
>> in Common Lisp. Note that he said "sane way" in this context when
>> he referred to multiple values in Common Lisp. (Or does PLT Scheme
>> deviate here from R5RS?)
>
> It doesn't. "Sane" here is subject to personal opinions, similar to
> having a double namespace.
Absolutely.
>>- I don't know of any Scheme that provides a CL-style package
>> system. Many provide module systems, however.
>
> ...and I can argue that a (good) module system is a superior solution.
> (But I won't.)
Thanks... ;-)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
>
> > Pascal Costanza <··@p-cos.net> writes:
> >>- I don't know of any Scheme that provides a CL-style package
> >> system. Many provide module systems, however.
> > ...and I can argue that a (good) module system is a superior
> > solution. (But I won't.)
>
> Thanks... ;-)
(Heh...)
········@yahoo.com writes:
> > The point I made is that most of the listed features you don't get
> > are due to the different nature of the two languages, like using a
> > `list' argument name.
>
> This is interesting. Other than Lisp-1 vs 2 and the hygienic macro
> system (which I happen to dislike), I didn't think Lisp and Scheme
> had different natures.
They are very different (languages and cultures). A good indicator
for the difference is that in CL people prefer `symbols' whereas in
Scheme `identifier' is a bit more common.
> If you admit that they do, then the "Scheme is good for teaching,
> not real applications" is only a step away :)
Not at all -- I also admit that C and CL have very different natures,
but that does not imply that I think that "C is good for teaching, not
for real applications". (And I certainly doing tons of "real
applications" in Scheme.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44sfcvF3c1ovU1@individual.net>
·······@gmail.com wrote:
> The point, I believe, was that, in PLT Scheme at least, you *do* get
> multiple values, a package system, arrays, hashtables, structures etc
> --things that where listed as a CL advantage in Alex's post.
- Multiple values in Scheme have slightly different semantics than in
Common Lisp. Note that he said "sane way" in this context when he
referred to multiple values in Common Lisp. (Or does PLT Scheme deviate
here from R5RS?)
- I don't know of any Scheme that provides a CL-style package system.
Many provide module systems, however.
There are also other differences in details for the same general features.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
<········@yahoo.com> wrote:
+---------------
| What am I missing by using Scheme (and Scheme web frameworks in
| particular) instead of Lisp? I could easily point out what people
| miss by using Lisp instead of Scheme: continuations.
+---------------
Actually, despite the excellent papers by Queinnec, and by
Felleisen et al, when it comes to web applications having
Scheme-style continuations turns out *not* to really be a
significant advantage after all!!
Yes, it is extremely important when designing a web app to *think*
in terms of the user's "Submit" of a form as calling a continuation
in the server -- it helps a lot with keeping the behavior sane from
the user's point of view, especially when the user has multiple
browser windows open to different pages within the app[1] -- but you
don't need a "real" continuation in the server to do that, only a
function that handles "the next transition" of the state machine
you're implementing. But you don't need "real" continuations in
the web app to derive the benefit from this way of thinking.
In fact, the big *problem* that arises when using real Scheme-style
continuations in web apps [seldom discussed by their advocates, or
quickly glossed over] is that keeping real continuations around
chews up memory, a finite resource, and to avoid (possibly even
inadvertant) DoS attacks you have to have some kind of "expiration"
and/or "GC" of the outstanding continuations, which puts you right
back in the same problem of needing a state-transition function to
call if the continuation has "timed out".
IME, the correct solution is to: (1) do your initial design *as if*
you were using real continuations; but then, (2) CPS-transform the
design[2] into a state machine with input-value-carrying transitions
[and once you have done this, CL works as well as Scheme]; (3) choose
an externalizable representation for the states and the permitted
transitions [that is, the CPS'd "continuations"]; then either
(4a) store the "continuation" in the web page delivered to the user
(encrypted and authenticated as much as necessary to prevent spoofing
and/or replay attacks), or (4b) store the "continuation" in a real
database, but recognize the need to perform "GC" on the stored
"continuations", with the inevitable upset that will cause to a
few users when their form "times out".
I tend to use "4a", but YMMV.
-Rob
[1] Queinnec, and to a lesser extent Felleisen et al, shows in
detail why this almost certainly means you must *NOT* use cookies!!
[Hint: Cookies are per-browser, not per page displayed.]
[2] Either formally/automagically or informally/manually. I have
found in my CL-based web apps that the latter is not particularly
difficult or error-prone.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> IME, the correct solution is to: (1) do your initial design *as if*
> you were using real continuations; but then, (2) CPS-transform the
> design[2] into a state machine with input-value-carrying transitions
> [and once you have done this, CL works as well as Scheme]; (3) choose
> an externalizable representation for the states and the permitted
> transitions [that is, the CPS'd "continuations"]; then either
> (4a) store the "continuation" in the web page delivered to the user
> (encrypted and authenticated as much as necessary to prevent spoofing
> and/or replay attacks), or (4b) store the "continuation" in a real
> database, but recognize the need to perform "GC" on the stored
> "continuations", with the inevitable upset that will cause to a
> few users when their form "times out".
This sounds to me like REST, which I happen to think is the right way
to do web programming. Declarative mechanisms for building your state
back up from the input help a lot (I use Cells for this).
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> IME, the correct solution is to: (1) do your initial design *as if*
>> you were using real continuations; but then, (2) CPS-transform the
>> design[2] into a state machine with input-value-carrying transitions
>> [and once you have done this, CL works as well as Scheme]; (3) choose
>> an externalizable representation for the states and the permitted
>> transitions [that is, the CPS'd "continuations"]; then either
>> (4a) store the "continuation" in the web page delivered to the user
>> (encrypted and authenticated as much as necessary to prevent spoofing
>> and/or replay attacks), or (4b) store the "continuation" in a real
>> database, but recognize the need to perform "GC" on the stored
>> "continuations", with the inevitable upset that will cause to a
>> few users when their form "times out".
>
> This sounds to me like REST, which I happen to think is the right way
> to do web programming. Declarative mechanisms for building your state
> back up from the input help a lot (I use Cells for this).
Depends on how 4a is implemented--it could end up with EvilURLs[1], which
are IIRC quite undesirable with REST. If implemented with cookies, then
EvilURLs can be avoided, although it does mean that the user can't be
logged in as one person in one browser tab and as another in another.
This is not IMHO a very big problem.
Also, certain types of replay-prevention and spoofing-prevention can
kill REST as well, unfortunately. But yes, it does sound a lot like the
basic idea behind REST.
[1] e.g. http://www.example.com/0032ab0076e28343c32432/
--
Robert Uhl <http://public.xdi.org/=ruhl>
As convenient as it is for information to come to us, libraries do have a
valuable side effect: they force all of the smart people to come together
in one place where they can interact with one another.
--Neal Stephenson
Robert Uhl wrote:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> Rob Warnock:
>
>>>(4a) store the "continuation" in the web page delivered to the user
>>>(encrypted and authenticated as much as necessary to prevent spoofing
>>>and/or replay attacks), or (4b) store the "continuation" in a real
>>>database, but recognize the need to perform "GC" on the stored
>>>"continuations", with the inevitable upset that will cause to a
>>>few users when their form "times out".
>>
>>This sounds to me like REST, which I happen to think is the right way
>>to do web programming. Declarative mechanisms for building your state
>>back up from the input help a lot (I use Cells for this).
>
>
> Depends on how 4a is implemented--it could end up with EvilURLs[1], which
> are IIRC quite undesirable with REST. If implemented with cookies, then
> EvilURLs can be avoided, although it does mean that the user can't be
> logged in as one person in one browser tab and as another in another.
> This is not IMHO a very big problem.
> [1] e.g. http://www.example.com/0032ab0076e28343c32432/
I'm not up on the latest, not being a pro web programmer. Is there
really a consensus that cookies are preferable to opaque URLs? First,
there's all those users who ignore or complain about them. There's the
"two sessions" problem you mention, which I believe is worse than merely
circumventing one user masquerading as two -- it locks the user into a
linear paradigm which, much as the marketing folks behind many websites
might love it, is unnatural for the web. Also, if state is encoded in
the URL, one person can get the web app to an interesting place, then
communicate the URL to someone else, who gets to the same place. This
beats the heck out of "click on x, now click on y over at the left, now
select the third item and click 'details'..." Summary: Opaque URLs suck
and cookies suck, but I suspect opaque URLs suck less.
When I read about CPS web programming, it immediately clicked as a
superior way to model interaction, but I also thought "and who's going
to garbage collect all those continuations?" so it was good to see Rob
Warnock point out that this is often elided.
Anyway, is there a good, concise yet technical web page on REST
somewhere? It's a tough term to Google and, though I did find a
reference to... Nevermind, I found a non-404 to the dissertation that
started it all from
http://www.findinglisp.com/blog/2004/11/web-application-design-rest-of-story.html
It's good to see all this action in web frameworks -- the plethora that
seems to be developing is staggering. There must be an awful lot of
sites with Lisp back ends out there.
Cameron MacKinnon <··········@clearspot.net> writes:
> Robert Uhl wrote:
> > ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > Rob Warnock:
> >
> >>>(4a) store the "continuation" in the web page delivered to the user
> >>>(encrypted and authenticated as much as necessary to prevent spoofing
> >>>and/or replay attacks), or (4b) store the "continuation" in a real
> >>>database, but recognize the need to perform "GC" on the stored
> >>>"continuations", with the inevitable upset that will cause to a
> >>>few users when their form "times out".
> >>
> >>This sounds to me like REST, which I happen to think is the right way
> >>to do web programming. Declarative mechanisms for building your state
> >>back up from the input help a lot (I use Cells for this).
> > Depends on how 4a is implemented--it could end up with EvilURLs[1],
> > which
> > are IIRC quite undesirable with REST. If implemented with cookies, then
> > EvilURLs can be avoided, although it does mean that the user can't be
> > logged in as one person in one browser tab and as another in another.
> > This is not IMHO a very big problem.
>
> > [1] e.g. http://www.example.com/0032ab0076e28343c32432/
>
> I'm not up on the latest, not being a pro web programmer. Is there
> really a consensus that cookies are preferable to opaque URLs? First,
> there's all those users who ignore or complain about them. There's the
> "two sessions" problem you mention, which I believe is worse than
> merely circumventing one user masquerading as two -- it locks the user
> into a linear paradigm which, much as the marketing folks behind many
> websites might love it, is unnatural for the web. Also, if state is
> encoded in the URL, one person can get the web app to an interesting
> place, then communicate the URL to someone else, who gets to the same
> place. This beats the heck out of "click on x, now click on y over at
> the left, now select the third item and click 'details'..." Summary:
> Opaque URLs suck and cookies suck, but I suspect opaque URLs suck less.
But, if you put the auth information non-obviously in the URL you
can't e-mail links. Yuck. Personally, I think the way to do it is to
pass the user name/id as a parameter, either hidden in a POST or
obviously with GET (eg, http://example.com/widgets/73/reviews?user=bob).
The password part can be kept in a cookie without the typical problems
associated with auth info in cookies. Unfortunately, there is nothing
even close to a consensus on how to do this. Nowadays, the number of
users who complain about cookies is miniscule enough to ignore (for
most purposes).
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > [rpw3 wrote:]
| >> IME, the correct solution is to: (1) do your initial design *as if*
| >> you were using real continuations; but then, (2) CPS-transform the
| >> design[2] into a state machine with input-value-carrying transitions
| >> [and once you have done this, CL works as well as Scheme]; (3) choose
| >> an externalizable representation for the states and the permitted
| >> transitions [that is, the CPS'd "continuations"]; then either
| >> (4a) store the "continuation" in the web page delivered to the user
| >> (encrypted and authenticated as much as necessary to prevent spoofing
| >> and/or replay attacks), or (4b) store the "continuation" in a real
| >> database, but recognize the need to perform "GC" on the stored
| >> "continuations", with the inevitable upset that will cause to a
| >> few users when their form "times out".
| >
| > This sounds to me like REST, which I happen to think is the right way
| > to do web programming. Declarative mechanisms for building your state
| > back up from the input help a lot (I use Cells for this).
|
| Depends on how 4a is implemented--it could end up with EvilURLs[1]...
+---------------
Not necessarily. If one uses POST operations with <INPUT TYPE='hidden'>
fields to hold the encoded state, the URL stays small -- in fact, for
the production apps I've written, the URL is generally *constant*!!
[Yes, this means that if the user wants to save the state of their
interaction and come back to it days later they need to save the
displayed *page*, and then fetch it off their local disk later.
The disadvantages of this are IMHO less than the disadvantages
of the alternatives.]
+---------------
| If implemented with cookies, then EvilURLs can be avoided, although it
| does mean that the user can't be logged in as one person in one browser
| tab and as another in another. This is not IMHO a very big problem.
+---------------
Maybe not to you, but I and many others I've talked to think it's
a *HUGE* problem, since it prohibits the user from making stateless
forays into the various alteratives of the web space without prematurely
committing themselves irrevocably.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Thomas F. Burdick wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
> > IME, the correct solution is to: (1) do your initial design *as if*
> > you were using real continuations; but then, (2) CPS-transform the
> > design[2] into a state machine with input-value-carrying transitions
> > [and once you have done this, CL works as well as Scheme]; (3) choose
> > an externalizable representation for the states and the permitted
> > transitions [that is, the CPS'd "continuations"]; then either
> > (4a) store the "continuation" in the web page delivered to the user
> > (encrypted and authenticated as much as necessary to prevent spoofing
> > and/or replay attacks), or (4b) store the "continuation" in a real
> > database, but recognize the need to perform "GC" on the stored
> > "continuations", with the inevitable upset that will cause to a
> > few users when their form "times out".
>
> This sounds to me like REST, which I happen to think is the right way
> to do web programming. Declarative mechanisms for building your state
> back up from the input help a lot (I use Cells for this).
It is actually the opposite or `dual' of REST. REST is all about
keeping your state together in one place so that you don't end up with
multiple inconsistent copies. The `web continuation' approach is about
writing code that doesn't *have* state in the first place.
Of course the continuation approach ends up reifying the implicit state
and passing it around, so you end up at the same spot. The difference
is where you start: with REST, you start by attempting to enumerate
and gather all the state, with continuations, you start by ignoring the
state and letting the computer figure it out.
Incidentally, the paper I co-wrote with Greg Pettyjohn, John Clements,
Shriram Krishnamurthi and Matthias Felleisen discusses how to reify the
continuation without wholesale CPS conversion of the program. (The
bizarre co-incidence is that Greg's approach to reifying a web
continuation is semantically equivalent to my approach of extracting a
continuation from the .NET machine using exceptions.)
"Joe Marshall" <··········@gmail.com> writes:
> Thomas F. Burdick wrote:
> > ····@rpw3.org (Rob Warnock) writes:
> >
> > > IME, the correct solution is to: (1) do your initial design *as if*
> > > you were using real continuations; but then, (2) CPS-transform the
> > > design[2] into a state machine with input-value-carrying transitions
> > > [and once you have done this, CL works as well as Scheme]; (3) choose
> > > an externalizable representation for the states and the permitted
> > > transitions [that is, the CPS'd "continuations"]; then either
> > > (4a) store the "continuation" in the web page delivered to the user
> > > (encrypted and authenticated as much as necessary to prevent spoofing
> > > and/or replay attacks), or (4b) store the "continuation" in a real
> > > database, but recognize the need to perform "GC" on the stored
> > > "continuations", with the inevitable upset that will cause to a
> > > few users when their form "times out".
> >
> > This sounds to me like REST, which I happen to think is the right way
> > to do web programming. Declarative mechanisms for building your state
> > back up from the input help a lot (I use Cells for this).
>
> It is actually the opposite or `dual' of REST. REST is all about
> keeping your state together in one place so that you don't end up with
> multiple inconsistent copies. The `web continuation' approach is about
> writing code that doesn't *have* state in the first place.
Continuations servers are definately the inverse of REST, but what Rob
described was designing your app as though it used continuations, then
CPS transforming the design, not the code. That was my approach to
doing REST, although I could see how you could end out with something
very much un-RESTy through a similar process.
> Of course the continuation approach ends up reifying the implicit state
> and passing it around, so you end up at the same spot. The difference
> is where you start: with REST, you start by attempting to enumerate
> and gather all the state, with continuations, you start by ignoring the
> state and letting the computer figure it out.
You can automate the process of enumerating the state, too.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
+---------------
| "Joe Marshall" <··········@gmail.com> writes:
| > It is actually the opposite or `dual' of REST. REST is all about
| > keeping your state together in one place so that you don't end up with
| > multiple inconsistent copies. The `web continuation' approach is about
| > writing code that doesn't *have* state in the first place.
|
| Continuations servers are definately the inverse of REST, but what Rob
| described was designing your app as though it used continuations, then
| CPS transforming the design, not the code.
+---------------
Yes, that's what I was trying to say, that (to me) the web continuation
approach is much more useful as a pattern[1] than as some fully-automatic
infrastructure or library.
-Rob
[1] In the RPG/Alexander sense, not the GoF sense.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ulrich Hobelmann
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <450mnfF4cjj8U1@individual.net>
Thomas F. Burdick wrote:
> Continuations servers are definately the inverse of REST, but what Rob
> described was designing your app as though it used continuations, then
> CPS transforming the design, not the code. That was my approach to
> doing REST, although I could see how you could end out with something
> very much un-RESTy through a similar process.
I wouldn't call them inverse. REST is about structuring data, and
keeping it consistent, while continuations are about control flow
between pages. OTOH it's hard to combine them, since a given URL can
only be either a REST page, or a continuation...
--
Suffering from Gates-induced brain leakage...
From: Pascal Costanza
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44qtvbF38gpeU1@individual.net>
····@unreal.uncom wrote:
> On Mon, 06 Feb 2006 22:50:47 +0000, Christophe Rhodes
> <·····@cam.ac.uk> wrote:
>
>>contains a log of the discussion, in case anyone wishes to draw their
>>own conclusions.
>
> Scheme vs CL vs whatever, is an issue worth periodic discussion.
> Where is the best place for such discussions?
We had Scheme / CL comparisons quite a few times here in c.l.l, and in
my experience this works typically quite well, at least in recent times.
A comparison along the lines of "can you compare this library in
language XYZ against that library in CL" should also pose no serious
problems.
However, "this library in language XYZ has a better documentation than
that library in CL, so XYZ must be the better language" is nonsense.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
····@unreal.uncom writes:
> On Mon, 06 Feb 2006 22:50:47 +0000, Christophe Rhodes
> <·····@cam.ac.uk> wrote:
>
>>contains a log of the discussion, in case anyone wishes to draw their
>>own conclusions.
>
> Scheme vs CL vs whatever, is an issue worth periodic discussion.
> Where is the best place for such discussions? It should be an obvious
> place, so people who want to participate in such discussions will know
> where to look for them. And/or maybe some kind of autoresponder could
> be installed in places where such discussions aren't wanted, which
> would automatically respond to such discussions with directions to the
> correct place for them.
Actually, there is no such place. The problem being that every one
has his own requisites, and must choose for himself. You can only ask
language-specific question on each language forum and draw YOURSELF
your OWN conclusions.
You could try to create:
news:alt.comp.language-comparison.cl-vs-scheme
news:alt.comp.language-comparison.pascal-vs-c
news:alt.comp.language-comparison.ada-vs-eiffel
or:
irc://irc.freenode.org/#cl-vs-scheme
irc://irc.freenode.org/#pascal-vs-c
irc://irc.freenode.org/#ada-vs-eiffel
Have fun!
> Kicking people off a forum without plenty of clear warning seems rude.
> Warnings that may seem clear to locals aren't clear to newbies. The
> warning should say explicitly that if he continues to discuss the
> particular topic he will be banned. You can't assume that a person
> with an unwanted topic is never going to have any wanted topics.
Yes, Xophe clearly has a problem, but it's not too bad to have a
slightly psychotic dictator to run the place. Usually, if you come
back and change your attitude, he doesn't kick you twice in a row.
--
__Pascal Bourguignon__ http://www.informatimago.com/
What is this talk of 'release'? Klingons do not make software 'releases'.
Our software 'escapes' leaving a bloody trail of designers and quality
assurance people in it's wake.
From: Ulrich Hobelmann
Subject: Re: Cross-lisp questions and my #lisp experience
Date:
Message-ID: <44r3naF3gv6nU2@individual.net>
Christophe Rhodes wrote:
> ········@yahoo.com writes:
>
>> So today, I worked my courage up, posted a big disclaimer, and asked
>> the folks on #lisp about Scheme vs Lisp, especially as it relates to
>> webapp frameworks. I got banned within 5 minutes (thanks Xophe !).
>
> <http://meme.b9.com/cview.html?channel=lisp&start=3348251388&end=3348252232>
> contains a log of the discussion, in case anyone wishes to draw their
> own conclusions.
To me it *does* look as if you guys overreacted a bit. Not everyone who
doesn't worship Lisp out of the box is a troll, seriously.
--
Suffering from Gates-induced brain leakage...
········@yahoo.com wrote:
> Summary: I have recently tried to inquire about Common Lisp web
> frameworks vs Scheme web frameworks on #lisp (I know, it smells like a
> flamebait, but I really didn't mean that). This post is a summary of my
> experiences, as well as a restatement of my questions.
>
> I originally learned Lisp at age 10 (about 20 years ago), used it in
> college (about 10 years ago) ant only returned to it about a year ago
> due to Paul Graham's recent advocacy. Naturally, I figured that the
> best hacker real estate is in web programming because this is the only
> way to escape the long shadow of C/C++/Java. I settled on Scheme after
> seeing that it has built-in continuations, and at least one
> well-documented framework. I am currently working on web applications,
> using a Scheme framework (SISCweb, if anyone cares).
>
> Before settling on Scheme, I have tried to learn UCW, but found the
> lack of detailed documentation troubling (no, I haven't seen the recent
> 50-meg video). However, I feel bad about choosing a language based
> mostly on the documentation volume.
>
> So today, I worked my courage up, posted a big disclaimer, and asked
> the folks on #lisp about Scheme vs Lisp, especially as it relates to
> webapp frameworks. I got banned within 5 minutes (thanks Xophe !) and
> never really learned much, other than being pointed to SBCL (which, as
> far as I can tell, is a CMUCL fork that still has threading and Mac OSX
> bugs).
>
> So, to anyone who has looked at both CL and Scheme recently: are there
> any well-documented, thread-safe, more-featureful-than-Scheme CL web
> frameworks? And please don't label me a troll again; occasionally,
> cross-language, cross-newsgroup concerns are valid issues.
I saw a recent mention that UCW was turning into a bit of a consensus
favorite. Looks like the #lisp crowd is a little touchy. I think there
would not have been a problem if someone somewhere had simply said,
"Yeah, understood about the doc, just fire it up and if you have
problems ask here or on c.l.l".
In an ideal world you would have super doc (uh, I should emphasize here
that I have no idea on Earth how good is UCW's doc), but with Lisp one
tends more to get really fast really good responses to tech problems on
c.l.l (and maybe other forums).
Your mistake was embedding flamebait in a technical question. No, the
disclaimer does not change that -- it draws flies, right? The correct
thing for you to have done when writing the disclaimer would been to
realize that, had you excised the Scheme bit, you would not have to
write a disclaimer. Then your exchange would have gone like this.
p_frici: What frameworks are recommended for CL Web apps?
#Lisp: UCW
p_frici: OK. Tried it. Doc sucks.
#Lisp: Word. But UCW rocks. You'll get good UCW support <here>
p_frici: OK, once more into the breach. Thx.
Btw, you are free to conclude that Scheme is better, but make that
decision for yourself, not out loud in a crowd of touchy Lisp yobs.
:)
kenny
Kenny, you're right. I really didn't mean my topic to become
"adversarial" or anything, but I guess my limited IRC experience has
showed :)
I was just wondering if perhaps Lisp frameworks posess some
expressiveness that I haven't noticed. In other words, I'm trying to
make sure I'm not to missing out on any innovation.
-- Dan
········@yahoo.com wrote:
> Kenny, you're right. I really didn't mean my topic to become
> "adversarial" or anything, but I guess my limited IRC experience has
> showed :)
#lisp is not really about Lisp, but more like a chat room for SBCL
fanboys. Of course they'll suggest you look at SBCL, duh. And it's
understandable that they are a little bit touchy after that Reddit
fiasco^Waffair.