On Wed, 2009-10-14 at 12:04 -0400, Aaron W. Hsu wrote:
> On Wed, 14 Oct 2009 10:51:42 -0400, David Rush <[email protected]> wrote:
>
> > I am starting to suspect that the only truly correct way to move
> > forward on macro modularity is to rebase the notion of a Scheme system
> > as a purely interpreted textual language.
>
> You seem to be arguing:
>
> 1. Module systems shouldn't need to be anything more than Lambda and
> Load.
> 2. Macros can not be modularized with lambda and load.
> 3. Ergo, we should get rid of Scheme as we know it.
I seem to recall carefully considering the blend of macrology and
scope with module imports and exports, doing a lot of hairy
formal-semantics, and concluding that there was no consistent way
to include macros in module exports. I seem to recall pointing
this out in the discussions about R6 nearly a year before it was
passed, making me, I think, one of the only people who agreed
with Guillermo Rozas in saying that modules should not be allowed
to export macros. I also recall being ignored. I hate to say I
told ya so, but..... aw, who am I kidding? I don't mind saying
it a bit.
So, here we are again. Why act surprised? The math is still the
same. The answer's still the same. "Scheme as we know it" has
a fault line along which its elegant crystalline structure breaks
when modules are added. R6 passed anyway, so a lot of people
apparently don't care.
What lambda handles and what scheme's scope rules govern consistently
is values. Unless macros are values (ie, first-class entities that
exist at runtime), Scheme's scope rules will not consistently govern
them. And that defeats what some see as being the whole point of
macros in the first place.
Speaking for myself, it's why I abandoned macros as an idea and
started looking at ways to express semantics that in scheme
require macrology using generalized functions. Generalized
functions can be handled completely consistently by a module
system because they are values.
I can demonstrate now (I've done some research since then) that
if you allow user-defined generalized functions to take their
arguments lazily or applicatively rather than just eagerly,
that's all you need to get expressive power equal to anything
that can be expressed without mutation in "hygienic" macrology.
If you want generalized functions that can do mutation, or which
have the power of syntax-case or defmacro, (ie, functions that
express the semantics of "setter" macros or macros that can do
variable captures) you also need first-class environments.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss