[R6RS] Internal DEFINE vs. macros

[Michael Sperber]

dyb at cs.indiana.edu writes:

>> This can be explained operationally in terms of the expansion
>> algorithm, but it seems difficult to come up with any declarative
>> intuition for it.  I certainly can't just go up through the nesting
>> levels and easily associate identifier occurrences with their
>> bindings.
>
> You can in most cases.  I agree that it would be nice, in theory, to be
> able to do so in all cases, but how much should we be willing to sacrifice
> to get this property?

This, I guess, is the fundamental issue behind a lot of the discussion
we're having about the module system, and it's a good thing it's
slowly emerging here---at this point, I'm not at all disappointed we
haven't arrived at the same conclusions.

> As you've mentioned previously, we'd have to bloat our record
> definitions to name all record constructors, predicates, accessors,
> and setters, 

We just have very different backgrounds and experience when it comes
to writing large-scale Scheme code.  An example:

After initially hacking with record-type definition forms that
implicitly construct names, I've come to appreciate the added clarity
(and, often, flexibility) of always specifying the names explicitly.
Subsequently, I wrote a lot of code with PLT's DEFINE-STRUCT (which
also chooses the names explicitly), and often found myself frustrated
by the lack of flexibility or the loss of grepping ability.  I
certainly don't consider the added typing "bloat."

> and we'd have to explicitly name all imports.  Now you're saying
> we'd have to do without internal definitions, or at least internal
> syntax definitions.  There are some other things we'd obviously have
> to do without, like include and datum->syntax-object.  What's less
> obvious is that we'd even have to do without syntax-rules macros
> (top-level as well as local), since even they can obscure bindings.

I never proposed being revisionist about these aspects (SYNTAX-RULES
and internal DEFINE) of R5RS, and I don't want to start now.  Of
course, with SYNTAX-CASE, I can break a lot of the properties I like
about SYNTAX-RULES, but there's a clear separation of concerns.  I
also acknowledge the need for a facility for writing macros-as-code,
and sometimes non-hygienic macros.

The question for me is whether having the ability to break a property
in principle means that we should give up on preserving the property
everywhere.  Just because internal definitions a) have a flaw (obscure
or not) and b) are in R5RS doesn't make it obvious that we can now add
other elements to the language with the same flaw without worrying
about it.  I'm not saying that we shouldn't at all cost, but I would
like to make sure that we weigh the issues in those cases.

> Doesn't it make more sense to relax on this issue and use a tool like
> MrSpidey when necessary?

Not for me.  I don't want to have to use an external tool to
understand a Scheme program.  I want Scheme programs to be as clear as
possible.  (Moreover, tools like MrSpidey are a far cry from being
universally available, and MrSpidey was a far cry from solving this
problem universally.)

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla