On Sat, Nov 20, 2010 at 9:46 AM, Hendrik Boom <hend...@topoi.pooq.com> wrote: > On Sat, Nov 20, 2010 at 08:42:57AM -0500, Shriram Krishnamurthi wrote: >> I haven't seen this book mentioned here before, so:
>> It is, well, a very particular perspective on things, but I've heard >> people speak well of it.
> It looks interesting. Very unSchemeish, though. Chapter 6, on > anaphoric macros, seems to celebrate unhygienicity.
> -- hendrik
The following passage is particularly unsettling.
"Even the vast majority of Scheme systems, the platform that has experimented the most with hygiene, provide unhygienic defmacro-style macros—presumably because not even Scheme implementors take hygiene very seriously. Like training wheels on a bicycle, hygiene systems are for the most part toys that should be discarded after even a modest level of skill has been acquired."
On Sat, Nov 20, 2010 at 9:53 AM, Carl Eastlund <c...@ccs.neu.edu> wrote: > On Sat, Nov 20, 2010 at 9:46 AM, Hendrik Boom <hend...@topoi.pooq.com> wrote: >> On Sat, Nov 20, 2010 at 08:42:57AM -0500, Shriram Krishnamurthi wrote: >>> I haven't seen this book mentioned here before, so:
>>> It is, well, a very particular perspective on things, but I've heard >>> people speak well of it.
>> It looks interesting. Very unSchemeish, though. Chapter 6, on >> anaphoric macros, seems to celebrate unhygienicity.
>> -- hendrik
> The following passage is particularly unsettling.
> "Even the vast majority of Scheme systems, the platform that has > experimented the most with hygiene, provide unhygienic defmacro-style > macros—presumably because not even Scheme implementors take hygiene > very seriously. Like training wheels on a bicycle, hygiene systems are > for the most part toys that should be discarded after even a modest > level of skill has been acquired."
On Nov 20, 2010, at 11:03 AM, Robby Findler wrote:
> Good thing we're not Scheme anymore.
:-) You think that guy would believe you? _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
If these two paragraphs are characteristic for the book, it is based on the usual misconceptions of poor Common Lispers about the world of hygienic macros, which they have never understood and are therefore afraid of.
For us, we should figure out what's good about the book and use it for our own work. We understand 'hygienic macros' and these guys' world. Advantage, us.
> If these two paragraphs are characteristic for the book, it is based on the usual misconceptions of poor Common Lispers about the world of hygienic macros, which they have never understood and are therefore afraid of.
And booleans, apparently.
> For us, we should figure out what's good about the book and use it for our own work. We understand 'hygienic macros' and these guys' world. Advantage, us.
Having read some of the stuff, l am not impressed. Yes, in some cases we may want to introduce a binding not named in a macro call. Racket and R6RS (macro-case) do that very well. That for a beginner it is difficult to prepare unhegienic macros: jolly good! I have misused datum->syntax a couple of times, just to find out later that I did not need it realy (although I recognize that in some cases it may be usefull) Jos
> -----Original Message----- > From: users-boun...@racket-lang.org > [mailto:users-boun...@racket-lang.org] On Behalf Of Matthias Felleisen > Sent: 20 November 2010 17:08 > To: Robby Findler > Cc: Carl Eastlund; us...@racket-lang.org > Subject: Re: [racket] letoverlambda
> On Nov 20, 2010, at 11:03 AM, Robby Findler wrote:
> > Good thing we're not Scheme anymore.
> :-) You think that guy would believe you? > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users
> Having read some of the stuff, l am not impressed. Yes, in some cases we may > want to introduce a binding not named in a macro call. Racket and R6RS > (macro-case) do that very well. That for a beginner it is difficult to > prepare unhegienic macros: jolly good! I have misused datum->syntax a couple > of times, just to find out later that I did not need it realy (although I > recognize that in some cases it may be usefull) > Jos
My experiences are similar. On the few occasions that I have used unhymacs, I first wrote and debugged hymacs; this path allows macro novices like myself to see and justify (or not) the need for developing them into unhymacs. To me, good development environments provide 'complication stages' that can be clearly understood and encountered only when required.
On Sat, Nov 20, 2010 at 1:25 PM, Jos Koot <jos.k...@telefonica.net> wrote: > I have misused datum->syntax a couple of times, just to find out later that I did not need it realy (although I > recognize that in some cases it may be usefull)
I continue to be delighted when I find that syntax-rules often provides an easily understood and syntactically pleasant solution to problems that I thought could only be solved by syntax-case and functions. Of course the problem lies within myself, not syntax-case! _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
> For us, we should figure out what's good about the book and use it > for our own work. We understand 'hygienic macros' and these guys' > world. Advantage, us.
> The author is irrelevant to us.
I've ran into this book a while ago -- it's just an overall bad piece of text, not just the macro parts. (And not even counting his hygiene ignorance (which is overall very popular in the CL world, usually a by-product of equating "hygiene" with `syntax-rules').)
I've only skimmed/sampled some of On Lisp, and even less of Let Over Lambda. But the main theme of both seemed to be: Macros are an important higher level of programming, but under-appreciated, under-utilized, under-understood (stood?), and "under-booked". Hence these books.
Anaphoric macros are deliberately unhygienic. But I didn't get the impression that all or even most of the macro techniques were unhygienic. Am I wrong and didn't get deep enough into the books? To put it another way, is the negative reaction here due to him dissing hygiene, or is it reflective of a deeper and broader disagreement with the entire approach of putting macros on a pedestal?
BTW I'm asking this innocently, genuinely not knowing the answer, curious what more experienced people think.
On Sat, Nov 20, 2010 at 10:53 AM, Carl Eastlund <c...@ccs.neu.edu> wrote: > On Sat, Nov 20, 2010 at 9:46 AM, Hendrik Boom <hend...@topoi.pooq.com> wrote: >> On Sat, Nov 20, 2010 at 08:42:57AM -0500, Shriram Krishnamurthi wrote: >>> I haven't seen this book mentioned here before, so:
>>> It is, well, a very particular perspective on things, but I've heard >>> people speak well of it.
>> It looks interesting. Very unSchemeish, though. Chapter 6, on >> anaphoric macros, seems to celebrate unhygienicity.
>> -- hendrik
> The following passage is particularly unsettling.
> "Even the vast majority of Scheme systems, the platform that has > experimented the most with hygiene, provide unhygienic defmacro-style > macros—presumably because not even Scheme implementors take hygiene > very seriously. Like training wheels on a bicycle, hygiene systems are > for the most part toys that should be discarded after even a modest > level of skill has been acquired."
For my part, I don't mind dissing hygiene; I certainly don't think that the current state of the art in hygenic macro expanders is the best we can do. BUT, I found the small sampling that I read of Let Over Lambda to be fairly ignorant in some ways and quite strange in others (like the paragraph that complained about booleans in Scheme; it didn't make much sense to me).
Anyways, to your actual question: my answer would be that most macros I know are hygenic. Ie, if you have to pick a default for variables introduced by a macro, hygenic is the right one.
<greghendersh...@gmail.com> wrote: > I've only skimmed/sampled some of On Lisp, and even less of Let Over > Lambda. But the main theme of both seemed to be: Macros are an > important higher level of programming, but under-appreciated, > under-utilized, under-understood (stood?), and "under-booked". Hence > these books.
> Anaphoric macros are deliberately unhygienic. But I didn't get the > impression that all or even most of the macro techniques were > unhygienic. Am I wrong and didn't get deep enough into the books? To > put it another way, is the negative reaction here due to him dissing > hygiene, or is it reflective of a deeper and broader disagreement with > the entire approach of putting macros on a pedestal?
> BTW I'm asking this innocently, genuinely not knowing the answer, > curious what more experienced people think.
> On Sat, Nov 20, 2010 at 10:53 AM, Carl Eastlund <c...@ccs.neu.edu> wrote: >> On Sat, Nov 20, 2010 at 9:46 AM, Hendrik Boom <hend...@topoi.pooq.com> wrote: >>> On Sat, Nov 20, 2010 at 08:42:57AM -0500, Shriram Krishnamurthi wrote: >>>> I haven't seen this book mentioned here before, so:
>>>> It is, well, a very particular perspective on things, but I've heard >>>> people speak well of it.
>>> It looks interesting. Very unSchemeish, though. Chapter 6, on >>> anaphoric macros, seems to celebrate unhygienicity.
>>> -- hendrik
>> The following passage is particularly unsettling.
>> "Even the vast majority of Scheme systems, the platform that has >> experimented the most with hygiene, provide unhygienic defmacro-style >> macros—presumably because not even Scheme implementors take hygiene >> very seriously. Like training wheels on a bicycle, hygiene systems are >> for the most part toys that should be discarded after even a modest >> level of skill has been acquired."
On Nov 20, 2010, at 9:01 PM, Greg Hendershott wrote:
> But I didn't get the > impression that all or even most of the macro techniques were > unhygienic.
Hygiene is a technical term. The idea is roughly that the __macro system__ (as a whole) should respect the lexical structure of your program. That is, by default no programmer should be able to accidentally write a macro that messes up lexical bindings in a subtle way.
Roughly speaking, macro hygiene is like safety. The latter also is a property of the language, meaning all programs have it, no matter the skill of the programmer who uses them. In particular, it doesn't make much sense to say an individual macro is hygienic or that an individual program is safe. You can 'prove' certain fail-safety properties about each but that's all. The word 'prove' is meant in the general sense that reasoning about programs constitutes an attempt to make sure it is always exhibiting the desired properties, no matter the context, input, or whatever.
(When I coined the phrase 'hygienic macro' I was reading a paper by Barendregt who used it in a similar context for dismissing detail concerns about substitution in LC. (My coauthors loved the term and so we took it. Another candidate had been 'synthetic' or something like that.))
In particular, something many people miss -- because of the way hygiene is presented -- is that a hygienic macro system must have a deep understanding of the underlying language, at least up to the level of the binding structure of its constructs. That is how it can even be sure what is a binding, where it is bound, and thus what can be painted/renamed/closed over/tweaked/whatever.
Once you understand that, you realize that it is simply not meaningful to say that a *macro* is "hygienic" -- that phrase is not even wrong.
On Sat, Nov 20, 2010 at 9:08 PM, Shriram Krishnamurthi <s...@cs.brown.edu> wrote: > In particular, something many people miss -- because of the way > hygiene is presented -- is that a hygienic macro system must have a > deep understanding of the underlying language, at least up to the > level of the binding structure of its constructs. That is how it can > even be sure what is a binding, where it is bound, and thus what can > be painted/renamed/closed over/tweaked/whatever.
> Once you understand that, you realize that it is simply not meaningful > to say that a *macro* is "hygienic" -- that phrase is not even wrong.
Not necessarily -- see syntax parameters. The idea is that there is an identifier (like `it') which is managed like all other identifers, and it has some use only inside some lexical context (like the consequence branches of an `if').
> [...] To put it another way, is the negative reaction here due to > him dissing hygiene, or is it reflective of a deeper and broader > disagreement with the entire approach of putting macros on a > pedestal?
In my case, my negative reaction is to CLers who think that hygiene is somehow equivalent to `syntax-rules', and because `syntax-rules' has the limitations that it does, they conclude that hygiene as a whole is an academic toy. One that you dump when you get to write Real Code.
20 minutes ago, Matthias Felleisen wrote:
> On Nov 20, 2010, at 9:01 PM, Greg Hendershott wrote:
> > But I didn't get the impression that all or even most of the macro > > techniques were unhygienic.
> Hygiene is a technical term. [...]
BTW, there's a good number of CLers that object to the actual term, since they see it as something that implies that their macros are "dirty".
> (When I coined the phrase 'hygienic macro' I was reading > a paper by Barendregt who used it in a similar context > for dismissing detail concerns about substitution in LC. > (My coauthors loved the term and so we took it. Another > candidate had been 'synthetic' or something like that.))
[IMO, a good term would be one that makes CL macros be "symbolic" or "concrete" -- something that indicates that the good macros are ones where you don't usually care about the actual characters that make up an identifier in code that you write...]
40 minutes ago, Robby Findler wrote:
> (like the paragraph that complained about booleans in Scheme; it > didn't make much sense to me).
I think that it is just a confused criticism -- he *probably* intended to praise the CL property that false is the same as the empty list, and that many core functions (like `car' and `cdr') return nil when given it instead of throwing an error. If this is wrong, then he knows so little about scheme that he should never have mentioned it. If it's true, then it indicates bad sloppiness on his part -- the kind that exposes biased opinion.
10 minutes ago, Shriram Krishnamurthi wrote:
> In particular, something many people miss -- because of the way > hygiene is presented -- is that a hygienic macro system must have a > deep understanding of the underlying language, at least up to the > level of the binding structure of its constructs. That is how it > can even be sure what is a binding, where it is bound, and thus what > can be painted/renamed/closed over/tweaked/whatever.
+1. I like to say that CL macros make a huge jump from CPP or M4: from unstructured text to structural "pre-parse" trees. And due to what Shriram says, hygienic macros make an equally huge jump to having information about the binding structre (more or less) of the code. (And in this context "hygienic macros" really mean all hygiene-breaking `syntax-case'-style macros -- since the information was there even if some macro chose to inject a concrete name.)
On Nov 20, 2010, at 6:58 PM, Matthias Felleisen wrote:
> On Nov 20, 2010, at 9:01 PM, Greg Hendershott wrote:
>> But I didn't get the >> impression that all or even most of the macro techniques were >> unhygienic.
> Hygiene is a technical term. The idea is roughly that > the __macro system__ (as a whole) should respect the > lexical structure of your program. That is, by default > no programmer should be able to accidentally write a > macro that messes up lexical bindings in a subtle way.
Dave Herman mentioned this to me some time ago, and my immediate response was this: okay, if the term "hygiene" refers to a macro system and not to a macro, then *what word* should we use to describe macros that violate transparency? "non-transparent"?
> On Nov 20, 2010, at 6:58 PM, Matthias Felleisen wrote:
>> On Nov 20, 2010, at 9:01 PM, Greg Hendershott wrote:
>>> But I didn't get the >>> impression that all or even most of the macro techniques were >>> unhygienic.
>> Hygiene is a technical term. The idea is roughly that >> the __macro system__ (as a whole) should respect the >> lexical structure of your program. That is, by default >> no programmer should be able to accidentally write a >> macro that messes up lexical bindings in a subtle way.
> Dave Herman mentioned this to me some time ago, and my immediate response was this: okay, if the term "hygiene" refers to a macro system and not to a macro, then *what word* should we use to describe macros that violate transparency? "non-transparent"?
On Sat, Nov 20, 2010 at 18:14, Matthias Felleisen <matth...@ccs.neu.edu> wrote:
> If these two paragraphs are characteristic for the book, it is based on the usual misconceptions of poor Common Lispers about the world of hygienic macros, which they have never understood and are therefore afraid of.
> For us, we should figure out what's good about the book and use it for our own work. We understand 'hygienic macros' and these guys' world. Advantage, us.
> The author is irrelevant to us.
> -- Matthias
I don't want to take any sides in this debate -- which seems to drift into a "Scheme vs Common Lisp" debate -- I just want to point to the "Clarifications" page written by the same book author regarding it's controversies:
P.S.: It just happens that a few weeks ago I've started reading the book online, and from yesterday I also have the book. And I kind of like the macro stuff described in there. (And just for the record I prefer Scheme over Common Lisp.)
Moreover, the macros described in his book (by using a certain methodology) are not that different from a primitive hygienic-like macro system. For example he defines the `square` macro as:
So my personal opinion (as an amateur Lisp-ish programmer) is that if someone is interested in DSL's he could read the book, at least to get an idea of what can be achieved in a Lisp-ish environment. (I actually want to understand his ideas and techniques and try to see how to better adapt and apply them to Racket in the context of hygienic macros (I currently only know `syntax-rules` so maybe the next step is to understand "hygienic" macros, thus any good pointers are welcomed).) _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
<ciprian.crac...@gmail.com> wrote: > On Sat, Nov 20, 2010 at 18:14, Matthias Felleisen <matth...@ccs.neu.edu> wrote:
>> If these two paragraphs are characteristic for the book, it is based on the usual misconceptions of poor Common Lispers about the world of hygienic macros, which they have never understood and are therefore afraid of.
>> For us, we should figure out what's good about the book and use it for our own work. We understand 'hygienic macros' and these guys' world. Advantage, us.
>> The author is irrelevant to us.
>> -- Matthias
> I don't want to take any sides in this debate -- which seems to > drift into a "Scheme vs Common Lisp" debate -- I just want to point to > the "Clarifications" page written by the same book author regarding > it's controversies:
> P.S.: It just happens that a few weeks ago I've started reading > the book online, and from yesterday I also have the book. And I kind > of like the macro stuff described in there. (And just for the record I > prefer Scheme over Common Lisp.)
> Moreover, the macros described in his book (by using a certain > methodology) are not that different from a primitive hygienic-like > macro system. For example he defines the `square` macro as:
> So my personal opinion (as an amateur Lisp-ish programmer) is that > if someone is interested in DSL's he could read the book, at least to > get an idea of what can be achieved in a Lisp-ish environment. (I > actually want to understand his ideas and techniques and try to see > how to better adapt and apply them to Racket in the context of > hygienic macros (I currently only know `syntax-rules` so maybe the > next step is to understand "hygienic" macros, thus any good pointers > are welcomed).)
> Dave Herman mentioned this to me some time ago, and my immediate response was this: okay, if the term "hygiene" refers to a macro system and not to a macro, then *what word* should we use to describe macros that violate transparency? "non-transparent"?
How about opaque?
- -- Eduardo Bellani
omnia mutantur, nihil interit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> Dave Herman mentioned this to me some time ago, and my immediate response was this: okay, if the term "hygiene" refers to a macro system and not to a macro, then *what word* should we use to describe macros that violate transparency? "non-transparent"? > Oh dear... would that word be "anaphoric"?
A macro that violates hygiene.. 'violator' _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
Sadly, his response only makes things worse. He writes
Some Scheme systems have theoretically advanced macro systems but I believe the Common Lisp macro system is more suitable for writing useful macros.
Eh? How about a huge chunk of the cool things in Racket, from the class system to Typed Racket to Lazy Racket to FrTime?
He does not understand that a macro system that closes over bindings from other modules is a *fundamentally different thing* than a mere macro system. It is hard to overstate this matter; it is foundational to what makes Racket a different language than Lisp or Scheme.
In fact, this merely demonstrates that where macros are concerned, he's a Blub programmer. (He may indeed be in the top-10%ile of Blubberers.)
I'm aware that he says
If you disagree and have examples to back up your opinions, I'd love to hear from you.
but perhaps if he were truly interested in learning, *he* would contact the authors of those "theoretically advanced systems" and ask them to educate him, not put the burden on them.
Shriram
PS: This message is public, so anyone who wants to is welcome to forward it to him or anyone else, w/out asking me for permission. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
