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.
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".)
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.
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). 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 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... 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.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
