I would suggest that everyone who wants On Lisp but doesn't have it consider sending a letter to the publisher asking when it will be reprinted, thus signalizing a demand directly to the publisher. In the meantime, lots of libraries have it. If the local library doesn't, use interlibrary loan services. The code from the book is on the web now, and should continue to be understandable once the book has been read and returned to the library. If need be, borrow the book from the library again.
As far as ANSI Common Lisp goes, it's still in print. If the English version goes out of print, learn German and buy the translation ;-)
h...@paradise.nirvananet (Hartmann Schaffer) writes: > i took the post that started the trend more as an indication that there is > a pretty high unsatisfied demand for the book, and that people turn to > desparate measures to get their hands on a copy. the way he expressed it > certainly did *not* sound like he requested a freebie
Has anyone actually tried ringing PH and asking them what the prospects for a reprint are? That would seem orders of magnitude better than oosting articles in newsgroups which PH editors are unlikely to read.
> Btw, I don't know Paul very well, having only spoken to him a handful > of times, but my impression is that if he had more time, he might tell > you that what stands between you yourself and making millions is not > the purchase of his or anyone's books but just plain getting out there > and finding any of the myriad business opportunities that are sitting > there waiting for someone to take them.
> And if you think all that stands between you and succeeding on a juicy > business topic is that one book, then find a way to borrow, rent, or buy > the book from someone else. If you think this problem is insurmountable, > you need a book on problem solving, not on programming.
I'm just following up to this so the text above appears in more articles. Just do it, don't wait for some book.
On Mon, 14 May 2001 21:40:17 GMT, olc...@interaccess.com (Thaddeus L
Olczyk) wrote: > I am writing this to make a request of you. If you find that > there is no way that your books will be in print once again, > of if the likelyhood is that they will not, then please make some > viewable/readable form of these books available on the web.
See question "Where can I get a copy of On Lisp?" in Graham's FAQ:
> Has anyone actually tried ringing PH and asking them what the > prospects for a reprint are? That would seem orders of magnitude > better than oosting articles in newsgroups which PH editors are > unlikely to read.
Unfortunately it is out of print. I've heard there are some copies left at amazon.co.uk, but they are not likely to last long. If you like I can put you on this page, which has led to some people getting copies. Copies also sometimes come up for sale at eBay.
I am in the process of getting the rights back from the publishers. Then I'll either set up some kind of print on demand arrangement, or just put it online.
> Kent M Pitman <pit...@world.std.com> writes: [snip] > > And if you think all that stands between you and succeeding on a juicy > > business topic is that one book, then find a way to borrow, rent, or buy > > the book from someone else. If you think this problem is insurmountable, > > you need a book on problem solving, not on programming.
> I'm just following up to this so the text above appears in more > articles. Just do it, don't wait for some book.
Continuing this action, but adding a point.
I like *On Lisp* as a read. In general, I enjoy nice written, interesting, thoughtful technical literature, and, for that reason, it be nice if *On Lisp* were more readily available.
I'd almost rather that it *wasn't* made downloadable, *if* this lead to continued lack of a printed version.
And I agree that it's not the *sine qua non*. And I don't think I'd pay $200 for a copy. However, I think it's really worth having in print.
Weird note: I was praising it's discussion of closures off handedly to a Perl guy (who had mentioned *Object Oriented Perl*'s discussion), and 1) he said he couldn't find it, never seen it, wasn't availible so 2) Lisp was dead, 3) lisp authors were all academic wankers who used confusing language, 4) thus (common) lisp was only used in academia etc., etc., etc. (note, some of the "thus"s ran several ways, depending on the stage of the conversation).
However, my reaction wasn't "Oh my god, the Lisp community must generate books to expand mindshare," but "Oh boy, what an idiot."
Hmm. While we're talking book wishes, extracting the Lisp advice bits of Norvig's PAIP (which is a fine fine book overall) seems like a feasible and worthwhile project, if just so I could recommend it to folks without having them give me a hard time with the "AI" word :)
In article <3B02B2B9.F86DB...@removeme.gst.com>, Bob Bane wrote:
> -- > Remove obvious stuff to e-mail me. > Bob Bane > Tim Bradshaw wrote:
> > Has anyone actually tried ringing PH and asking them what the > > prospects for a reprint are? That would seem orders of magnitude > > better than oosting articles in newsgroups which PH editors are > > unlikely to read.
> Unfortunately it is out of print. I've heard there are some copies left > at > amazon.co.uk, but they are not likely to last long. If you like I can > put you > on this page, which has led to some people getting copies. Copies also > sometimes come up for sale at eBay.
> I am in the process of getting the rights back from the publishers. > Then > I'll either set up some kind of print on demand arrangement, or just > put > it online.
I did call PH when I was looking for on lisp, right around when it started to be seriusly hard to find. They told me that the plates were distroyed and they had no plans for a second edition. I did finaly get a copy thanks to Mr Graham's wantonlisp.html page and I would like to thank him publicly for providing the service. Remember lisp is a small community and a small goup of loud vocal people does not buy many books. The first production run lasted for over 10 years and this is not good from the publishers point of view when he has other books that sell out in 1-2 years, quite probably with larger print runs. The fact that they are useless in 3 years max from the inital print run is a good thing, he gets to sell more books. I have heard some rumors about book on demand publishing becoming practical. What would be cool for lisp would be a publisher, like Dover press, that would find a profitable bussness by buying the rites to books that will otherwise never again see the light of day and set up a web site where you could order these books and get them printed as needed.
On Wed, 16 May 2001 18:35:51 -0400, Bijan Parsia <bpar...@email.unc.edu> wrote:
: Weird note: I was praising it's discussion of closures off handedly to a : Perl guy (who had mentioned *Object Oriented Perl*'s discussion), and : 1) he said he couldn't find it, never seen it, wasn't availible so 2) Lisp : was dead, 3) lisp authors were all academic wankers who used confusing : language, 4) thus (common) lisp was only used in academia etc., etc., : etc. (note, some of the "thus"s ran several ways, depending on the stage : of the conversation).
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" [*].
I found respect there, the discussion wasn't too much deep but the idea sounded elegant and people contributed to the thread. The lack of macros in Perl could make that approach impractical and it wasn't clear how one could have a hash with the closures in memory if requests could be directed to more than one process in the web server, which seems to be the only reasonable scenario (this is something to solve in the Lisp application as well).
On Tue, 15 May 2001 12:44:58 GMT, Kent M Pitman <pit...@world.std.com> wrote:
>[Rant alert.]
>Maybe it's just me, but I find this a remarkably irritating thread.
>Certainly it's a possible thing for someone to give away intellectual >property, but it feels to me like the whole discussion presupposes that >his only rational or polite or reasonable course of action is to make >the book more available. I don't see that.
> . > . > .
> .
Gee golly-willakers!
I was taught that it can't hurt to ask. Is it possible that this is an instance where it _can_ hurt to ask?
I think that I should sue my parents for misdirection.
> I was taught that it can't hurt to ask. Is it possible that this is > an instance where it _can_ hurt to ask?
Have you stopped beating your wife?
> I think that I should sue my parents for misdirection.
Every question contains a set of assumptions that an answer may confirm, deny, or simply fail to question, in which case the answer may turn bad. Most people consider only the surface assumption, without even thinking about the underlying assumptions or even the purpose of asking. This is actually reflected in their programming. If you are generally unaware of your assumptions in daily life, chances are you will bring that lack of training in mental skills into your programming. This is the reason I expect programmers to be more aware of their assumptions than most people and consequently more to blame for their assumptions, which I expect to be more conscious than for the general population. (I realize that this puts the programmers I talk about into the "well-educated" segment of the population and that this is increasingly a faulty assumption, progressing towards counter-productive.)
Suppose you are about to write a function that produces an identification string that contains a sequence number. You believe that format is too expensive and decide to print to a string stream. Where you would have requested decimal with ~D in format, you just use write. This works most of the time, until someone decides to bind *print-base* to 8, say, for some unrelated use, and your function prints the sequence number in the wrong base. This may be disastrous. Suppose you remember the base and use (write x :base 10), instead. This works for a long time, then stops working because you were unaware of the variable *print-radix* and failed to use (write x :base 10 :radix nil). Now, it is generally wrong to use a base and a radix marker different from what the user of the value has requested, but there are several users of the print engine, so there are several ways to deal with this and the Lisp way of binding global control variables must be understood and its assumptions made explicit to make this work _all_ the time. (I use write in this example because it lists all the printer control variables as keyword arguments, very much unlike the knowledge you otherwise have to have about printer control variables.) The exact same problem occurs when programmers who have active disdain for the internal upper-case symbol names forget to bind *print-case* or specify :case or ascertain that readtable-case has the expected value, because in their Common Lisp images, these all have their favorite values.
Most software bugs are related to unchecked assumptions, especially the kind of assumption that restrict the set of possible answers to questions that have far more possible answers. These are the questions programmers fail to ask, or the result of asking the wrong questions, which as I hope I have demonstrated _can_ hurt you. (And that this issue is not a joke, unfortunately. Software quality is directly related to willingness and ability of its programmers to ask the _right_ questions, which is a much more valuable skill than to answer the wrong questions correctly, which is what, e.g., Perl and HTML is all about.)
I think your parents should sue you for believing everything they said, if anyone is to be sued over this, because they taught you that it cannot hurt to question their advice, but you failed to do that and still depend on them to tell you what is right. Growing up means finding out why what your parents told you was right for them and their time, figuring out if it is right for you and your time, and if not, what else might be right. For instance, it worked well to repeat one's parents' advice when the world changed very little from generation to generation, but that it has worked in the past is precisely the reason it will not continue to work.
On the other hand, if you really had parents who were able to answer any insane question rationally so that it did in fact never hurt to ask, it is very important to learn how to answer questions so that it does cannot hurt to ask... Actually, that might be a very, very valuable skill.
Erik Naggum <e...@naggum.net> writes: > Software quality is directly related to willingness and ability of > its programmers to ask the _right_ questions, which is a much more > valuable skill than to answer the wrong questions correctly, which > is what, e.g., Perl and HTML is all about.
Most Perl scripts aren't very good in answering any questions correctly in my experience. Given some filenames with spaces or colons in them or anything else out of the ordinary in their input and they will merrily regexp themselves to oblivion.
And there's nothing terribly wrong with HTML as such. As soon as it got into the hands of idiots that couldn't get separation of structure and layout in their heads it was lost off course. Add to that that the major browsers in stead of enforcing the standard pedanticly bowed backwards to tolerate junk that wasn't well formed and you get the current disaster.
-- Lieven Marchand <m...@wyrd.be> Making laws appears to win votes. Enforcing them doesn't. See Rule One. Roger Burton West in the monastery.
> I was taught that it can't hurt to ask. Is it possible that this is > an instance where it _can_ hurt to ask?
Frequently a question is just a gate to something that is hurt. Questioner just opens the gate for it. He doesn't know who comes. Even when he sees the question was "bad" he can't say why.
> The main text that is readily available these days > seems to be Norvig's "PAIP," which, it seems to me, > is somewhat _better_ than either of Graham's books.
While PAIP is a great book, and can be used as an introduction to Common Lisp, it wasn't meant as such, and in fact the code in the book is inetntionally fairly basic, with a few exceptions, such as the stuff on macros (which, by the way, is mainly complex because writing a serious macro in CL involves a lot of "fighting the system").
Someone who has worked his or her way through PAIP will have a decent knowledge of basic AI approaches, but still needs to learn a lot both about Common Lisp itself and about Lisp programming techniques that have not or barely been touched on.
On the other hand: someone who enjoyed working through PAIP is almost certainly someone who is well-equipped to learn these things.
I don't know Graham's books, so I cannot compare them.
> While PAIP is a great book, and can be used as an introduction to Common > Lisp, it wasn't meant as such, and in fact the code in the book is > inetntionally fairly basic, with a few exceptions, such as the stuff on > macros (which, by the way, is mainly complex because writing a serious > macro in CL involves a lot of "fighting the system").
That remark made me interested: In what way do you feel that writing (serious) macros in CL involves 'a lot of "fighting the system"'? This seems to imply that CL is actively "resisting" your writing of the macro in some form, which would imply that CL is in some ways unsuited to writing list-transformation programs. Could you elaborate?
Regs, Pierre.
-- 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
> While PAIP is a great book, and can be used as an introduction to Common > Lisp, it wasn't meant as such, and in fact the code in the book is > inetntionally fairly basic, with a few exceptions, such as the stuff on > macros (which, by the way, is mainly complex because writing a serious > macro in CL involves a lot of "fighting the system").
Thsoe who do not know or do not like the rules are always fighting the system regardless of what "the system" is, while those who know and like the system cannot generally fathom what it is that people _want_ to fight.
The same goes with laws and regulations, codes of conduct, cultures, etc. Programming languages are social constructs. Some people enjoy rebelling more than they enjoy living in a society. Some are able to appreciate the societies they live in higher than what rebelling against it and its people would entail, regardless of whether they think everybody would appreciate whatever is on the other side of rebellion more than the present. I, for instance, think it is far better to fight incompetence than to live peacefully with incompetent people. Some people feel this way about drugs, abortion, communism, etc. That macros in Common Lisp should be such an issue should come as a surprise to no one. However, there is much, much less _force_ involved in having to accept macros than any of the other issues that cause similar reactions, so I have a really hard time understanding the underlying desires of the people who go nuts about "unhygienic" macros and the like. Matter of fact, I think they are insane and fanatical because there is absolutel no _point_ in rebelling against macros. Just understand them. This is how it works. Deal with it. If you want to change the way they work, you definitely have to understand how they work today and all the discarded alternatives.
If you want _any_ system to change, exploit it, do not fight it. Exploitation causes people who see undesirable consequences of their goals to review their means of achieving them, perhaps even changing their goals. Fighting them causes people who are under attack to shut down all critical processes in self-preservation and defend themselves, regardless of the cost to their real goals. (Exploitation of (massive) incompetence, however, is so unethical only Bill Gates and his like could do it for a long period of time.a)
Now, how to exploit the system-fighters so they themselves implode? I think Guile is an excellent way to exploit the dislike of Common Lisp and the adherence to "simpler" ways to do things. With any luck, it turns into a _complete_ disaster before it has a chance of getting better.
> In what way do you feel that writing (serious) macros in CL > involves 'a lot of "fighting the system"'?
O.K. I take it you are an experienced macro writer.
(1) People like you and me have come to grips with the intricacies of macro writing, know the pitfalls and how to avoid them, and may even have the status of "macro guru". This is somewhat like Mel in the story (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 of a macro is very simple, yet it is not trivial for a novice to go and write good macros.
(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:
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).
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.
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. 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.
(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 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.
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 :-)
> "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"'?
> O.K. I take it you are an experienced macro writer.
> (1) People like you and me have come to grips with the intricacies > of macro writing, know the pitfalls and how to avoid them, and may > even have the status of "macro guru".
Pleas call me "eating guru". I eat every day. I even use that super cool tool called spoon.
If you call everyone who has learned to use something a "guru" then I think this word is overloaded (in the C++ sense).
> I think the very fact that there are macro gurus indicates that > there is a problem:
Could you please state once more for me what exactly is "macro guru"?
> the basic notion of a macro is very simple, yet it is not trivial > for a novice to go and write good macros.
It is not trivial for *anybody* to make something of quality without learning how to do it. Even if the tools are simple and have taken a lot of time to become such.
> (2) Macros are (or should be) about meaning one thing when you say > another
Macro is a tool -- the one that lets you, as a programmer, extend the language. It's not just a text replacing tool (although you may want use it as such). Looks like you want something and think it is macros but it ain't.
> 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 may be a kludge for you. It does not mean that it is a kludge for other programmers. It might also be that macros are not suitable for the task you want to use them for and thus may look like a kludge. Might be that you just have not learned and do not understand them.
If you have invented a way to make macros better please show it to us. I'm sure everyone here will appreciate it. Until then we're all using what has worked until now.
> There is a difference between 'the list function' and '(list ...)'.
Can't understand what you're talking about.
> CLtL2 has 'solved' the resulting problem by requiring that no > built-in function can be redefined, but that is of course a weakness > bid.
In what way it is a weakness?
If you write a program that uses LIST function and then someone else changes that function, how do you expect your program to work?
> Lisp has fought hard to get rid of (default) dynamic scoping, but in > macros this is still the default.
I'd say macros have no different scoping.
> If your macro references a variable X, it just grabs whatever X > happens to be available at the location where the macro is used.
Yes. And thats what it is supposed to do (although I don't like the term "grabs").
> 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.
I don't completely understand what you mean by "dynamic scoping for lambdas". But I can't see any guru phenomenon here.
> Normally you mean 'this variable' but have to write 'X', again not > quite the same thing.
Can't follow you without a piece of code.
> As with functions, lexical scoping (referential transparency) should > be the default, with an option for dynamic scoping.
Talking about language design?
I'd say -- if there's something missing in Common Lisp for you, go write it. But it would most probably require writing macros which don't quite understand.
> (3) So since the macro writer wants to state "whenever I say this I MEAN > that",
I'd say it's more like "whenever I say this I MEAN this".
> but the system wants to hear "whenever you say this, I should assume > that you SAID that", macro writing necessarily involves fighting the > system.
There's no fighting. The system does exactly what you tell it to do, according to The Standard.
> 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
Macros *are* a correct solution to correct problems. If you're afraid to familiarize yourself with the system it looks like your problem not Lisp's.
-- Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
> 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".
Let me start by clarifying that I am NOT complaining about anything, I was simply explaining why certain code was somewhat complex, and happened to use "fighting the system" in my explanation. In particular, I am NOT saying that anything should change.
"Janis Dzerins" <jo...@latnet.lv> wrote in message
> If you call everyone who has learned to use something a "guru" then I > think this word is overloaded (in the C++ sense).
I don't. I mean that people walk up to me, even though they are decent programmers, to have me get wrinkles out of their macro. Of if they don't walk up to me, I can often construct a context in which their macro doesn't do what they had intended it to do.
> Macro is a tool -- the one that lets you, as a programmer, extend the > language. It's not just a text replacing tool (although you may want > use it as such). Looks like you want something and think it is macros > but it ain't.
I know what a macro is, and how to write them. I was simply explaining what I meant with "fighting the system".
> If you have invented a way to make macros better please show it to > us. I'm sure everyone here will appreciate it. Until then we're all > using what has worked until now.
Of course. A lot of research is going on (more in the Scheme community than in the CL community as far as I am aware), but I don't think the final solution has been found yet. Obviously, until that happens we all happily go on hacking.
> > There is a difference between 'the list function' and '(list ...)'. > Can't understand what you're talking about.
About someone calling your macro in the context of an (flet ((list ..)) ..). CLtL2 saves you here, but if instead of 'list' it were a function you had defined yourself, you would still be bitten. Lexical scoping would have saved you here, would have allowed you to write a protected lexical scope that would also have saved you from redefinitions.
> In what way it is a weakness?
If doing something turns out to go wrong, and it can be fixed, I consider it a weakness simply to forbid doing it. It is a bit of brittleness in an otherwise sturdy language. I don't want to see CL turn into a "you cannot do that" language -- we have already enough of those.
> If you write a program that uses LIST function and then someone else > changes that function, how do you expect your program to work?
By wrapping a scope around your functions that protects the original definition of list.
> > If your macro references a variable X, it just grabs whatever X > > happens to be available at the location where the macro is used.
> Yes. And thats what it is supposed to do (although I don't like the > term "grabs").
..and that's dynamic scoping. An X in a lambda doesn't behave that way: it always refers to the X in the context in which the lambda was defined. I have been way too much in the discussion of dynamic vs. lexical scoping for lambda's, and endlessly heard exactly the phrase you use "And that's what it is supposed to do", and don't have the energy any more to go into that discussion, sorry. Nothing personal. You might want to check http://www.acm.org/pubs/citations/proceedings/lfp/62678/p86-bawden/ if you are an ACM member. (If you are not, you might find a working version of that paper at ftp://altdorf.ai.mit.edu/pub/scheme-reports/synclo.ps).
> There's no fighting. The system does exactly what you tell it to do, > according to The Standard.
In that case writing VB is no fighting either.. :-)
> (1) People like you and me have come to grips with the intricacies of macro > writing, know the pitfalls and how to avoid them, and may even have the > status of "macro guru". This is somewhat like Mel in the story > (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 > of a macro is very simple, yet it is not trivial for a novice to go and > write good macros.
How can you both invent _and_ lament the macro guru at the same time? There is no such thing as a macro guru. There are, however, macrophobes.
> (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:
Macros are in fact implemented as transformations. What you make of them is up to you. Ingenious use of macros can make some things very easy to understand. Idiot use of macros make things harder to understand. What else is new? Incidentally, every "should be" betrays an agenda. Before things "should be", study what they _are_. Your problem is that you started to "should be" before you understood how things are. (This has been evident for a long time, by the way.)
> 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).
So you choose to rebel against the obvious, and call things "kluge" that are simply means of achieving something you need. What else is new? Rebels _are_ usually clueless. This is how we do these things. If you do not like it, invent something better. Criticizing without improvement is just so much useless whining.
> 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.
Could you try to _explain_ your mindset instead of giving examples that make sense only to yourself?
> Lisp has fought hard to get rid of (default) dynamic scoping, but in macros > this is still the default.
Really?
> If your macro references a variable X, it just grabs whatever X happens > to be available at the location where the macro is used.
This is not what we call dynamic scope.
> 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.
When will it occur to you that _you_ are actually inventing the gurus?
> 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.
That _is_ the situation today.
FYI: people have written macros that hide the mechanics of "fresh variables". Those should arguably have been part of the language, but they are not, for whatever reason. So it is part of the oral tradition. Big deal. Learning to do anything well requires effort. If instead of learning you rebel against the effort, you will never do it well, and that itself will be an argument in favor of not doing it the way it should be done.
I submit that the way you have treated macros in Common Lisp is exactly the same way that turn people into criminals. Rather than understanding the existing set of rules and living within them, they break them out of sheer ignorance and arrogance, then the rules hit them back, because they are not quite as arbitrary as the whim of those who break them, and they get _another_ reason to break the rules: The rules are bad and they hurt you. If you want to break the rules, first you must understand them and then break them by achieving what they were intended to achieve better than the rules already achieve, such as by eliminating a negative side effect. Otherwise, there is no constructive element in breaking the rules, only destructiveness, and that is never appreciated, except possibly by others of the same rebel inclination.
> (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.
What if you got it all wrong? What if _you_ are fighting "the system" only because you have misuderstood what "the system" is doing and how it works?
> 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.
And the problem here is what?
> 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 :-)
An analogy to a skilled craftsman versus an unskilled craftsman comes to _my_ mind. Maybe that is because I happen to think that the idiotic attitude problem many people have towards lawyers is based in exactly the same willful and arrogant ignorance of "the system" that those who hate macros or Lisp in general suffer from.
This is only a problem with _your_ approach to macros, "Biep @ http://www.biep.org/". If you could bother to study how it works and try to learn to use it properly, you would probably be able to find a way to express what you need, just the way you want to express it. You see, the whole idea with macros is expressibility.
Simply put: If you do not want to learn the language, do not blame the language for your inability to express yourself in it.
> > If you have invented a way to make macros better please show it to > > us. I'm sure everyone here will appreciate it. Until then we're all > > using what has worked until now.
> Of course. A lot of research is going on (more in the Scheme > community than in the CL community as far as I am aware), but I > don't think the final solution has been found yet. Obviously, until > that happens we all happily go on hacking.
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.
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'.
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.
> 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.
> Let me start by clarifying that I am NOT complaining about anything [...]
Hmmm.
> I mean that people walk up to me, even though they are decent > programmers, to have me get wrinkles out of their macro. Of if they > don't walk up to me, I can often construct a context in which their macro > doesn't do what they had intended it to do.
Seems to me you are indeed complaining instead of solving the problem. If you know this stuff so well (which I have yet to see evidence of), either your communication skills towards the people you are helping is lacking, or they fail to learn enough from you. Write a paper on proper macro-writing and publish it. From what I have seen so far, you should expect criticism of your narrow view of their uses and purposes.
> I know what a macro is, and how to write them.
I am a fairly good marksman, and after having seen little improvement in my shooting in the past couple months, I worried to a fellow marksman, much, much better than me, that I had reached the apex of my skills. He looked amused and said he had experienced the same thing several times and always needed advice from better marksmen to change some of the things he did not think needed improvement, some of them rather dramatic. One of the great things about truly useful skills is that there is always more to learn. Optimization has the drawback that if you optimize the wrong way, for the wrong purpose, you end up being good at something that is simply _wrong_ to be good at. If you still insist on improving, you may in fact get worse to an objective eye, since you fail to reach the goal. (This part is fortunately impossible in shooting. It is such an easy way to get feedback.)
> Of course. A lot of research is going on (more in the Scheme community > than in the CL community as far as I am aware), but I don't think the > final solution has been found yet. Obviously, until that happens we all > happily go on hacking.
In my view, the final solution on macros has already been found. Scheme folks are continuing to "research" down the wrong path, as they have for many, many years. They are like the "doctors" of the past who thought illness was in the blood, and go on with their "research" despite the discovery of penicillin elsewhere.
> About someone calling your macro in the context of an (flet ((list ..)) ..).
The problems in Scheme are not the problems in Common Lisp. If a Scheme jerk does that in Common Lisp, he breaks the rules, written and unwritten and should not blame the language for his ignorance.
"Doctor, doctor, it hurts when I make this contorted movement." "So don't do it."
> CLtL2 saves you here
You know, one of the symptoms of your lack of sufficient effort is that you think CLtL2 is the authoritative reference. You may not be aware of this, but ANSI X3.226 Common Lisp has been issued, in fact was issued on 1994-12-15. It is now the authoritative reference on Common Lisp. You can find hypertext versions on the Net if you too cheap to buy the real thing from ANSI.
> but if instead of 'list' it were a function you had defined yourself, you > would still be bitten.
But why should the macro be using it? Obviously, the macro references an environment known to it, and draws on functions that are well-defined in it. If you change those with flets, you should be fully aware of the consequences. Incidentally, if you feel that this is such a drag, the rule that you should not redefine functions in the common-lisp package is not an arbitrary restriction. It is good advice never to redefine a function locally that has a global, _published_ definition. If you _do_ do so, it is for the obvious side effect that you blame "gurus" for.
Does this mean that the application programmer should be mortally afraid of screwing with somebody's names, like he would be in a one-namespace, no-packages language like Scheme? Not at all. Packages have published and unpublished symbols, mind you, so if you take care to review the published symbols in a package you have used, you follow the same rule for _any_ package you use as you do for the common-lisp package. Only the standard could not have mandated the same thing for your symbols as it does for the standard symbols.
I think the rule is really, really simple: If the symbol is not in your own package, be very cautious. Now, there are some "problems" with the package symbol in that it would have been lovely if the various values of a symbol could be treated differently, but this quickly leads to serious problems, too.
Some other languages require serious ownership protocols for objects. Common Lisp requires an ownership protocol for symbols, instead. The former are runtime concerns.. The latter are read-time concerns and should be covered by interprogrammer communication, a.k.a. documentation.
> Lexical scoping would have saved you here, would have allowed you to > write a protected lexical scope that would also have saved you from > redefinitions.
Really? Are you sure you understand what lexical and dynamic scope are all about? It sure looks like you have skipped a few classes on this.
> If doing something turns out to go wrong, and it can be fixed, I consider > it a weakness simply to forbid doing it.
An amazing attitude. How is this reflected in your view of society in general? Or are you one of those bondage-and-discipline programmers who want static type checking, class-owned methods, etc, too? If so, why do you bother with Common Lisp at all?
> It is a bit of brittleness in an otherwise sturdy language.
It is called "flexibility and responsibility". It can be bent, but if you bend it out of shape or break it, that is your responsibility. If you set up the rules so that you need never bend them, somebody else will feel imprisoned in your language. I can say right now that I would not use the language you think is so much better than Common Lisp.
> I don't want to see CL turn into a "you cannot do that" language -- we > have already enough of those.
Precisely, but you argue very strongly in favor of just that. Exactly like a politician who loves freedom as long as everybody does what he thinks is best for them. Freedom in a society is not a question of what you can do within the rules, it is a question of what happens to those who want to break or change the rules because they think the rules are wrong. Macros in Common Lisp makes it possible for freedom fighters to write their _own_ rules. Some people are incredibly emotionally opposed to such a concept, calling it "anarchy" and all sorts of negative things. I read you to be such a person.
> By wrapping a scope around your functions that protects the original > definition of list.
This may be done with a code-walking macro. Go write it.
> > > If your macro references a variable X, it just grabs whatever X > > > happens to be available at the location where the macro is used.
> > Yes. And thats what it is supposed to do (although I don't like the > > term "grabs").
> ..and that's dynamic scoping.
Bzzzzzt! Wrong!
> An X in a lambda doesn't behave that way: it always refers to the X in > the context in which the lambda was defined.
Which lambda are you talking about now? Are you perchance unaware of the effect of special declarations, which do in fact make real dynamic scope?
> I have been way too much in the discussion of dynamic vs. lexical scoping > for lambda's, and endlessly heard exactly the phrase you use "And that's > what it is supposed to do", and don't have the energy any more to go into > that discussion, sorry. Nothing personal. You might want to check > http://www.acm.org/pubs/citations/proceedings/lfp/62678/p86-bawden/ if > you are an ACM member. (If you are not, you might find a working version > of that paper at ftp://altdorf.ai.mit.edu/pub/scheme-reports/synclo.ps).
Precisely. You want syntactic closures. You can have that in addition to macros. You know how you can get that, do you not? If not, let me remind you of how to write macros: Use copy-symbol for all symbols referenced in the macro body, and refer to the uninterned symbols you have created. Pretty easy to do. I suggest you show us how to do it, since you (1) know how to write macros, and (2) need this. If you do not, I just conclude that you are one of those people who have a Scheme brain that cannot deal with Common Lisp. There are a lot of those in the Scheme community. It is one of the reasons I want such Scheme people to go to hell. Fortunately, they are doing it on their own, anyway. It is also one of the reasons I no longer consider Scheme a Lisp.
> 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.
