Well, I suppose I am honor-bound to flame just a bit: On Fri, 2009-09-11 at 01:10 -0400, Eli Barzilay wrote: > On Sep 9, Thomas Lord wrote: > > On Wed, 2009-09-09 at 11:17 -0400, Eli Barzilay wrote: > > > And what do "we" get instead? Huge amount of verbiage that goes > > > back to rehashing decisions that were done decades ago -- fexprs > > > were dug up from their grave, first class environments were > > > suggested (seriously!) as a solution for multiple values, `lambda' > > > as a module system replacement, and of course there's yet another > > > wave of defmacro nostalgia. > > > > Name calling is not helpful. "Sticks and stones may..." and such > > but, realy.... > > Huh?? I really did mean each of these, and I don't see any of them as > a form of name calling.
"dug up from grave" -- "(seriously!)" -- "nostalgia". Them is name calling. That is ridiculing. It's been repeatedly pointed out that in a very classic three-register interpreter defmacro and a memoizing variation on fexprs are a great boon to implementation and that, in combination with some exposure of environments, can be used as a basis for modules and hygienic macros. Real, living implementations work this way - some of the longest lived and most popular implementations we've got. > Perhaps one clarification would help for why I said "defmacro > nostalgia". (The following turned out as something that would be a > better fit for a blog post, but I have no private blog. Apologies for > dumping it here.) > > In my experience, people like to have a kind of a concrete hold on > syntax. Something like "it's all just lists and symbols". Moving > from such a concrete world to a *hygienic* one means that you can no > longer have this simplistic point of view -- no matter what you do, > symbols and lists are just not going to work, you need to have some > extra information[*]. In fact, in a recent post Lynn Winebarger wrote > about this: > > | The advent of hygeinic macros marked the end of the era in which > | symbols could be equated with identifiers. Identifiers have a lot > | more information in them. > > I've ran into a very similar sentiment when dealing with > representation of syntax using plain symbolic forms and using a HOAS. > In the latter, you lose the concrete name (you're essentially dealing > directly with alpha-equivalence classes), and some people find it hard > to adjust to such a name-less world. (In an attempt to explain the > utility of HOAS in my work, I've made an observation that one of the > most fundamental CL-Scheme differences is going from "symbols" to > "identifiers".) The approach I took was to model binding sites as a mapping from symbols to locatives (a locative being a mutable, anonymous location - probably a bit like what you mean by "identifier"). Works perfectly well and has the charm of closely resembling how you would write a denotational semantics for Scheme. CL is off in a separate world that harkens back to the lisp 1.5 days where what I call locatives were not anonymous and were in fact identified with symbols. > In both cases, I find that the immediate reaction of rejecting the > "nameless" approach is a kind of an attempt to get back to the > familiar comfort zone where a symbol is a symbol; where > `symbol->string' gives you enough information about it (even if it's > an uninterned symbol). *That* is what I labeled above as "defmacro > nostalgia" (but it still doesn't explain why I used "nostalgia"). It > is something that I would expect Schemers to treat as essential. You have a straw-man going. Nobody I've seen is arguing for lisp 1.5 style "value slots" on symbols. A (potentially first-class) locative is the anonymous binding site you are thinking of. An environment is a mapping (with various special characteristics) of symbols to locatives. Defmacro / memoizing-fexpr-ish things can indeed be usefully (both in theory and practice) be modeled as graph rewriting on code-as-s-exprs. > There are the usual two kinds of name capturing that makes it > essential -- the one that can be addressed using uninterned symbols is > usually taken as the more important one (and therefore used by CLers > to explain why they don't need hygiene). Nobody around here is arguing for CL. I happen to also like uninterned symbols for other reasons - they are just a convenient data structure that is usually easy to provide. They are not essential to macro systems in Scheme, though. > The other kind of capture is > considered less important, in the style of "nobody would be insane > enough to have a different meaning for `if'". But if you consider > macros with a module system: it allows you to keep the abstraction > barrier by letting you export a macro but not utility functions and > values that the macro uses, and it allows you to define your own > language (for example, a language with a new kind of `if') and still > be able to import macros that are written in the usual Scheme > language. > > Considering the need for hygiene Do you understand that when I advocate for defmacro and such that this does not in any way preclude hygienic macros? It is precisely because *i built hygienic macros* on a system with defmacro / memoizing-defmacro and exposed environments and locatives that I think it is a good approach to defining Scheme. > and the fact that identifiers are not > just symbols, I would also expect schemers to take hygiene as > intuitive. But I know that this is often expecting too much... I quit reading there. -t > There > are a good number of schemers who still prefer the plain symbol > approach, and as a result there is this longing for the simple world > of `defmacro' (or ER/SC macros that are taken as a more defmacro-ish > facility). Given what I said in the previous paragraph, it's not > surprising that this often comes with a preference for the simplicity > of `load': having no module system (and having uninterned symbols) > gets you back to a place where hygiene is not that important. And > this is why I used "nostalgia": IMO, these kind of sentiments often > come from "old school schemers" whereas "new schoolers" are more > likely to see hygiene as essential and intuitive. > > > > [*] As an aside, this is exactly why I like `syntax-case' as a base > system: instead of going with some obscure `rename' function or some > representation of the lexical environment that surrounds a macro use, > it deals directly with "symbols + some opaque value" where the latter > represents the lexical information of the identifier and there is no > need to understand what is actually kept there. > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
