> 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..
I don't think anyone thinks our Lisp is the perfect Lisp.
Personally, I don't think Scheme is a Lisp, but I say so mostly to help avoid Scheme fanatics tinkering in Lisp or vice versa, since I think the two arise from differing motivations. I think languages that are out for different purposes will never satisfy each others' users, and ought not try. But I also think you can't critique a language very usefully if you have not tried to use it and if you don't have some sense for how it is intended to BE used.
That's not to say some don't go back and forth between, and I don't mean to say a person can be only in one camp. Just that some people seem people deny themselves a legitimate view of the other side by letting their prejudices get in the way.
I'm not sure what to say about EuLisp. I haven't tracked that. But certainly its name doesn't strike fear in my heart. I do personally think it's a separate language, perhaps more a dialect of Scheme than Lisp, but that's just a subjective judgment. I don't think CL is a rock unto itself. I count gnu emacs lisp as a member of the lisp family, and it's far from CL compliant.
All of that said, though, I don't think there's any way that CL people are unwilling to hear criticism. We thrive on it. We share our troubles and learn from them. Although I consider myself an advocate of CL, I spend a LOT of time here whining about its nits. But that whining, whether from me who's used it for a while or from a newbie who's just optimistic trying it, needs to come from someone who is doing their best at whatever their level of expertise to "get into it", and not merely "taking a moment to prove to themselves what they already knew" or "testing out their theory that the language couldn't work by running an example or two".
I'm speaking completely generally in all of the above remarks. I haven't followed this particular discussion in detail other than to note there were some heated exchanges. Please don't take any of my vague references to this or that kind of person as veiled references to the players here--I'm just answering your remark in the general sense that it appears to call for.
I think there are communities that suffer from NIH syndrome. I honestly don't think the CL community does. Someone (Joel Moses, I think) described Lisp as a big ball of mud, to which you can add more mud without disturbing the basic design (I've paraphrased a little); other langauges have been variously described by others using other metaphors that don't always tolerate an influx of new ideas. (APL, is the canonical example of a diamond, I think it was, which cannot have other diamonds added to it without breaking.)
> 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.
I think you misunderstand a couple of things.
First, the particular dialect which is CL was formed out of a desire to not haggle until doomsday about the primitive functionality. It is a language whose purpose is less to be "right" and more to be "standard". That doesn't mean it can't be found to have more optimal ways of doing things, it's that in order to be changed, you'd have to show the platform was fundamentally broken.
Second, this same thought was the conclusion of J13 a year or two ago when it effectively decided to renew the standard rather than to change it. I don't know anyone who didn't have an armload of things they want changed, but no one could justify the COST of a change compared to the VALUE of leaving it as is. No one felt the language was materially unusable and the general sense was that moving forward, not spinning our wheels on the same old stuff, was the important thing.
I think if you are fair, and you divide the discussion along the lines of "old" and "new" layers, you'll find all the same old stuff you may remember from long ago. I've seen a lot of healthy discussion about anything from a trivial function like partition-string to regexps to defsystem to xml parsing to http handlers to you name it. I don't think you see people saying they have only one way to do things or that they aren't open to new thoughts. But on the things that are STANDARD, you see them defend the present way not because it's "right" but because it creates a balanced platform to do this next round of work from.
I've recently whined about the misdesign of pathnames (the problem of the "hosted pathname", for example). But you know what? That's fixable by layering correct semantics atop the present semantics. It's not fatal. And I think it's better to count the overall system as working exactly because it offers enough capability to rise above its little details of misdesign by monotonic addition.
> 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"..
I think the gusto is not gone, but you phrase your remark as a perception and I'm not going to assert that however it seems to you is not however it seems to you. I will, however, suggest you are misperceiving the reality.
(I don't understand what any of this has to do with macro-writing in CL, but I'll just let that slide. If I care, I'll go read DejaNews. You don't have to replay the conversation. It's just curious how far a conversation can drift sometimes...)
> All I was trying to do is to explain why certain code was more complex > than average.
How do you measure complexity? How do you know where the average is?
> Now this whole "my Lisp is the perfect Lisp" thing saddens me a bit.
Why? You have displaed a "my view is the perfect view"-attitude to almost everything else already? Is it because you get counter-arguments that show that your view is _not_ perfect that it saddens you?
> 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..
It saddens me to see someone with so little actual knowledge have such strong opinions.
> 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.
The rebel nature has always had more fun before laws and regulation, which, amazingly, a majority of people actuall prefer, took away their "freedoms". There are always people who can only have "fun" in a society without set rules, i.e., where they make up their own and can change them at will. There are people who do not want others to have "fun" at all and make up so many rules that nobody can do anything unanticipated without breaking enough to hurt you. Then there are people who grow tired of making up rules all the time, of ever-changing rules everywhere they go, of finding that the human capacity for memory is an _enemy_ instead of a good friend in living productively, of living in fear of their long-range planning turning to an exercise in futility because the rules change so fast they cannot plan long-range at all. (These people are not trying to do business in the Norwegian tax "climate", however, where politicians today are debating whether to withhold a tax break they promise us ten years into the future back in 1992, because, amazingly, it will reduce government revenue.) In short, the only people who have more "fun" in a society without rules are the people who have enough power to make the rules. If you recall such insignificant political events as the Magna Carta, which forced the then King of England to behave, or The Declaration of Independence, which forced the ruling England to withdraw their power to make rules over people in America, or the Universal Declaration of Human Rights, which basically sets limits to what the rule-makers can do to those who lack the power to make their own rules, so they have to _follow_ rules, you might begin to understand that the ability to make up rules as you go and to change everything all the time is not at all appreciated by those who try to follow them. This also applies to programmers writing software in Lisp, companies basing all or some of their business plans on such software, or vendors who want to sell stuff to both of these parties, who consider the lack of agreement on the rules so hard to live with, but which the rebel nature finds so endearing because it is anathema to that dreaded anti-rebel concept of _responsibility_. It is probably a mystery to you, so please feel free to believe me on faith, but societies, small and large, that have stable rules have prospered much, much more than societies with unstable rules. This seems to apply regardless of what the rules are, but bad rules tend to be unstable, so we are driven towards societies with stable rules. Globalization forces countries with irrational policies to reevaluate their rules because people are free to choose the rules they want to apply to their business and their personal lives. Guess what kind of people find this so dangerous and fight it so much. Precisely the kind of people whose main philosophy in life is to be on the rule-making end of the rules. More reasonable people tend to consider both the maker and the follower of rules.
> 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".
The point with Common Lisp macros is that you can devise your own language if you want to. Scheme has successfully been implemented in Common Lisp, for instance. What was once called "research" is now more often called 'application programming" because the research has sort of "trickled down" into the masses. An amazingly amount of AI stuff has taken this route and is no longer considered "AI" for that reason alone. _Compilers_ were once a very, very advanced "AI" research project.
I think the evidence of what is going on in the other languages shows us that we have indeed reached the status of perfect language, but a lot of rebels of sometimes severely limited intellectual resources are never going to be satisfied with it, and insist on reinventing everything that is already in Lisp badly. The little _actually_ new stuff that people do can also be done in or with Common Lisp. More often than not, however, the "new" is in standardizing some of the environmental issues. I guess it was a lot more "fun" before we had standardized environments, right?
I want to build things. That _includes_ languages, but not exclusively. People who build languages have a very hard time. People who build stuff that _more_ than just programmers and researchers can use have a slightly easier time. This has nothing to do with the perfectness of languages.
#:Erik -- Those who do not know Lisp are doomed to reinvent it.
> 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.
You are too puzzling a character for me to want to spend any time on, but just out of curiosity, since you refer to CLtL2 as the reference for Common Lisp, your attitudes and opinions must predate 1995 and not have evolved much since, and by the looks of it, you are still mired in the pre-1990 Lisp world, possibly even pre-1980. Why is that comfortable for you when the rest of the Lisp world really _has_ moved on so much and so far? Why are you pining for an irrelevant past?
Or are you trying to prove my point when I say that Scheme is not a Lisp, that the Lisp that "Scheme is a Lisp" refers to is a really, really ancient Lisp that has absolutely no relevance outside of history lessons?
> 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.
The very idea that anything is "objectively better" is simply ludicrous.
I think you need a fundamental attitude readjustment. Quit being a troll.
Craig Brozefsky <cr...@red-bean.com> writes: > Kent M Pitman <pit...@world.std.com> writes:
> > 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.
To clarify, I intended to suggest that the discussion of scaling lisp applications could be moved to lispweb where there are many people interested in the topic, and alot of people with experience in the topic.
It was in no way intending to suggest that discussion with Kent about consulting on the topic of scaling lisp web apps should go to that list.
-- Craig Brozefsky <cr...@red-bean.com> http://www.red-bean.com/~craig "Indifference is the dead weight of history." -- Antonio Gramsci
In article <9fq3q7$5kp1...@ID-63952.news.dfncis.de>, Biep @ http://www.biep.org/ <reply-...@my-web-site.com> wrote:
>All I was trying to do is to explain why certain code was more complex than >average.
I have a pet theory as to why some code is more complex than average.
It tries to do more complex things.
The CL macro facility is extremely powerful. It allows you to write a code generator with a very small amount of overhead. It's like writing a small piece of a compiler, without all the parser and lexer stuff (which you don't need here).
This stuff is difficult. I remember the first time I had to write a program to generate simple source code. I really botched the job, and wrote and rewrote it before I got the basic idea.
Now, that took a lot of scaffolding. (You try writing something complicated in IBM 370 assembler without supporting structure.) In CL, it takes almost no extra structure, and so the bulk of what you'd normally write is removed, leaving only the core. Since the task is inherently difficult to do right, this leaves the macro writer writing, and perhaps struggling with, a few lines of code. The size of the macro written makes it look like it has to be easy and simple, whereas it's complicated and can be difficult.
When there's a small language construct that is surprisingly difficult and error-prone, there's a temptation to think that it's because of some fault of the language. This is usually true of most computer languages I've used, but I think it false in this case.
>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..
There's lots of things in the world that don't work very well, but which nobody's come up with a better solution for. Winston Churchill said "Democracy is the worst form of government, except for all the other ones." I think this is one of those cases: it isn't perfect, but I don't have a better idea, and I haven't met anybody who did.
So, if you have an idea for a better way to write macros, or a better way to teach how to write macros, please tell us. If not, then I think this is one of those cases of idealism that are just going to be frustrated.
> 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.
So what are you proposing? If you have nothing to show around (and yes, it's just as easy to build something now as in the old days - maybe easier), then all you're doing is bitching. Anyone who could show a system for doing the equivalent of (or more than) the current CL macro system without (what you perceive as) the cruft would probably be listened to. So get cracking! Otherwise, be still.
>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.
It is important to keep in mind that regardless of where the spirit of exploration takes the Scheme community, defmacro remains exactly as usable and easy in a Lisp1 as in a Lisp2. A Lisp1er would use the same technique to avoid lexical-variable capture as a Lisp2er would -- when you introduce a lexical variable in the expansion, use a gensym. If someone gets the impression that a Lisp1 forces one into considering a hygienic macro system any more than a Lisp2 does, that impression is unwarranted.
Off-topic post alert. . .if you're not interested in load-balancers hit 'n' now.
Tim Moore <mo...@herschel.bricoworks.com> writes: > 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.
As someone pointed out earlier, if you have a reasonably full-featured load balancer, their approach scales nicely. Insert a load balancer parcelling initial requests amongst a farm of servers and then turn on persistence for future requests and you have a robust, simple solution. FWIW, persistence usually comes in the form of a cookie, an SSL session ID, or client IP address(es) (NOTE: outside of intranets, the AOL problem makes using client IP a bad idea).
This does leave the problem of what happens when the persistent server for XYZ falls over in the middle of a session. AFAIK, I don't know of any load-balancer that would do anything besides load-balance the client to a different server.
And all for a few measly $$$ and 4-U (gotta have a redundant pair) of rackspace.
d...@goldshoe.gte.com (Dorai Sitaram) writes: > ... A Lisp1er would use the same > technique to avoid lexical-variable capture as a > Lisp2er would -- when you introduce a lexical variable > in the expansion, use a gensym.
Actually, I was more referring to the issue of what variables you could use free. In Scheme, I find using variables like LIST to be dicey because I use that as a variable name and it requires me to know how a macro expands to know if I'm screwing it by using a pretty variable name. So I think there are some legit concerns in a Lisp1.
> If someone gets the > impression that a Lisp1 forces one into considering a > hygienic macro system any more than a Lisp2 does, that > impression is unwarranted.
It might not be an all-or-none thing, but I think it can't be argued that the probabilities of collision are higher. Well, ... it can be argued ... I just don't think it will end successfully. ;-)
> "Pierre R. Mai" <p...@acm.org> wrote in message > news:87g0ddzv3r.fsf_-_@orion.bln.pmsf.de... > > In what way do you feel that writing (serious) macros in CL > > involves 'a lot of "fighting the system"'?
[...]
> (2) Macros are (or should be) about meaning one thing when you say > another -- not necessarily about transformations, even though the notions > come close. (To appreciate the difference, see what C macros can do that > they shouldn't..) Let me just give a few examples:
Here I'd have to disagree. Macros in Common Lisp _are_ arbitrary source code transformations, nothing more and nothing less. They are not mechanisms that are geared to writing syntactic short-hand notions, they are just a hook into the compiler/interpreter. They are source-level transformations of the sort you will find in the first stage of a compiler.
In that way they are all powerful (every kind of transformation that is computable can be implemented), and with that power come the corresponding caveats.
Which is why I was surprised by your assertion that writing macros involves a lot of "fighting the system", which I take to mean that you have to circumvent _restrictions_ in the system to reach your goals.
If your claim were to be that the macro system itself provides too little guidance and support to the writer of "simple" syntactical convenience macros, I'd actually quite possibly agree.
I think there is a place (in a layered standard to ANSI maybe) for a layer on top of the macro system, that implements something similar to the R5RS-style or Dylan-style pattern-based macro systems.
But note that those are very different mechanisms with very different goals and uses to those of defmacro-style "macros".
> There is a subtle but fundamental difference between the notions of 'fresh > variable' and '(gensym)'. The latter is a kluge to arrive at the former > (or the right thing to do in other contexts, of course).
It is not a kludge, it is a lower-level tool, a building-block out of which the higher-level tool will be built.
> There is a difference between 'the list function' and '(list ...)'. CLtL2 > has 'solved' the resulting problem by requiring that no built-in function > can be redefined, but that is of course a weakness bid.
Of course there is a difference between 'the list function' and '(list ...)'. The former is a function, the latter a form that is a function call.
What you probably meant to state is that there is a difference between the list function as described in the ANSI CL standard, and the function that is invoked when the implementation encounters the form '(list ...)'. But if (eq 'list 'cl:list) (which is a reader issue), then there is no such difference, because you are not permitted to bind it, again according to the standard, as you state (though relying on a document that never had any standing as a standard, in contrast to CLTL1 and now the American National Standard X3.226).
Furthermore, as Kent has pointed out the same is true of any other global function or special variable that is part of foreign code, since the same implicit contract exists there, too.
And since "problems" only occur when you break that contract, which requires direct action from you, this is a completely stable situation. When you override the definition of #'cl:list, you have to expect the consequences.
> (3) So since the macro writer wants to state "whenever I say this I MEAN > that", but the system wants to hear "whenever you say this, I should assume > that you SAID that", macro writing necessarily involves fighting the > system. It is a lot like legalese: a lawyer is also a guru in bringing a
Not at all. Fighting the system means having to work around restrictions in the system, in order to achieve the results intended. The problem you are running up against aren't the fault of the system:
The system states quite clearly that macros are a completely general source transformation system. But you want something _more_ restricted, in order to preserve you from having to think about low-level issues. In effect you are complaining that the system gives you too little guidance, thereby allowing you to do something different from what you wanted.
BTW I don't think that your description of what the macro writer wants to is clearly defined. The moment words like "MEAN" etc. crop up in a definition of what a system should enable, we enter the land of DWIM it seems to me.
> meaning across in a system that tends to look at texts, but it involves > non-trivial phrasings, and often a lot more text than one might have > thought. If a non-guru draws up a legal document, it is likely there are > loopholes.
Well, again, that isn't fighting the system. When a non-programmer draws up a specification for a system, it is likely to contain many loopholes and inexactitudes. That's why we have programmers (and lawyers), which are capable of navigating the _necessary_ intricacies of complex systems.
Of course for certain, simpler problems, the lawyer can offer you a prewritten text, which can be used with a few simple changes out of the box.[1] Again, for certain "simple" macros, it might be preferable to use a more restricted mechanism layered on top of defmacro. Indeed for many macros that people define it is often better to use inlined functions.
And the nice thing about CL is that it allows the user to design and implement such mechanisms to his liking, exactly because CL macros are arbitrary source transformations.
> Does that help? Again, if you are familiar with the system, the > "macrolese" may come naturally, and even appear obvious, and definitely > prove exploitable in ways that a "correct" solution would not be -- again > the comparison with lawyers comes to mind :-)
If you were to refrain from using such words as "correct", and letting your disdain for the legal system taint your argument, it might be more persuasive. It is clearly the case that defmacro is a "correct" solution to the problem of arbitrary source to source transformations. That you don't want a solution to this problem, but rather to a slightly different problem, doesn't make defmacro incorrect, it just means that you are missing a system that is a perfect fit to your particular problem. And the nice thing is that defmacro gives you the mechanisms to create that system, which would be impossible if you didn't have access to that lower-level mechanism.
Regs, Pierre.
Footnotes: [1] In the legal world it is often still advisable to consult a lawyer, because non-experts are notoriously bad at evaluating whether the assumptions underlying the prewritten text apply to them or not. Luckily this is somewhat simpler in the case of simple macros.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
I have not read the thread past this point, but so far completely disagree that this person is trolling.
I find the discussion interesting and educating. Erik Naggum wrote recently in another thread (the "aref inline?" one) very correctly about how in the usenet forum, it "pays off to be imprecise and incorrect in order to produce the most lucid answers." So I think there is much more to be gained in this discussion by getting the chips off the shoulder keeping the discussion technical. Biep has committed no outrage at this point.
Coby
Addendum: My familiarity and skill with macros is such that I can write them and use them to solve interesting and complex problems in ways that I find very satisfying but still do not yet fully understand much of what I see being discussed at times. I like them very much but do not fear hearing what others dislike, nor hearing criticisms I already disagree with, it helps me learn.
> (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!"))
> > 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"
> 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.
I think that load balancing is often required because of unnecessary mistakes.
If you're serving static pages, the current record is at least 3000/sec on an x86 box (http://uwsg.iu.edu/hypermail/linux/kernel/0104.2/1191.html). (Yes, there are multiple NICs.) Of course, if you're only serving static pages, you probably don't care about sessions, but I mention that rate because it suggests that a single webserver might be able to serve a lot more traffic than many people expect.
So, how many dynamic pages can a single webserver generate per second? Naturally, the answer depends on what it takes to generate the page, but Rushing's Medusa put out did 200 messages/second (for egroups) from a 400MHz PII. (Medusa is a single-threaded python app. The execution model looks a lot like co-routines. The code is available at www.nightmare.com.) That code is basically just a clever front end for select, so it's the same for any network service.
Those are old numbers - there are faster ways to handle select in more modern linux/bsd/solaris kernels, and there are faster processors. In addition, while the python interpreter is single-threaded, other webservers can make use of multiprocessors. In short, it shouldn't be too hard to generate/serve 1000 pages/second from a comparable system running on a high-end, but commodity, 4 processor x86 box. (I suspect that network i/o will be the bottleneck - we're approaching low-end PCI limits.) And, how many sites need that kind of capacity but can't afford to buy something even more capable? (100/sec is 360k/hour, or easily a million/day.)
Ah, but what each page requires 100 joins (or disk i/o)? In that case the webserver can front-end compute servers. I suspect that a single webserver can easily front-end a fairly hefty oracle server, say a 16 processor sun box. Using a webserver as a front-end uses connection bandwidth&processing, but we still should be able to generate 500 pages/sec.
Will some people need even more capacity? Yes, but not many.
> There is a subtle but fundamental difference between the notions of 'fresh > variable' and '(gensym)'. The latter is a kluge to arrive at the former > (or the right thing to do in other contexts, of course).
Yes there is a difference between a call to `gensym' and the notion of a "fresh variable" -- as Pierre pointed out, `gensym' is a low-level tool. If you don't like writing your macros at that low of a level, don't. Write yourself some tools and never type the sequence "gensym" again. I actually type "gensym" maybe 1 in 500 times I use an uninterned symbol in a macro. Once in a while I need to call `gensym' directly, the rest of the time, I use a little utility that walks the code my macro returns and replaces symbols looking like =foo with uninterned symbols. It took a couple minutes to write. But I'd be really annoyed if I didn't have access to the low-level `gensym' on those occasions when I need it.
> There is a subtle but fundamental difference between the notions of 'fresh > variable' and '(gensym)'. The latter is a kluge to arrive at the former > (or the right thing to do in other contexts, of course).
Actually, Lisp also has GENTEMP, but experience showed that it was never adequate. Peter Norvig and I, when putting together a coding style presentation years back (parts of which I think is findable somewhere by web searches) both noted and agreed that almost all uses of GENTEMP are semantically flawed. The problem with GENTEMP (which might not appear in C because of lack of print/read consistency leading to ephemeral environments that perhaps don't expose the problem) is that you can't close over the space of things you wish to have something be "fresh from". That is, I can say "give me a fresh variable" and you can do the same, but later we can merge our two environments and find that we each thought a certain variable was free and used it but that in the new, merged environment, it is not free. You might say the probability was low that the two would be used together, but it sometimes happened that people would proclaim such uses SPECIAL, thinking after all that they owned the variable, and then they would suddenly start failing to work in other people's closures upon reload of stored code that had formerly been thought to be a lexical closure.
> There is a difference between 'the list function' and '(list ...)'. CLtL2 > has 'solved' the resulting problem by requiring that no built-in function > can be redefined, but that is of course a weakness bid.
I don't see what this has to do with macros or weakness of anything.
> Lisp has fought hard to get rid of (default) dynamic scoping, but in macros > this is still the default. If your macro references a variable X, it just > grabs whatever X happens to be available at the location where the macro is > used.
Properly styled code therefore does not do this except where it can see the entire space of usages and so prove it is safe. This does not turn out to be a weakness in experienced practice. It is syntactically straightforward and convenient for macro writers to write solid code in the face of this deficiency.
> Like dynamic scoping for lambdas, people who have gotten used to > that tend to like it, and indeed can proffer a whole battery of situations > where this 'feature' can be exploited -- again the guru phenomenon. > Normally you mean 'this variable' but have to write 'X', again not quite > the same thing. As with functions, lexical scoping (referential > transparency) should be the default, with an option for dynamic scoping.
This is an assertion without foundation.
Certainly I absolutely agree with you that it is possible to take the position you are taking. Nor do I deny that many do. However, there are other consistent world models that compete with this one and that are used as well.
There is also a price in terms of "complexity elsewhere" for the approach you suggest. Nothing prevents you from using macro "painting" like Eugene Kohlbecker's macro systems in Scheme use, but if you try it you will find that it doesn't work as well in CL as it does in Scheme because a lot more things in Lisp than Scheme rely on identity, and Kohlbecker's model paints not just program but data, which injures some CL data structures that Scheme has no way of talking about.
Further, there is a definite cost in terms of how hard it is to do things that don't fit neatly into a simple substitution model. Doing "hard computation" on a macro form in Scheme/Dylan is very much harder than in Lisp. Macro writers have to think about these costs, too, which is why many of them prefer the Lisp model.
If one was going to do a hygienic macro system for Lisp, the one I'd pursue would be Alan Bawden (I think it was)'s "Syntactic Closures". (I had a similar theory worked out but he beat me to publication. Even so, I liked his approach much better than Gene's painting system and was sad to see the painting system win out.)
> (3) So since the macro writer wants to state "whenever I say this I MEAN > that", but the system wants to hear "whenever you say this, I should assume > that you SAID that", macro writing necessarily involves fighting the > system.
So do ALL things that you choose not to like, whether or not they work. No serious macro writer I know feels like he's fighting the system. I very much enjoy writing macros. I find their use simplifies my life and I enjoy the process of making them. I look forward to it.
> It is a lot like legalese: a lawyer is also a guru in bringing a > meaning across in a system that tends to look at texts, but it involves > non-trivial phrasings, and often a lot more text than one might have > thought. If a non-guru draws up a legal document, it is likely there are > loopholes.
That same programmer is often going to write bad programs as one-shots, without the macro system, too.
But I have often said that the quality of being a programmer is being a list-maker. You are writing a full flowchart through a space, not just a single path. There is programming for the dabbler, where you just try something and hope it works the one time you try it, and pat yourself on the back. But that's a different art form entirely. Programming for serious programmers is about having industrial strength operators that stand up under contract scrutiny. And I daresay CL unhygienic macros will stand up to Scheme hygienic ones just fine. And probably both will beat out C macros by leaps and bounds.
> Does that help? Again, if you are familiar with the system, the > "macrolese" may come naturally,
A skilled craftsman always knows his tools. Would you come critique a carpenter's shop on the basis of how hard it is to use the 30 kinds of saws when you can't see what the subtle differences are? Because that guy is surely just glad to have the right tool for each job as he comes up on it. I'm sure he doesn't see it as woodlese.
> and even appear obvious, and definitely > prove exploitable in ways that a "correct" solution would not be -- again > the comparison with lawyers comes to mind :-)
As I went to write "There is no canonical out-of-context notion of correct." I seem to recall someone (perhaps Erik) already making that point.
In particular, spec99 has both dynamic and static pages. In addition, the 3000 number is NOT pages served, but simultaneous connections that are getting adequate service. It's doing over 9000 ops/second.
The underlying hardware is a 2 processor 1GHz PIII with only 4GB, but it's only the fastest on "cheap" hardware.
The x86 champ is 8000 connections at 22.7k ops/second from an 8 processor 700MHz PIII-Xeon (and 32GB).
There are even faster results from a 12 processor SUNfire and a 12 processor IBM eServer (RS64). (I didn't see any 3090 followon results.)
If anything, that's more argument for the feasibility of a single webserver.
Yes, a single webserver is a single point of failure. Then again, if your servers aren't on non-adjacent plates (servers on different sides of the San Andreas fault isn't good enough), you're already subject to single cause failures. It's hard to do redundancy right, to get a system that is actually more reliable than its components, and in many cases, minimizing time to repair/recovery is more important.
> I have not read the thread past this point, but so far completely disagree > that this person is trolling.
> I find the discussion interesting and educating. Erik Naggum wrote
recently
You like it that Biep is starting to insult Erik and in an attempt to get him going?
He bashes the current macro system without having no replacement. Then he says he is not bashing the current system. Then insists that Scheme might be on the road onto a better one. Then he starts insulting Eirk's intelligence. Provoking Erik, for me, says that he is a scheming troll. Biep knows better.
These are interesting stats, and they do show that a single server may be a viable option for many web applications. Then you can use closures to your heart's content. I don't like to talk about my employer much in this forum, and our traffic numbers are a closely guarded secret anyway, but... there ain't no way we would run the front end of the site on a single server. I'll leave it at that.
> In particular, spec99 has both dynamic and static pages. In addition, > the 3000 number is NOT pages served, but simultaneous connections > that are getting adequate service. It's doing over 9000 ops/second.
> The underlying hardware is a 2 processor 1GHz PIII with only 4GB, > but it's only the fastest on "cheap" hardware.
> The x86 champ is 8000 connections at 22.7k ops/second from an 8 > processor 700MHz PIII-Xeon (and 32GB).
> There are even faster results from a 12 processor SUNfire and a > 12 processor IBM eServer (RS64). (I didn't see any 3090 followon > results.)
> If anything, that's more argument for the feasibility of a single > webserver.
> Yes, a single webserver is a single point of failure. Then again, > if your servers aren't on non-adjacent plates (servers on different > sides of the San Andreas fault isn't good enough), you're already > subject to single cause failures. It's hard to do redundancy right, > to get a system that is actually more reliable than its components, > and in many cases, minimizing time to repair/recovery is more important.
> Actually, Lisp also has GENTEMP, but experience showed that it was > never adequate. Peter Norvig and I, when putting together a coding > style presentation years back (parts of which I think is findable > somewhere by web searches) both noted and agreed that almost all uses
Would that have been the ``Tutorial on Good Lisp Programming Style'' at the Lisp Users and Vendors Conference, August 10, 1993
If that's the one you're referring to, people can get the slides from Peter Norvig's site at <url:http://www.norvig.com/luv-slides.ps>. It refers to use of GENTEMP as one of a list of red flags: "... you do not automatically have a problem in your code, but you should still proceed cautiously". A footnote refers to GENTEMP specifically as having "no known good uses"
Daniel Barlow <d...@telent.net> writes: > Kent M Pitman <pit...@world.std.com> writes:
> > Actually, Lisp also has GENTEMP, but experience showed that it was > > never adequate. Peter Norvig and I, when putting together a coding > > style presentation years back (parts of which I think is findable > > somewhere by web searches) both noted and agreed that almost all uses
> Would that have been the ``Tutorial on Good Lisp Programming Style'' > at the Lisp Users and Vendors Conference, August 10, 1993
> If that's the one you're referring to, people can get the slides from > Peter Norvig's site at <url:http://www.norvig.com/luv-slides.ps>. It > refers to use of GENTEMP as one of a list of red flags: "... you do > not automatically have a problem in your code, but you should still > proceed cautiously". A footnote refers to GENTEMP specifically as > having "no known good uses"
>> I have not read the thread past this point, but so far completely disagree >> that this person is trolling.
>> I find the discussion interesting and educating. Erik Naggum wrote > recently
> You like it that Biep is starting to insult Erik and in an attempt to get > him going?
> He bashes the current macro system without having no replacement. Then he > says he is not bashing the current system. Then insists that Scheme might > be on the road onto a better one. Then he starts insulting Eirk's > intelligence. Provoking Erik, for me, says that he is a scheming troll. > Biep knows better.
> Wade
From what I have read of Erik's posts here, insulting his intelligence is stupid. If you read what he writes there is no way a person of average or better inteligence could think he is less then very smart and educated. You may not agree with it but he presents a very good argument.
"Wade Humeniuk" <humen...@cadvision.com> wrote in message <news:9fua6j$sjo$1@news3.cadvision.com>... > You like it that Biep is starting to insult Erik and in an attempt to get > him going?
What a pile of crap! In <3200870443762...@naggum.net> it was E that was provoking - strange, having such an uncalled for attack with all that fuss over the "fighting the system" phrase, just because E had previous judgement over B - when he accuses most people of doing this to him.
> He bashes the current macro system without having no replacement. Then he
He bashed nothing - he had it in a comment, in double quotes and later admitted he doesn't know macros too well.
> says he is not bashing the current system. Then insists that Scheme might > be on the road onto a better one.
E was the one who brought hygienic macros into the thread.
> Then he starts insulting Eirk's > intelligence.
How? Look at that post - E just came out of nowhere in a clear attack because of some personal past issues with B, and in what seemed to be an attempt to AVOID a fight, B did not reply for his posts. Anyway, insulting E's intelligence seems to be a very easy thing to do.
> Provoking Erik, for me, says that he is a scheming troll.
Oh god...if you just pull your tongue out of E's ass for a couple of minutes you might think better. It's so fucking annoying to see people happily shove their tongues up there just because he seem to know more than you do. Like that magic flute he uses his infinite cheap speeches and bad cliches to drag you morons behind him. The damage he does for Lisp is far beyond his technical "contributions" only if for this killing of anyone that dares saying something bad on CL - other people are open to hearing about good things from others while E is so focused around he's speeches about smart people not locking on a single way of thinking that he is completely unaware of anything and anyone except for himself. Just Get a Fucking Life.
>> ... A Lisp1er would use the same >> technique to avoid lexical-variable capture as a >> Lisp2er would -- when you introduce a lexical variable >> in the expansion, use a gensym.
>Actually, I was more referring to the issue of what variables you >could use free. In Scheme, I find using variables like LIST to be >dicey because I use that as a variable name and it requires me to >know how a macro expands to know if I'm screwing it by using a pretty >variable name. So I think there are some legit concerns in a Lisp1.
>> If someone gets the >> impression that a Lisp1 forces one into considering a >> hygienic macro system any more than a Lisp2 does, that >> impression is unwarranted.
>It might not be an all-or-none thing, but I think it can't be argued >that the probabilities of collision are higher. Well, ... it can be >argued ... I just don't think it will end successfully. ;-)
The fallacy in your argumentation is you assume that in a selected time range (say, when he's writing the expansion text of a macro) a Lisp1er forgets he's using a Lisp1 and thinks he is using a Lisp2. This is an absurd assumption -- a Lisp1er is already fully cognizant and acceptive of the idea that he's using a Lisp1. It, however, makes sense that a Lisp2er using a Lisp1 might have a problem like this. In essence, you are saying that a Lisp2er would run into problems working in a Lisp1 that he wouldn't in a Lisp2. That is indeed a legit thing to say but perhaps should go without saying.
d...@goldshoe.gte.com (Dorai Sitaram) writes: > The fallacy in your argumentation is you assume that in > a selected time range (say, when he's writing the > expansion text of a macro) a Lisp1er forgets he's using > a Lisp1 and thinks he is using a Lisp2. This is an > absurd assumption -- a Lisp1er is already fully > cognizant and acceptive of the idea that he's using a > Lisp1. It, however, makes sense that a Lisp2er using a > Lisp1 might have a problem like this. In essence, you > are saying that a Lisp2er would run into problems > working in a Lisp1 that he wouldn't in a Lisp2. That > is indeed a legit thing to say but perhaps should go > without saying.
Well, I've spent serious time coding Scheme for work at some places I've worked, so I tink I'm not just making it up from theory. The problem is that if someone else gives you a macro whose implementation you don't know, you cannot know whether any variables you bind will cause that macro not to work.
In CL, the common rule for macros is to never use a variable free, only functions. And additionally, if the macro has as its home package the package you're in, you must know its implementation or cannot bind any functions either; if it's a "foreign" macro, you can bind functions because the package system will protect you.
In Scheme, there is no package system protecting you, nor is there a separation of functions and values, so you are at risk every time you bind a variable unless you know the expansion of every lexically contained macro or unless you have a macro system with hygiene.
I don't see how this is fallacious. What is the statement I have made that is factually incorrect?
