Subject: Re: Macro-writing in CL From: Erik Naggum <erik@naggum.net> Date: Thu, 07 Jun 2001 14:57:21 GMT Newsgroups: comp.lang.lisp Message-ID: <3200914634726937@naggum.net> * "Biep @ http://www.biep.org/" <reply-via@my-web-site.com> > 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 -- Travel is a meat thing.