rur...@xarch.tu-graz.ac.at (Reini Urban) writes: > Raymond Toy wrote: > >How would you tell such a compiler that you really do want variable > >capture?
> glad you asked that: then I would use a function, not a macro.
OK, write a function which allows you write code more or less like this:
(asetf (second list) (+ it 7))
The first parameter is a _place_, and the the second is an expression giving the new value for that place, where the the variable IT is captured to the old value of that place.
This example is from Paul Grahams book "On Lisp", by the way.
* Dorai Sitaram | Well, all right. FWIW, I am sorry you had all those harrowing | experiences with the Scheme community. What comes across very clearly in | your response is that you have this antipathy toward the Scheme | community, if not toward Scheme per se. Either kind of antipathy is OK. | I still think it is unfortunate to be enraged or seduced into silly | untruths because of that. Fighting fire with fire really works only for | the Fire Department. Out here it only adds to that "sociological mess" | that you feel burned by.
excuse me, but why should I feel any better about Scheme, now? you attack one of the most knowledgeable persons in _both_ communities for no reason at all. is this _another_ instance of "political correctness"?
tell you what: I want to write nice, working programs that don't take forever and to use as much of the legacy of mankind as possible in the process. that's why I can't stand Scheme, which makes me feel like I have been given exquisitely shaped flint stones and a beautifully prepared coat made from a bear's hide, and then I have to re-invent everything from there, which will neither be exquisite nor beauitiful because I don't have 40,000 years to reinvent everything from where Scheme left us in anything but rough ways. since Scheme people tend to be extraordinarily proud of their hand-made bear coats and swing flint stones like no one has ever seen and then challenge everyone they meet to compete with them on such terms, especially Common Lisp people, I also find little reason to frequent Scheme communities. when you arrive with your own neanderthal attitude, Dorai, I tend to think that Scheme people should be left alone, possibly relocated to a reservation, but let's make sure we don't leave any metal ores nearby. there's no telling what would happen if the Scheme community discovered bronze, or god forbid, iron. but at least you're _incredibly_ hygienic and elegant, and I, too, admire your fine flint stones, as long as I don't have to use them for anything.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
In article <sfw671jshxw....@world.std.com>, Kent M Pitman <pit...@world.std.com> wrote:
>[grievances deleted because they can't be justly summarized]
OK, I guess you don't have an antipathy to the Scheme community after all. :->
I wasn't asking you to be polite or not to flame. I was asking you not to contribute to misunderstandings, especially since you seem dedicated to removing them. That's all.
I sense an attempt ("this is one of them", "two sides", etc., etc.) to locate me in your standard catalog of obstreperous rants by the Scheme community. If you are not, I am grateful. I have already twice expressed my dignified sympathy, and I frankly don't know what else anybody can do when faced with this kind of extended regurgitation of grief.
If, on the other hand, you are indeed locating me in that noisome catalog of yours, at least there is some comedy value to it. Nothing in my two articles can or should be taken as a brief for Scheme in general or hygienic macro systems in particular. Indeed, I quite agree with you that developments in Scheme have made it seem to some that hygienic macro systems are necessary when they aren't really. I am just saying that having one or two or many namespaces has no valid bearing on which way one chooses to jump on the hygiene issue. That, it would appear, is our only disagreement, or maybe even not -- I am fast losing track of what you're trying to say because you are getting way too discursive.
* Reini Urban | using macros just not to evaluate one of its arguments is lame. | lambdas are better.
then why don't you just program in Scheme? sometimes, I think the Lisp1 vs Lispn thing really _is_ about doing things one way or one of n ways.
what I really _don't_ understand is why Scheme freaks need to _prove_ Kent's points. it would seem much more rational to work very hard to _disprove_ all his claims.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
William Deakin <wi...@pindar.com> writes: > Raymond Toy wrote:
> > How would you tell such a compiler that you really do > > want variable capture?
> what about (declare (capturable mungo mongo midge))? ;)
This would get my vote (if I thought the compiler had to be told anything at all; as I've said, I'm not much of a mind that CL needs hygiene but if it did, this would be a good way to specify thing).
A principle of language design that I endorse generally is that the number of words you should have to say in order to communicate an idea to the compiler should usually be about the same as you'd have to say to someone over the phone or out loud to someone over dinner in order to unambiguously communicate the same concept. To the extent that you have to say materially more, it's often a cue that the language designers have not done their job very well.
Although it's not a "language" per se, I have to say that the typical verbiage you have to say to C++ (and most other languages) to get an "object foothold" in CORBA is a good example of someplace where the total number of words is hugely more than the number of words that should be required. For some reason, little boilerplate pieces of code like this seem to get turned into templates to be pasted in by programmers of other language, and reveled in, rather than as so often in Lisp, turned into macro expansions never to be seen again by humans. I don't know why that is, but I often liken it to the trappings of chemical addiction, where people are said to really get into the whole business of preparing their fix as much as the actual actual taking of the drug (whether it be opening the box of cigarettes and tapping it just so and smelling it and so on, or whatever more elaborate thing for other drugs). People are just creatures of habit and seem to gravitate toward systems that provide them with mounds of predictable if drugerous business.
I dunno--maybe fighting the monotony that other systems serves up just means users spend their life forever unpredictably stressed by new technologies and maybe and we shouldn't fight it and should just let them mire themselves in familiar, if monotonous, drudgery. But for some reason I always focus on the idea of digging out of those monotonous activities to find the new monotonous activities that await once you get used to what's beyond...
d...@bunny.gte.com (Dorai Sitaram) writes: > I wasn't asking you to be polite or not to flame. I > was asking you not to contribute to misunderstandings,
If you go back and re-read the conversation, I think you will see I attacked no one. It's possible that your gripe is that in fact I did attack no one since then that person would be morally empowered to defend him or herself. However, I was responding only in kind to a prior message which spoke about a general problem without specifics as well, and I was doing my best to speak at the level of abstraction already introduced and in the context already introduced.
Looking over my original message, the only statement I can think of which I made which might be controversial was this one, which you chose to respond to by attacking me pesonally rather than by merely addressing the technical statement I made:
kmp> They are only really unsafe in Scheme, which has no package kmp> system and only one namespace.
In defense of this remark, my use of the word "unsafe" was merely following in the same literature that the Scheme community has used this term in macros. There is a technical sense in which "unsafe" means "capable of accidental capture" and that's a true and defensible claim. If you want to add additional remarks saying that you have other experiences, you're welcome to, but don't say I'm contributing to confusion merely by restating the problem in a way that is faithful to the original statement of the problem by the community that originally established the issue. Further, it is true that Scheme has no package system--it has a module system. And it is, like it or not, a common oversight by people from the Scheme community who are unused to the package system to say you can't write a macro that will avoid capture problems when in fact, it's trivial to write a great many macros that will avoid this if you just have either GENSYM or else MAKE-PACKAGE and INTERN. So I don't see how I was contributing to a confusion by saying this.
The remainder of my message aws:
kmp> Macros are not generally unsafe in Lisp.
This statement is true and supported by lots of actual practice. It does not, in my opinion, contribute to any misperception or confusion.
kmp> Lisp has used its simpler macro system with great success and kmp> very little problem for many years and unintentional variable kmp> capture doesn't require anything as sophisticated as a special kmp> defsafemacro.
This statement also seems true to me even in hindsight.
kmp> This is a common misperception about Lisp which people carry kmp> in from Scheem.
This statement seems true to me. It is a common misperception. I wanted, as I often do, to take the incident of this message to highlight the issue so that people could watch for it and catch it when they see it rather than let it go by. I don't see how watching for something makes for any confusion or misperception. I have a lot of rules that say to "watch for something" in my head; that doesn't mean I take an explicit action upon seeing them--I'm not advocating dogma here. I'm advocating kicking this out to "conscious thought" and not working on "autopilot" when statements of this kind are seen.
kmp> People need to understand that problems always exist in a kmp> context.
It's hard to see how this contributes to a misperception or confusion.
kmp> Moving to a new context requires reevaluating the issues kmp> in the new circumstances, not just assuming they carry over.
Ditto.
That concludes the entirety of my message which you chose to single out an request I ""not [...] contribute to misunderstandings" with. I stand by my claim that I did not. And further I stand by my claim that if there was or ever is a misunderstanding in what I say, the right thing is simply to address it at the appropriate technical level. I think I have an established record of acknolwedging errors and confusions in what I've said, or even of acknowledging legitimate points of view that I happen not to agree with. I see no reason to get personal.
> especially since you seem dedicated to removing them.
I am dedicated to identifying them. Removing them seems to me like fixing the "delete bug"--I don't have pointer access to really do it, so why try?
> That's all.
> I sense an attempt ("this is one of them", "two sides", > etc., etc.) to locate me in your standard catalog of > obstreperous rants by the Scheme community.
I did not originally locate you in anything. The reply was originally to Reini and the subject of the sentence in question was the idea, not the community. I did not attribute the idea to everyone in the community, I said the origin of the offending idea was the community. Communities are large and pluralistic; no idea that is "of them" is "of every individual within them". Nevertheless, it can be useful to understand the reason for a confusion, and since the reason for this particular confusion (about hygiene) is based in specific technical details of the things those people do every day (they really do play with single namespaces and they really do play with lexicality a lot), it seemed appropriate to mention the context in order to support my real point which was that context can influence one's perception of reality. And that is a point I don't want to detract from in this long discussion of what is politically right and wrong to say because it hurts someone's feelings who I never said I wanted to hurt.
> If you are not, I am grateful.
I am not trying to single out you or anyone to feel bad. I hate it when people do that to me, and I don't do it to others.
> I have already twice expressed my > dignified sympathy, and I frankly don't know what else > anybody can do when faced with this kind of extended > regurgitation of grief.
I don't expect more of you. These remarks on my part are simply to make sure my point is clear on the record since you have in spite of your staements of sympathy also herein included additional remarks about me which I felt required a reply. This will be my last detailed statement on the social nature of this since I've pretty much established my position on my original remarks, and since I don't plan to play Zeno's Paradox with you, dissecting this conversation into infinity.
> If, on the other hand, you are indeed locating me in > that noisome catalog of yours, at least there is some > comedy value to it. Nothing in my two articles can or > should be taken as a brief for Scheme in general or > hygienic macro systems in particular.
Nor should anything in my "articles" be taken to say there is anything wrong with Scheme having those. For reasons probably personal to me, and perhaps not general to others, I personally find the Scheme macro system painful and ugly, and I never myself use it. But I know others that do use it, and I certainly use macros others have written, and I'm sure that as a matter of technical workmanship and design it's a fine thing. (My personal quibbles with it are philosophical, not practical.) I assume someone must like it because it's there. I'd have gone for syntactic closures, myself, in the context of Scheme. And I'm happy to do my macro programming in CL where the issue just doesn't arise...
> Indeed, I quite > agree with you that developments in Scheme have made it > seem to some that hygienic macro systems are necessary > when they aren't really. I am just saying that having > one or two or many namespaces has no valid bearing on > which way one chooses to jump on the hygiene issue.
I think this isn't so, but recognize the right of others to disagree on this as a technical matter. I base my belief in part on the technical matter of Lisp1 and in part on the nearly-consequential sociology that emerges from the technical choice. As a matter of observed sociology, I think it does matter. Science does not recognize "my hunches" or "my gut feelings based on personal societal observation" as a proper scientific method of analyzing data per se, so I forgive you for disagreeing. But on the other hand, Science does not say that everything it rejects on the basis of lack of evidence is false, so please forgive me for believing that the namespace issue matters even though you don't think so.
I have written a long post on this a long time ago, and you may be able to find it on deja news. I promised Erik a long time ago that I would write this up as a real article that I could reference but never have done so. I'll keep trying to find the time. But it's not that I've never spoken in detail on it. I just picked a bad forum. (please no residual converation about my having called comp.lang.lisp a "bad forum" :-)
> That, it would appear, is our only disagreement, or > maybe even not -- I am fast losing track of what you're > trying to say because you are getting way too > discursive.
> excuse me, but why should I feel any better about Scheme, now? you > attack one of the most knowledgeable persons in _both_ communities for no > reason at all. is this _another_ instance of "political correctness"?
> tell you what: I want to write nice, working programs that don't take > forever and to use as much of the legacy of mankind as possible in the > process. that's why I can't stand Scheme, which makes me feel like I > have been given exquisitely shaped flint stones and a beautifully > prepared coat made from a bear's hide, and then I have to re-invent > everything from there, which will neither be exquisite nor beauitiful > because I don't have 40,000 years to reinvent everything from where > Scheme left us in anything but rough ways. since Scheme people tend to > be extraordinarily proud of their hand-made bear coats and swing flint > stones like no one has ever seen and then challenge everyone they meet to > compete with them on such terms, especially Common Lisp people, I also > find little reason to frequent Scheme communities. when you arrive with > your own neanderthal attitude, Dorai, I tend to think that Scheme people > should be left alone, possibly relocated to a reservation, but let's make > sure we don't leave any metal ores nearby. there's no telling what would > happen if the Scheme community discovered bronze, or god forbid, iron. > but at least you're _incredibly_ hygienic and elegant, and I, too, admire > your fine flint stones, as long as I don't have to use them for anything.
I have no problem with this kind of characterization of Scheme. Scheme is indeed unusable for many, nay, most purposes. As I said earlier, my response to Kent is not a defense of Scheme or the Scheme community at all. Heck, it is not even a defense of hygienic macro systems.
Something very strange is going on in this thread.
* Reini Urban wrote: > glad you asked that: then I would use a function, not a macro. > functions should have distinctive variables. > macros just placeholders, they should not infect others. > (100% unintentional) > using macros just not to evaluate one of its arguments is lame. > lambdas are better.
Presumably you'd weaken this in the case where the name came from the user, or you rule out most of the WITH-x macros (and, in a slightly alternative universe, you rule out LET too...).
Taking a naming cue from Harlequin in an attempt at consensus building, Eclipse calls this WITH-UNIQUE-NAMES. (Note that with-unqique-names/with-gensyms is a little different than William's hygenic-let example.)
Here's a definition for both. (I'm with Erik on the issue of having macro-generated symbols use the names provided by the programmer. You can disagree and use GENSYM if you like.)
A smile-and-a-handshake to anyone who can lucidly explain (no pun intended) WHY the REBINDING code works, or conversely, convince me that it doesn't.
(defmacro WITH-UNIQUE-NAMES (vars &body body) `(let ,(loop for var in vars collect `(,var ,(copy-symbol var))) ,@body))
(defmacro REBINDING (vars &body body) ;difficult code here!.. (loop for var in vars for name = (copy-symbol var) collect `(,name ,var) into renames collect ``(,,var ,,name) into temps finally (return `(let ,renames (with-unique-names ,vars `(let (,,@temps) ,,@body))))))
> > On Wed, 08 Sep 1999 20:10:23 GMT, Reini Urban wrote: > > >Stupid subject line.
> > Grin.
> > >But reading the Tanksley-Joswig talk, Tanksley complaining about the > > >semantic problem with macros, I thought why not writing a compiler which > > >can automatically rename such captured vars in a new special form, > > >defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown > > >away then :)
> > No! Anaphor is a powerful thing, and any change to avoid its bad effects > > would also destroy its good ones (and thus obsolete all macros).
> > Lisp doesn't need to be changed to avoid accidental symbol capture. All > > you have to do is define and use a very simple macro, let's call it > > "hygenic-let", which uses 'let' and 'gensym' to create new variables which > > will shadow the old ones.
> > An example of its usage would be:
> > (defmacro duh (x y z) > > (hygenic-let ((i 1) (j 2)) > > (do-things i x y z) > > j))
> > Make sense? This has just declared i and j to be hygenic -- secretly, > > it's replaced every use of i and j with a new gensym.
> > 'On Lisp' defines this macro, IIRC, but I don't remember what it > > called it.
> > >No really, a decent compiler should be able to do the static analysis of > > >possible variable captures in special macros and rename/gensym them. > > >(Letting dynamic creation of such DEFSAFEMACRO's aside.)
> nod. INLINE is supposed to do this (no comments about any particular > implementations). this also barring the effect of SETF not > escaping the scope of the function problem.
> -- > J o h a n K u l l s t a m > [kulls...@ne.mediaone.net] > Don't Fear the Penguin!
On Fri, 10 Sep 1999 13:33:26 GMT, Reini Urban wrote: >Raymond Toy wrote: >>If your compiler is smart enough to know when NOT to gensym something, >>then surely it would be smart enough not to waste resources and >>performance when you DO gensym everything. >>How would you tell such a compiler that you really do want variable >>capture? >glad you asked that: then I would use a function, not a macro. >functions should have distinctive variables. >macros just placeholders, they should not infect others. >(100% unintentional)
I don't see how a function would be able to 'infect others'. As far as I can see, only special forms and macros can do that.
Other than that, though, I would have designed the macro system as hygenic, but with provision for anaphora. Perhaps this would make it non-Lisp; if so, we can all be thankful that I am doing no such thing, nor will I.
>using macros just not to evaluate one of its arguments is lame. >lambdas are better.
You mean for lazy evaluation? That doesn't have anything to do with symbol capture or anaphora.
Macros lack some of the characteristics of functions in Lisp. It might be interesting to design a variant in which they had some of those properties. I can already see how to design such a variant of Forth, although it would require a better memory management system than Forth currently has (it would also be very unForthlike).
I'm not going to even think about it, though -- reading On Lisp has given me a lot better feel for Lisp, but I'm not that much in touch yet with what makes Lisp Lisplike :).
On Fri, 10 Sep 1999 17:03:25 GMT, Kent M Pitman wrote: >d...@bunny.gte.com (Dorai Sitaram) writes: >> I wasn't asking you to be polite or not to flame. I >> was asking you not to contribute to misunderstandings, >If you go back and re-read the conversation, I think you will see I >attacked no one.
I don't see him as claiming that -- a flame usually doesn't contribute to misunderstandings, but rather causes altogether too much understanding. :(
>It's possible that your gripe is that in fact I did >attack no one since then that person would be morally empowered to >defend him or herself. However, I was responding only in kind to a >prior message which spoke about a general problem without specifics as >well, and I was doing my best to speak at the level of abstraction >already introduced and in the context already introduced.
I found your post interesting, since I had taken a contrary position; at the same time, I don't believe that you established your point, especially since rather than proving that the problem doesn't affect Lisp or can't be considered as a problem, you merely stated that as truth and then attempted to impugn Scheme as having other problems.
>Looking over my original message, the only statement I can think of >which I made which might be controversial was this one, which you >chose to respond to by attacking me pesonally rather than by merely >addressing the technical statement I made: >kmp> They are only really unsafe in Scheme, which has no package >kmp> system and only one namespace. >In defense of this remark, my use of the word "unsafe" was merely >following in the same literature that the Scheme community has used >this term in macros. There is a technical sense in which "unsafe" >means "capable of accidental capture" and that's a true and defensible >claim.
This would be entirely true if Scheme's macro system were unhygenic -- but it isn't. Its hygene is an essential part of its construction, more so than Lisp's package system is part of its macro system (if I may make the ridiculous comparison).
>If you want to add additional remarks saying that you have other >experiences, you're welcome to, but don't say I'm contributing to >confusion merely by restating the problem in a way that is faithful >to the original statement of the problem by the community that originally >established the issue. Further, it is true that Scheme has no package >system--it has a module system. And it is, like it or not, a common >oversight by people from the Scheme community who are unused to the package >system to say you can't write a macro that will avoid capture problems >when in fact, it's trivial to write a great many macros that will avoid >this if you just have either GENSYM or else MAKE-PACKAGE and INTERN. >So I don't see how I was contributing to a confusion by saying this.
It's ridiculous, obviously, to claim that it's impossible to write a safe macro in Lisp. GENSYM makes it all possible. The "problem" is that a safe macro is a very complicated macro. My ideal would have safety be the default, and anaphora require a brief workaround (certainly nothing complicated).
However, this is somewhat of an aesthetic judgement, and after spending some time with Scheme, I have to agree that aesthetics are not the best judge of language power.
>The remainder of my message aws: >kmp> Macros are not generally unsafe in Lisp. >This statement is true and supported by lots of actual practice. >It does not, in my opinion, contribute to any misperception or confusion.
It's true in the sense that macros can _always_ specifically be made safe in Lisp.
>kmp> Lisp has used its simpler macro system with great success and >kmp> very little problem for many years and unintentional variable >kmp> capture doesn't require anything as sophisticated as a special >kmp> defsafemacro. >This statement also seems true to me even in hindsight.
I have a problem with it. Please help me correct my problem.
You say that Lisp's macro system is "simpler". Presumably you mean simpler than Scheme's, or perhaps simpler than defsafemacro. Yet it seems to me that in order to make safe macros in Lisp, you have to be immensely more careful and knowledgable about some huge complexities than you have to be in Scheme.
>kmp> This is a common misperception about Lisp which people carry >kmp> in from Scheem. >This statement seems true to me.
It certainly seems accurate to me -- I came in from Scheme, and I have that perception. I'd still like to know why it's wrong, although I certainly don't insist on it. I'll be spending plenty of time with Lisp -- it's a better language than Scheme, no doubt.
>It is a common misperception.
I'd _love_ to hear why it's false. I hear you describing how Scheme would be dangerous without hygenic macros, and I believe it. I read "On Lisp"'s discussion of how Lisp is dangerous without careful attention to every symbol, and I believe that. Hygenic macros cause me no effort and don't add to my code's visual complexity; watching and guarding every symbol does.
Note that I'm not contradicting you, merely describing my own feelings about my experiences.
>kmp> People need to understand that problems always exist in a >kmp> context. >It's hard to see how this contributes to a misperception or confusion. >kmp> Moving to a new context requires reevaluating the issues >kmp> in the new circumstances, not just assuming they carry over. >Ditto.
It's clear that I need some help in doing that reevaluation. If I don't get it, I'll still stick with Lisp, so no pressure.
>That concludes the entirety of my message which you chose to single out >an request I ""not [...] contribute to misunderstandings" with. I stand >by my claim that I did not. And further I stand by my claim that if there >was or ever is a misunderstanding in what I say, the right thing is simply >to address it at the appropriate technical level. I think I have an >established record of acknolwedging errors and confusions in what I've said, >or even of acknowledging legitimate points of view that I happen not to >agree with. I see no reason to get personal.
Again, I think his offence was mainly to your attacks against Scheme, which were made as though Scheme didn't have a hygenic macro system.
You may not have contributed to misunderstandings (although I'd say that calling Scheme's macro system hazardous is a misunderstanding). You certainly, however, did nothing to remove any of those misunderstandings -- you merely called them out as such.
I can see how that would be insulting to many people who held those misunderstandings as though they were facts -- a discussion of why their opinion was a misunderstanding would be interesting, but simply calling it a misunderstanding isn't.
Is there a web page on this? Or does "On Lisp" have something about it?
Kent M Pitman wrote: > The thing that I value the most about CL and > its community is its ability to embrace multiple concepts and multiple > ways to think about things;
Well, since R5RS Scheme has had multiple values too, so perhaps things are getting better in that camp. :-)
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
In article <sfw1zc6lmw2....@world.std.com>, pit...@world.std.com says...
> kmp> They are only really unsafe in Scheme, which has no package > kmp> system and only one namespace.
> In defense of this remark, my use of the word "unsafe" was merely > following in the same literature that the Scheme community has used > this term in macros. There is a technical sense in which "unsafe" > means "capable of accidental capture" and that's a true and defensible > claim. > [...] > The remainder of my message aws:
> kmp> Macros are not generally unsafe in Lisp.
> This statement is true and supported by lots of actual practice. > It does not, in my opinion, contribute to any misperception or confusion.
I beg your pardon, but using what appears to be two definitions of "unsafe" contributes to confusion.
Of course a Lisp programmer always uses gensym where appropriate to write a safe macro; thus also with Scheme, as any environment with defmacro will also have gensym. (If the Scheme lacks defmacro, how can it be unsafe? Unuseful, maybe, but unsafe?)
So they're either both "unsafe" (with quotes - the "capable of accidental capture" defn), or they're both "safe enough."
[I know that you're going to to respond "I know, I know - look, I was hacking on (NOT NIL) when you didn't know a LABELS from a LAMBDA." This is about contributing to confusion, not educating Kent. I am here to learn from Kent, not educate him. Obviously. So enough confusion already.]
> * Johan Kullstam > | graham called it WITH-GENSYMS
> I have found COPY-SYMBOL to be superior to GENSYM in that the symbols > produced have understandable names, which helps a lot when looking at the > expansion and at the produced code.
I'm curious why you find COPY-SYMBOL better than GENSYM with an optional argument. It would seem that if you ever have nested macros that use the same names, it would not be possible to distinguish the names produced by COPY-SYMBOL, since they would print the same. At least with the GENSYMs, you can expect that two instances of #:COUNTER-4569 actually refer to the same variable.
-- Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Howard R. Stearns wrote: > (defmacro WITH-UNIQUE-NAMES (vars &body body) > `(let ,(loop for var in vars > collect `(,var ,(copy-symbol var))) > ,@body))
Aren't you missing a "'" before the second "," on the third line?
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
> Of course I know "On Lisp" and the scheme macros which suffer from the > Lisp1 decision.
> But reading the Tanksley-Joswig talk, Tanksley complaining about the > semantic problem with macros, I thought why not writing a compiler which > can automatically rename such captured vars in a new special form, > defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown > away then :)
I feel like I am missing something important here, so I have to ask: What is the semantic problem with macros that you are referring to?
* Ben Goetter | Of course a Lisp programmer always uses gensym where appropriate to write | a safe macro; thus also with Scheme, as any environment with defmacro | will also have gensym. (If the Scheme lacks defmacro, how can it be | unsafe? Unuseful, maybe, but unsafe?)
as I understand this, Scheme cannot generate symbols on the fly in code in the first place, since the language is not defined in terms of sexprs, but in terms of a grammar with a lexical analysis phase, and that it wouldn't help with _possible_ conflicts, since there is no concept of "uninterned symbol" (due to lack of a package concept), they do such things with LAMBDA and its "renaming", anyway, which is lexical, and if Scheme had had DEFMACRO, it would have been tremendously dangerous, since it couldn't possibly be safe in Scheme, lacking all the machinery.
at key here is understanding the Scheme community's attitude towards DEFMACRO in Common Lisp. simply put: they don't understand it, because they lack the concepts to deal with what which makes macros safe in CL. lack of concepts usually leads to an incredible amount of confusion, but the Scheme community has voluntarily rejected a number of concepts, which for a number of reasons they can't go back on, and having to do so would in turn cause massive upheaval. thus the emotional intensity. Scheme has reached its evolutionary apex, and anything you can do from here on will be perceived to reduce the language. this is OK by me, actually, since I think Scheme is hurting the Lisp community every time a Scheming bastard tries to pass Scheme off as "Lisp" sans qualifications.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
>> That's why I thought it should be done automatically. hmm... Not easy for >> dynamic lisps like elisp or autolisp. William wrote: >Yup. But does that make CL wrong?
not wrong, only worse than it could have been.
>Maybe elisp or autolisp should be lexically scoped. Join the 90's &c :)
that's a different story. <sigh> it's hard to maintain backwards compatibility with millions's of "dynamically scoped" (i know, this is a wrong term) legacy code. with new keywords no problem. but scope is not the problem. well, in my case it makes things worse because ALL possible candidates may "infect" the var (placeholder) in the macro, not just the lexically visible.
>> Looks like that I have to patch a CCL copy just for fun, to see if it >> makes sense to me.
>What is a CCL?
Corman Common Lisp
>> (my local newsfeed is a mess nowadays. 10-20 hours for this... >Bad news :(
I complained and the news admin rebooted the machine. It seems to be much better now. Sometimes and in certain fields complaining DOES make sense :)
-- Reini _NSAKEY ist mir schon gar nicht mehr wurscht.
Reini Urban wrote: >> But reading the Tanksley-Joswig talk, Tanksley complaining about the >> semantic problem with macros, I thought why not writing a compiler which >> can automatically rename such captured vars in a new special form, >> defmacro-alike. something like DEFSAFEMACRO. "On Lisp" could be thrown >> away then :) Dobes Vandermeer wrote: >I feel like I am missing something important here, so I have to ask: >What is the semantic problem with macros that you are referring to?
that macros are quite unreadable and maintainable. take a look at "On Lisp" or the typical macros. and compare this to scheme macros or with-gensym approaches. the rest of my complain was only about efficiency. how to improve with-gensym, not to gensym every var, only those which are needed.
secondly, I do care about newbie's (the AutoLISP crowd) who should be able to understand a macro system (easy) and write correct code then (hard). semantics are very important for newbies.
another story with semantics is nested backquoting. but better have the ` than doing it explicitly. I know this. I don't even have ` and , not macros in AutoLISP, so I have to write the expansion explicitly (once) and have to read this mess (every day). ` comes best to what one could expect for a decent language. -- Reini Urban http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
>> What I don't like with user-defined gensyms in macros is >> unreadability, hard to write and somewhat knowing in advance >> which vars can get captured. (really every?)
>I don't see why it's hard to know this. If the macro expands into >something that binds variables, you need to make sure those variables >have unique names, unless you intend them to be visible in the >expansion (which is surprisingly often the case).
>> Of course you can gensym all your vars in the macro, but this might >> be a waste of resources (and performance).
>I can't imagine a realistic case where it has any significant impact >on either, unless you have a really slow compiler.
With my compiler (Visual Lisp) I see the difference, because it has to deal with a dynamic lisp (all vars are global!), and cannot "localize" (stack-allocate) somewhere globally used vars. (not only those in lexical context). The performance lost is measurable and annoying in my libraries.
Gensym'ing all those candidates is slow because gensym is the same hack as in elisp, interning concatenated strings explicitly, in the global enviroment. The compiler is not slow but the resulting code. With proper compiler analysis it can be improved dramatically in my case.
If it would matter in a decent common lisp implementation I may doubt as well. Gensym should be fast enough there. esp. because it is only created in lexical context, so stack-allocated.
Erik Naggum wrote: >* Reini Urban >| using macros just not to evaluate one of its arguments is lame. >| lambdas are better.
> then why don't you just program in Scheme? sometimes, I think the Lisp1 > vs Lispn thing really _is_ about doing things one way or one of n ways.
this has nothing to do with multiple or singular namespaces.
> what I really _don't_ understand is why Scheme freaks need to _prove_ > Kent's points. it would seem much more rational to work very hard to > _disprove_ all his claims.
i'm no scheme freak at all. i prefer lisp by far. (besides demanding tail-call-elimination, but practice is different) i'm with kent. his claims are rational and politically correct.
my purpose was not to attack common lisp. only to ask how to improve macro semantics and performance (which are an unsolvable problem and a non-existing problem, i know). -- Reini Urban http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Tim Bradshaw wrote: >(and, in a slightly alternative universe, you rule out LET too...).
You know, I've always had a bad feeling about LET too :)
I cannot create bindings just for debugging purposes by marking the binding form with the mouse and evaluate it. With the let syntax this is impossible. With &aux and following setq's it is possible.
and here you caught me again: (sorry, if someone caught me wrong before. this is nothing against lisp, only another newbie question)
let* and efficiency i really don't know if the expansion of LET* (into to nested lambdas) is a good thing or if it should be a special form instead, which can bind in sequence internally without having to call nested lambdas. lambda might have some overhead which is not needed in the context of LET*. (?) but I might be wrong. binding in sequence might require a full LAMBDA to be correct. (I don't have SICP or WINSTON/HORN here in the office to prove it by myself, so I have to sleep over it) -- Reini Urban http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
>>>>> "EN" == Erik Naggum <e...@naggum.no> writes:
EN> lexical, and if Scheme had had DEFMACRO, it would have been EN> tremendously dangerous, since it couldn't possibly be safe in EN> Scheme, lacking all the machinery.
Gambit Scheme has no hygienic macro system built-in; it does however have a DEFMACRO-like system with gensym and all the necessary machinery. This is essentially no more a problem[1] than it is in CL (and in my opinion, this means not a problem at all.).
Also, in the R5RS under 6.3.3, Symbols: "Some implementations have 'uninterned symbols' ...".[2]
The 'problem of unintentional capture' still remains if you accept, as some must have done, that the possibility of this is a problem in and of itself, of course, and given that DEFINE-MACRO (which is the DEFMACRO-in-scheme) fails to solve this problem, then it is unsafe in the technical sense mentioned. It's pretty clear that this is the unsafety (is that a word?) deemed problematic, and not just inside of Scheme, I think, whether or not it was seen to be more problematic there. Then again, there are other (technical, percieved) problems solved by the Scheme systems, and having programs be other than s-expressions is one of them[3] - useful for doing Dylan at least... I probably need some emoticon here to avoid being roasted. "%/&. Oops. Well, anyway.
The program-as-text thing of the RnRS is pretty strange though; I've never seen any real argument of why it's supposed to be a good idea[4]. It does of course complicate the whole concept of macros, but what really puzzles me is eval, 6.5.5: "/Expression/ must be a valid Scheme expression represented as data, ..." Hm.
Personally, I really like real, DEFMACRO-style macros, with programs represented as sexps and with the full language available for transforming them. It's much simpler to explain and understand and to *implement* for one thing - hygienic macros have been around for a long time, but people haven't really rushed to implement them in any kind of lisp. DEFMACRO obviously isn't a safe-syntactic-abstraction-Right -Thing all by itself, but it seems pretty Right-Thingish anyway, given what it can do.
Footnotes: [1] There are obviously more ways in CL than in Gambit for avoiding name conflicts, but the ones present in Gambit are sufficient, given care. I accept that CL would require less care, or tolerate more carelessness.
[2] With 'uninterned' quoted, and no explaination of what interning a symbol might mean. It guess it really helps to understand Lisp if one wants to understand Scheme.
[3] The other ones I've found mentioned has been a more restricted form of transformations (especially not allowing side-effects) and making macros easier to write and/or read, meaning macro-by-example. I've found these last two desiderata really, *really* frustrating when trying to use the recently standardized system for anything a bit complicated. Macro-by-a-really-big-lot-of-examples-with-some-bits- missing-and-a-nifty-trick-involving-the-string-"snork".
[4] I've read H.Bakers paper about why it is a really bad idea, though (Critique of DIN Kernel Lisp) and that seemed pretty much like the last word on the case for me. So perhaps I just didn't get it.
rur...@xarch.tu-graz.ac.at (Reini Urban) writes: > my purpose was not to attack common lisp. only to ask how to improve > macro semantics and performance (which are an unsolvable problem and a > non-existing problem, i know).
There is nothing wrong with macro semantics in CL. What is there is sound, it just works by different principles than does the Scheme mechanism. Principles that are appropriate and natural to the CL context, where people are pervasively used to implementing separation of modularity using difference in symbol names by packages.
The reason I object to the use of the phrase "improve macro semantics" is that it implies an incremental refinement to the CL mechanism, which would not "improve" the semantics. An incremental refinement would add a layer atop what is there but would not change what there is, and so would be no more nor less semantically strong than what was there because it would not change its degree of semantic goodness.
It sounds to me like you mean either "change macro semantics" which would improve some things while breaking everything else (and CL relies to a huge extent on macros in very fine detail) or else what you are asking for is a "syntactic", not "semantic", change.
In the former case, you are violating an explicitly stated principle of the language design, which is stability and a focus on tried-and-true and well-accepted techniques [and I shouldn't have to say this, but that has to mean "tried WITHIN the context of CL" not "tried for some other community"--saying that Scheme-style macros have been "tried" would be disingenuous and in violation of accepted scientific method. No controlled experiment has been tried rewriting substantial large-scale systems that are heavily based on CL-style macros to see if they could as easily be written using the Scheme macro system, for example, nor have communities been given the option of both systems in a test environment to see which they flock to].
In the latter case of my two from above, where the problem is merely one of "syntactic sugar" on the existing macro system semantics, which I'm assuming it more likely what you mean even though you're calling it "improving macro semantics", the existing macro system, with its present syntax and semantics, is capable of accomodating a syntax-only change without any underlying change to what others are doing, just by getting your own package and defining an appropriate macro that people can use or not use as they like. Which if you do will also prove my point that there was nothing semantically wrong with the existing macro system.
I'm really not big on the whole "semantics" thing as a field of study--to me, the definition of semantics is "means something intelligible that I can write a compiler for"; I just can't read and have little use for all that icky math at the back of the Scheme spec. I'm happy that it's fun for someone, but it does nothing for me. So I may be the wrong person to opine on this. But my seat-of-the-pants understanding of semantics says that you're only "improving the semantics" when you are "changing the semantics" + "the change is positive". In this case, we can deftly duck the question of whether the change is positive by observing that absent a request to change how the language functions, and following up only on the addition of an extra macro, you are still "compiling the code the same way" (my definition of "having the same semantics") and consequently you are not "improving the semantics" becuase you haven't changed it. Perhaps that just means I'm a backwoods hick who's talking over his head on a topic he shouldn't be opining about though... always a possibility.
