It is mot my fault that you expose your ignorance and your arrogance about what you do not understand. You are one of those who think they have nothing more to learn and instead spend your time blaming what you have not studied for the fact that you do not understand it properly.
It has been obvious for quite a while that you are here only to talk, not to listen, not to learn, not to appreciate contrary opinions and views. I suggest that you retreat to your Scheme world and enjoy yourself instead of wasting your time here, being as you are the one to suggest that people go away.
You are making a problem look much harder than it is because you have failed to understand it. It behooves a critic to be well educated. You are not in the topic at hand. Maybe you are so "educated" in other things you actually believe you do not have to know specifics, anymore, but then that is the problem in this debate, not the issues at hand.
Just write the macros that produce the effects you want. Publish them. It is actually that is. The fact that you can is the strength of the Common Lisp macro system. The fact that you _cannot_ do this in a syntactic closures system is a weakness of that system. The fact that you might have to is not a blemish or a weakness of a language that was expressly designed to let people build their own tools within it. If you want a language that _enforces_ what you think is right, that language is not Common Lisp, and the community you should talk to is not the Common Lisp community.
> "Marco Antoniotti" <marc...@cs.nyu.edu> wrote in message > news:y6c1yow9y4u.fsf@octagon.mrl.nyu.edu... > > Of course in Scheme you have to "fight the (impoverished) system" > > much much more than in CL, just to make it usable as a whole.
> Well, if you stick to the standard, it is not so much fighting as > simply being unable to. (O.K., CPS style macros might be considered > fighting the system, but then CPS is popular in Scheme circles..)
> Fortunately virtually every implementation goes well beyond the > standard, but it is a shame that decent macros are often necessarily > unportable.
> I think that is inherent in the different approaches: CL wants something that > works, and wants it now, and Scheme wants the right thing or nothing > - and often that is nothing.
Excellent point. Although I'd go as far as saying, that most of the time, what works (in CL) also happens to be "the rigth thing".
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
> If you had bothered to try to read what I > wrote, you would have understood that I don't have the least problem > expressing what I want to express ...
Then again, maybe you do want to deal with it...
When people express themselves, there are two possible motivations for doing so. One is emotion - when people emote, they don't care about others hearing what they have to say, but the goal is in the expression itself. For example, artists must be able to express themselves freely without necessarily having to communicate. Complainers also express themselves without communicating.
The second aspect of expression _is_ communication. Communication has both a sender and a receiver of information. Those who express themselves well in this sense have a good idea as to how their listeners are receiving what they have to say.
Now, the first part of the second sentence above tells me that you don't want to just spout off, but that you want people to understand what you say. However, I contend that you are not necessarily doing that well. And the fault may be ours completely, because of our point-of-view, but let's take an example of how you should try to listen to yourself from my point of view if you want me to understand you:
You give your web address as http://www.biep.org/. However, when I tried to get to your website in my netscape, I got an error: "This Virtual Directory does not allow contents to be listed." Now, I don't know what the problem is, here; it may be a problem entirely on my end. However, I never have any trouble getting anywhere else on the web, and so your site is particular in at least one sense. Perhaps your site is just busy, or perhaps you have never tested it using Netscape on a unix box. However, this just illustrates the points Erik and Marco were trying to make:
If we disagree on the usage of macro writing, perhaps it is because there is a disconnect between what you are saying and what we are hearing. Many of the things that Erik specifically mentioned communicated to me that he had indeed read and understood what you were saying, and if these understandings were not what you were trying to say, then you must find a way to close the communication gap if you want people to understand you.
I suggest that you go back over Erik's post and respond point-by-point, correcting any mistaken assumptions that he might have made. Bear in mind, that I had the same assumptions that he did, and would have responded to at least a couple of your points in similar manner. For example, the fact that the CL community does not care to continue developing their macro system and the scheme community does, suggests to me that the scheme community is dissatisfied with their macro system, whereas the CL community is satisfied with theirs.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
On Thu, 7 Jun 2001, Biep @ http://www.biep.org/ wrote: > "F. Xavier Noria" <f...@isoco.com> wrote in message > news:3b0370ef.1598314@news.iddeo.es... > > I asked in comp.lang.perl.misc whether anyone had considered > > to use closures to store session state in web applications > > as Paul Graham explains in the continuation of > > "Beating the Averages".
Graham's session-state-as-closures technique is a cool hack, but I wonder how scalable it is. It forces a remote user to be served by the same Lisp image (on the same machine, obviously) on every transaction. While it's desirable to do that for caching reasons, etc., it's not great to rely on that mode of operation: load balancing, hardware failure, and network problems/instability, to name a few factors, all conspire against it.
Tim Moore <mo...@herschel.bricoworks.com> writes: > On Thu, 7 Jun 2001, Biep @ http://www.biep.org/ wrote:
> > "F. Xavier Noria" <f...@isoco.com> wrote in message > > news:3b0370ef.1598314@news.iddeo.es... > > > I asked in comp.lang.perl.misc whether anyone had considered > > > to use closures to store session state in web applications > > > as Paul Graham explains in the continuation of > > > "Beating the Averages".
> Graham's session-state-as-closures technique is a cool hack, but I wonder > how scalable it is. It forces a remote user to be served by the same > Lisp image (on the same machine, obviously) on every transaction. While > it's desirable to do that for caching reasons, etc., it's not great to > rely on that mode of operation: load balancing, hardware failure, > and network problems/instability, to name a few factors, all conspire > against it.
While these would make slight problems, I think he was trying to make the client-server connection seem (from the point of view of the programmer writing the application logic) like a continuous connection for the term of the interaction: something most of us want to do when writing web apps. Load balancing could occur on a per-session, rather than a per-http-request basis. I don't think you'll lose much, at least on large systems. Hardware and network failure hopefully occur infrequently enough that this won't happen during the course of a given session. Otherwise you've got bigger problems.
> (with-open-file (biep "ears" :direction :input) > (write "Quit Being A Troll!" :stream biep) > (flush-output biep))
Nice said ;-) But Biep will hear more if we use :output as :direction. The standpoint taken in CLs notion of "direction" is the Lisp System not the file. So "input" means "The Lisp System gets input from a file" and "output" means "The Lisp System outputs to a file"
Duane Rettig <du...@franz.com> writes: > [context elided. see prior posts if that matters to you.]
> For example, the fact that the CL community does not care to > continue developing their macro system and the scheme community > does, suggests to me that the scheme community is dissatisfied with > their macro system, whereas the CL community is satisfied with > theirs.
I think this is a good point.
I think the Scheme community is puzzled by the fact that CL doesn't have a hygienic macro system and yet doesn't run into all kinds of problems as a result. Usually this kind of "surprise" comes from momentarily making the mistake of assuming that the conversation can usefully proceed by idealizing the differences between the two languages as being "only this" and assuming that what keeps the conversation focused will not leave out critical information that makes the conversation meaningful. It is impossible to have a conversation about macros without a conversation on namespaces and packages (and "hygiene" is as much about those other two issues as it is about macros). Yet they mostly forget to bring them into play when looking at our macro system. We in CL rely on the Lisp2ness and on the package system to protect us from name conflicts, and in practice, it does. To my knowledge, having worked at several Lisp vendors and having used CL now about 2 decades years, people who know what they are doing reliably do not run into any problems with name collisions in CL. The problem just doesn't come up. The ecology works.
I guess my point is that Duane is not just speculating when he says "suggests to me that...". There's pretty extensive experience with myriad users and multiple implementors over a really long time (in "contemporary programming language use" terms) to suggest that the reason no one is "evolving" the CL macro system is that it works just fine.
In fact, historically, the biggest boom in Lisp productivity and expansion that I've ever seen occur was around the time that people discovered the creation and exchange of "cool macros". Lots of macro packages were offered by the system and by users, and, by all accounts, productivity AND program reliability went way up because tedious idiomatic uses didn't have to be painstakingly repeated any more, at risk that people would find the longhand versions too painful to do in full form or that they would make a mistake in adjusting them for context. Macros changed the Lisp world, very much for the better. And since that time, I've heard no regrets and no "gee, this is getting out of hand". Rather, I've heard people continuing to be amazed by how many layers you can create of macro on macro and still get utterly reliable outcomes.
<reply-...@my-web-site.com> wrote: > (http://www.brabandt.de/html/jargon_49.html). I think the very fact that > there are macro gurus indicates that there is a problem: the basic notion
So what? In all human activities there are both novices and gurus.
Tim Moore <mo...@herschel.bricoworks.com> writes: > Lisp image (on the same machine, obviously) on every transaction. While > it's desirable to do that for caching reasons, etc., it's not great to > rely on that mode of operation: load balancing, hardware failure, > and network problems/instability, to name a few factors, all conspire > against it.
I don't agree. You should trust your hardware, network etc. enough to be able to assume that each component can serve the same user through a session.
And I think layer 4 switches like Foundry Server Iron solve the load balancing issue for you. -- (espen)
(close biep) ; since it was not cleaned up (setf biep (open "ears" :direction :output)) (write "Quit Being A Troll!" :stream biep) (flush-output biep) (close biep)
Or with the macro
(with-open-file (biep "ears" :direction :output) (write "Quit Being A Troll!" :stream biep) (flush-output biep))
But I think I really should have created a new macro like
(with-persons-aural-attention (biep :uri "http://www.biep.org") (tell biep "Quit Being A Troll!"))
or
(biep! Quit Being A Troll!)
or
(biep!!!!!!!)
After all thats what macros are for.
Wade
"Jochen Schmidt" <j...@dataheaven.de> wrote in message
> > (with-open-file (biep "ears" :direction :input) > > (write "Quit Being A Troll!" :stream biep) > > (flush-output biep))
> Nice said ;-) > But Biep will hear more if we use :output as :direction. > The standpoint taken in CLs notion of "direction" is the Lisp System not > the file. So "input" means "The Lisp System gets input from a file" > and "output" means "The Lisp System outputs to a file"
> Tim Moore <mo...@herschel.bricoworks.com> writes:
> > Lisp image (on the same machine, obviously) on every transaction. While > > it's desirable to do that for caching reasons, etc., it's not great to > > rely on that mode of operation: load balancing, hardware failure, > > and network problems/instability, to name a few factors, all conspire > > against it.
> I don't agree. You should trust your hardware, network etc. enough to > be able to assume that each component can serve the same user through a > session.
Large websites are complex systems. You can't assume this unless you build a great deal of redundancy into the system or you don't care that much if session data is lost.
> And I think layer 4 switches like Foundry Server Iron solve the load > balancing issue for you.
I think you mean "solve the combination of load balancing and session affinity" as you can obviously solve load balancing and break session affinity. Yes, the features of that switch look like they might do the trick, assuming you're willing to work within the constraints of their URL and cookie parsing support and also assuming you're willing to put up with a single point of failure.
I don't want to overstate my "argument": store building, even at Yahoo!, is not a high volume application and may work fine on a single machine. Losing intra-page transitions is probably not a huge deal. And I like the idea of using closures for this application. But I still don't think it scales well.
>>>>> "TM" == Tim Moore <mo...@herschel.bricoworks.com> writes:
TM> [...] Yes, the features of that switch TM> look like they might do the trick, assuming you're willing to TM> work within the constraints of their URL and cookie parsing TM> support and also assuming you're willing to put up with a TM> single point of failure.
My understanding is that you need to store the session context somewhere anyway, closures or not. If you want to avoid the single point of failure sitting in frot of your server farm, one alternative might be to decouple your session context storage from the web server and move it to the back-end. You still need some replication and auto failover somewhere to satisfy the no single point of failure constraint. Then the issue becomes whether closures can still the used under this scheme, and I suspect, for practical purposes, it would be too much pain to get "persistent" closures. I would be thrilled to see an elegant solution to this though.
TM> I don't want to overstate my "argument": store building, even TM> at Yahoo!, is not a high volume application and may work fine TM> on a single machine.
You don't need a single machine or even the fancy switch, your front end web servers can possibly do the right thing if you solve the session-id to lisp image mapping problem in a robust way (possibly via the same mechanism above).
TM> Losing intra-page transitions is TM> probably not a huge deal.
I agree, for this to hurt you the likelihood of the lisp server machine going down while the user has an active session has to be appreciable. Outside of that, any particular machine doing down does not hurt you.
Tim Moore <mo...@herschel.bricoworks.com> writes: > ... I like the idea of using closures for this application. But I > still don't think it scales well.
Where is this technique discussed? I'd like to peek in at it and compare notes. If I understand you correctly, I've used this technique myself, effectively giving continuation closures a handle and then having the session call back looking for a continuation by name. If you assume one-time reuse and timeout, it works pretty well. If you can re-visit the same continuation more than once or if you can't GC them, it's a problem.
I don't see what the issue is with "scaling", though I can imagine we might be talking slightly at crossed purposes. When I say "closures" I don't mean literally (lambda ...) closures [at least not without a little additional programming work, which I think *could* be done] but rather the general concept. Could you maybe elaborate on the scaling problems you see so I can try to see if I'm just missing something obvious?
I may be available to consult on this if someone has a real application that needs this and needs help working out the syntax details... ;-) [Such discussion should go through email, though, not newsgroup.]
> effectively giving continuation closures a handle and then having the session > call back looking for a continuation by name. If you assume one-time > reuse and timeout, it works pretty well. If you can re-visit the same > continuation more than once or if you can't GC them, it's a problem.
> I don't see what the issue is with "scaling", though I can imagine we might > be talking slightly at crossed purposes. When I say "closures" I don't > mean literally (lambda ...) closures [at least not without a little additional > programming work, which I think *could* be done] but rather the general > concept. Could you maybe elaborate on the scaling problems you see so I can > try to see if I'm just missing something obvious?
Graham does seem to be using real closures. My scaling concerns, as I've written in other articles, have to do with requiring sessions to always return to the same machine.
Keeping some kind of server-side state around for sessions, usually in a relational database, is common enough for those who've tried to jam session state into hidden form fields and such.
> I may be available to consult on this if someone has a real application > that needs this and needs help working out the syntax details... ;-) > [Such discussion should go through email, though, not newsgroup.]
> I may be available to consult on this if someone has a real application > that needs this and needs help working out the syntax details... ;-) > [Such discussion should go through email, though, not newsgroup.]
Might I suggest the lispweb mailing list as a forum for such discussion.
Kent M Pitman <pit...@world.std.com> wrote: +--------------- | Duane Rettig <du...@franz.com> writes: | > For example, the fact that the CL community does not care to | > continue developing their macro system and the scheme community | > does, suggests to me that the scheme community is dissatisfied with | > their macro system, whereas the CL community is satisfied with theirs. | | I think this is a good point. | | I think the Scheme community is puzzled by the fact that CL doesn't | have a hygienic macro system and yet doesn't run into all kinds of | problems as a result. +---------------
Confession: I happen to program in both CL & Scheme and, as it happens, when I write macros in Scheme I always use "defmacro", since it does the (to me) obvious & correct thing. [Hygiene? See "gensym".]
+--------------- | There's pretty extensive experience with myriad users and multiple | implementors over a really long time (in "contemporary programming | language use" terms) to suggest that the reason no one is "evolving" | the CL macro system is that it works just fine. +---------------
That's why I've never bothered to learn R5RS macros, even though they're "standard" and defmacro isn't. The latter is all I need; I understand what it does; and all of the implementations of Scheme I use (and of course, all of the CLs) have it (or something equivalent from which it can be trivially defined).
-Rob
p.s. It may help that I use to code some *incredibly* complex things in MACRO-10 (the PDP-10 assembly language) macros way back when... ;-} It didn't have "gensym" per se -- you had to manually construct your own unique macro temp symbols by concatenating assembly-time counters and local prefixes & suffixes & the like. But now that I think about it, one could have easily written "gensym" *in* MACRO-10 macros! (I just never would have called it that, since I hadn't been exposed to Lisp yet.)
> Where is this technique discussed? I'd like to peek in at it and compare > notes. If I understand you correctly, I've used this technique myself, > effectively giving continuation closures a handle and then having the session > call back looking for a continuation by name. If you assume one-time > reuse and timeout, it works pretty well. If you can re-visit the same > continuation more than once or if you can't GC them, it's a problem.
Earlier I gave this pointer: http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz; I am not sure that answers your question, but it does discuss re-entrance, which is interent in the WWW model: people can always return to pages they have visited before.
>>>>> On 8 Jun 2001 04:25:01 GMT, Rob Warnock ("Rob") writes:
Rob> p.s. It may help that I use to code some *incredibly* complex things Rob> in MACRO-10 (the PDP-10 assembly language) macros way back when... ;-} Rob> It didn't have "gensym" per se -- you had to manually construct your Rob> own unique macro temp symbols by concatenating assembly-time counters Rob> and local prefixes & suffixes & the like. But now that I think about it, Rob> one could have easily written "gensym" *in* MACRO-10 macros! (I just never Rob> would have called it that, since I hadn't been exposed to Lisp yet.)
The PDP-10 systems at MIT were programmed using the MIDAS assembler, which was even more powerful than MACRO-10. To wit,
GENSYMMED DUMMIES.
If a gensymmed dummy is unspecified, its value will be a GENERATED SYMBOL 6 characters long - the first character "G"; the rest, a number in the current radix whose value equals that of .GSCNT, which starts out as 0 and is incremented before each gensymming. Thus, in each call, an unspecified gensymmed dummy will provide a unique label. If nullspecified, a gensymmed dummy has the null string as a value. Gensymmed dummies are treated differently when nullspecified or unspecified for compatability with old versions of MIDAS. In fact, the distinction between unspecification and nullspecification is made only to handle this case.
Yes Erik, you have already shown clearly enough that you cannot read.
If you could, I could give you some hints on reading, like the fact that there is a semantics phase between input syntax and reply syntax. I really hope one day you will get to the level that you can read and understand what I wrote, and see that you are not addressing at all what I am talking about.
But actually, I am not trolling - This started as a simple explanation why some code was more complex than average, and then Erik jumped in misreading my comments.
> (with-open-file (biep "ears" :direction :input) > (write "Quit Being A Troll!" :stream biep) > (flush-output biep))
> Wade
> "Biep @ http://www.biep.org/" <reply-...@my-web-site.com> wrote in message > news:9fo442$53sri$1@ID-63952.news.dfncis.de... > > Erik, would you please go away? If you had bothered to try to read what I > > wrote, you would have understood that I don't have the least problem > expressing > > what I want to express using the CL macro system, and that I do not > propose that > > anything should change. This is the second time you, out of nothing, > start > > spouting stuff at me that has nothing to do with what I am writing about > and is > > at the same time offensive.
> There's pretty extensive experience with myriad users > and multiple implementors over a really long time (in > "contemporary programming language use" terms) to suggest > that the reason no one is "evolving" the CL macro system > is that it works just fine.
Thanks. That's my point of view too. In fact, I stated so specifically at the top of one of my messages. All I was trying to do is to explain why certain code was more complex than average. When someone asked me, I tried to explain the difference between a transformation in meaning and a textual transformation, and I guess at that point some people started seeing Scheme monsters along the way and got out their guns.
Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit. I am glad the Scheme community resisted the ARPA pressure to merge with CL, and I do hope EuLisp is not still-born, but even then, a mere three Lisps..
Maybe it is just old age, but in my experience the days before standardisation were much more fun, when you wrote a Lisp with some neat feature and showed it around, and looked at other peoples' Lisps and took their stuff seriously.
Oh, I know, some research is still going on, but it seems the gusto is gone, and that is not because we have reached the status of "perfect language"..
> Maybe it is just old age, but in my experience the days before > standardisation were much more fun, when you wrote a Lisp with some > neat feature and showed it around, and looked at other peoples' > Lisps and took their stuff seriously.
> Oh, I know, some research is still going on, but it seems the gusto > is gone, and that is not because we have reached the status of > "perfect language"..
As I see it: Common Lisp standard has not stopeed anything -- it's just a solid foundation for us to build on. Everyone is free to improve on it (although it's really hard for novices to come up with something that might be an improvement).
-- Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
> As I see it: Common Lisp standard has not stopped anything > -- it's just a solid foundation for us to build on.
Oh, having CL is definitely a good thing, and of course it doesn't forbid anybody to play around. But the time when Interlisp was in a contest with MacLisp, when to almost everybody's amazement Scheme(r) brought the Planner/Conniver line back in the fold by showing that with lexical scoping Hewitt's actors were identical to procedures, that time seems gone, and I think too early.
I must confess that on the lexical scoping thing I used to be on the wrong side, or rather defending having both (having programs such as this Prolog interpreter that didn't need to pass along most of its arguments in the backtrack-recursion), but the discussions were there, and there was an enormous lot of creative energy pushing the barriers forward. It seems most of that has gone to the FP people (who talks about monads in the Lisp community?), and Lisp seems to be petering out.
Other languages are (seemingly) overtaking it, and the power of Lisp that made it run faster and thereby stay miles behind of the pack has been sapped. It is like the hare falling asleep because it is ahead of the tortoise.
Now maybe I am wrong, and exciting new developments are still leading to improvements, but the only place where I see that happen is Scheme, and despite SLib, Scheme is not real-world robust. (Well, that's exaggerated, but there are definite disadvantages to using Scheme in the Real World.)
My ideal vision would be the big bomber CL moving steadily forward, with a lot of smaller satellite Lisps around it that cleared the way in front, and then CL absorbing the space cleared by those satellites. But I see only one satellite, Scheme, which has its own set of satellites and is in fact (slowly and ever more slowly) moving forward, but only in one of a host of possible directions, which is not necessarily the direction CL should go.
Of course Lisp itself is a satellite of the ethereal ideal programming language, having chosen to explore the untyped lambda calculus, but most of the activity is happening by the typed lambda calculus people, and if their languages get better than the best Lisp, research in untyped lambda calculus as a programming language, or in program-as-data, will all but die when Lisp dies.
I don't care if a language dies because a successor is objectively better, but I do care if that kills parts that are, or may be, better than corresponding parts in that successor.
-- Biep Reply via http://www.biep.org (which is down right now, but sending to any username whatsoever at that domain will get to me).
> "Kent M Pitman" <pit...@world.std.com> wrote in message > news:sfwhexs6ku9.fsf@world.std.com... > > Where is this technique discussed? I'd like to peek in at it and compare > > notes. If I understand you correctly, I've used this technique myself, > > effectively giving continuation closures a handle and then having the session > > call back looking for a continuation by name. If you assume one-time > > reuse and timeout, it works pretty well. If you can re-visit the same > > continuation more than once or if you can't GC them, it's a problem.
> Earlier I gave this pointer: > http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz; > I am not sure that answers your question, but it does discuss re-entrance, which > is interent in the WWW model: people can always return to pages they have > visited before.
> -- > Biep
By the way, if you have problems with this file (as I did), its probably because it is actually a pdf file, NOT a gz file. I.e., just rename it to *.pdf and use your pdf reader on it.
On Thu, 7 Jun 2001 21:28:30 GMT, Kent M Pitman <pit...@world.std.com> wrote:
> Where is this technique discussed? I'd like to peek in at it and compare
This paper might also be relevant:
"The Influence of Browsers on Evaluators or, Continuations to Program Web Servers" Christian Queinnec Proceedings of ICFP '00 SIGPLAN Notices - vol. 35, n. 9, Sep. 2000, page 23
