Alex Shinn wrote:
>
> Ah, indeed - I forgot the parameters need to be bound globally as
> syntax parameters, and these still need to match hygienically.

No, syntax parameters are unrelated here.  They're used when you want
a specific binding to have a different meaning in the context of some
macro, and the issue here is *matching* keywords, not using their
binding.

Alex Shinn wrote:
>
> Syntactic closures would make it easy to implement unhygienic
> parameters, but I guess that's not possible with syntax-case.

This doesn't make any sense.  Any macro facility is still something
that works by having bindings for identifiers, so whatever it is, it
can't avoid having macro names bound and having these bindings respect
the usual scoping rules.  (I can only guess that the above is a broken
attempt to talk about something more similar to a `let-syntax' with an
unhygienically constructed name.)

Alaric Snell-Pym wrote:
>
> AIUI, Alex's goal is to have the same unhygiene that (quote ...)
> has.  The symbols within need to be taken just as symbols, not as
> identifiers, and that's that.

Right that's his goal, and it is a broken one.  As I said earlier,
life is fine if you accept or reject hygiene completely.  These
attempts at doing so in some cases are what leads you to a mess.  In
any case, accepting hygiene (which is supposed to be the somewhat more
popular sentiment in this list's context) means that at the macro
level you have identifiers, and that's that.  It's worth repeating:

  In macros, bindings are identifiers, not symbols.

Symbols are there as the concrete name that was written in the code,
but when you get to the macro level it doesn't matter.  Actually it
shouldn't matter -- and the fact that there are low-level systems that
let you access it is a wonderful way to trip people and get them
utterly confused.  (This thread being a wonderful example.)  (And BTW,
I'm not advocating removing the underlying symbolness of identifiers;
they do have an occasional use, maybe, only it's much more rare that
these uses are justified.)

Here's a quick demonstration of how it gets broken.  Assume that the
macros in question want to match two keywords: `+' and `?'.  The first
is bound, the second isn't.  Alex wants to write some "portable" macro
that matches on these things as is -- as symbols -- and without
creating a dummy binding for `?' just for that.  As things stand,
that's impossible to do if you want to keep your sanity.  The thing is
that `+' is bound, so it should respect scope, and `?' isn't.  So if,
for example, you could import `+' with a different name and use that,
but you can't do that with `?' since it's not a binding.  In the same
way, using a prefix for a whole library would apply to `+' but not to
`?'.  (And I mentioned CL earlier: note that it's package system
(which deals with symbols, not identifiers) does put all (unknown)
symbols in the current package, thereby it corresponds to not having
such "raw symbols".)

So that's just broken, and that's that.  What he really wants is a new
macro tool, some `syntax-rules/literal-keywords' that matches all of
its keywords by their symbolic name, which would again treat `+' and
`?' in the same way.  The question is whether this is a good idea or
not.  His earlier claim was:

> Almost all DSLs, however, fall into the latter case.

IMO, this is a *very* questionable thing to say.  In the context of
Scheme, DSLs are almost always created with macros.  (It's true that
there are other forms of DSLs, but what's the point of Scheme then?)
And a DSL that is made of macros is certainly one that is expected to
obey the host language's scoping rules, and that's the whole goal of
hygiene.  And it's not only IMO, it's also IME -- I don't remember
seeing a single *good* DSL that used symbols.  But maybe that's just
me, who equates "good" with "respects (lexical) scope" -- there are a
few people who love CL format strings with all of their "features".

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports