[R6RS] Internal DEFINE vs. macros
dyb at cs.indiana.edu
dyb
Sun Apr 24 13:45:13 EDT 2005
> 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."
While I prefer the naming regularity inherent in the implicit name
generation, it's fine with me if we allow the names of the constructor,
predicate, accessors, and setters to be specified explicitly as long as
I have the option of having them implicitly generated. Can we agree
on that? Then we can both get what we want for the code we write.
Of course, before you start grepping through my code, you might need to
expand my record definitions to include explicitly the names that would
have been generated implicitly.
But we digress...back to internal define-syntax:
> 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.
The price we pay for powerful language features is that the power can be
abused to write obscure code. Internal define-syntax adds to the power,
so it adds to the risk of obscure code. Used properly, however, it leads
to clearer code, just like internal define, syntax-rules, include, etc.
> Not for me. I don't want to have to use an external tool to
> understand a Scheme program.
Isn't 'grep' an external tool? ;-)
> (Moreover, tools like MrSpidey are a far cry from being
> universally available, and MrSpidey was a far cry from solving this
> problem universally.)
If we ever get the r6rs done, there's a lot more chance that it will be
universally available. Even then, it may remain a far cry from solving
the problem universally, but it is already better than grep.
Kent
More information about the R6RS
mailing list