-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/11/2013 02:29 PM, Eli Barzilay wrote:

> 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".)

Well, his goal is perhaps a little higher level; he wants to write a
macro that interprets the body of the macro invocation in a certain way,
namely as just a datum rather than with the emotional baggage of Scheme
source code.

This, I think, is really just a matter of degree. As much as the bodies
of let and cond deviate from normal scheme in that they contain lists
whose first member is not a procedure to apply to something, Alex wants
to see symbols rather than identifiers. A macro is free to interpret
cons cells, numbers, strings, and so on found in its body as it sees
fit, so why can't it interpret symbols outside of the context of
lexically bound identifiers?

The more general problem that I think he wants to solve might be looked
at like this.

Say we have a procedure, such as an sre matcher, but think about the
general form, which applies to lots of DSLs, and even to things like
quasiquotes as a degenerate case:

(matches <pattern> <input>)

That might also offer some up-front compilation, like so:

((compile <pattern>) <input>)

It would be nice to offer users (a) syntactic sugar and (b) run-time
efficiency by doing some or all of the compile "at compile time" (that
being, in this context, hopefully sometime before run time in order to
gain a benefit, and ideally shared between multiple runs of the program,
perhaps due to compilation to a binary executable). This might be done
by writing a macro that does the compile part and expands to just enough
run-time code to generate the compiled representation so it's usable at
run time.

Now, when used with the original "matches" or "compile" procedures, the
patterns are going to be quoted literals if they're not read or computed
from somewhere else. And so they use the unhygiene of the quote
macro/special form.

One might say that such poor hygiene should be limited only to quote
(and quasiquote?), and so users must use run-time compilation and not
use macros for this kind of DSL; one might write a macro that expands to
a quote wrapped around the body of the macro, but that's then sealing
that value up for run time, rather than letting the macro process it at
expansion time. And quoting the body of a macro won't help, obviously,
as the quote isn't evaluated before being given to the macro expander;
it'll still get syntax rather than a datum.

So, are you saying that quote is unschemely, or that macros which follow
the kind of general DSL pattern I consider above are unschemely, or
neither and I'm completely misunderstanding/misrepresenting you? :-)

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDwKR4ACgkQRgz/WHNxCGoAHACggBPv/QBjZl+nzeRB8NF6+7jP
M88AnRLf54Mb0hBOC8vujFun93WtBxRK
=098U
-----END PGP SIGNATURE-----

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