Thu Nov 11 13:10:39 EST 2004
>>>>> "Kent" == R Kent Dybvig <dyb at cs.indiana.edu> writes:
Kent> The code I showed you was not abtracted---it made direct use of nested
Kent> modules. If I can use macros to create new module abstractions,
Kent> I can hide those nested modules in the abstraction, and the intent
Kent> would become more clear. So the ability to use abstraction would have
Kent> helped, not hurt. I claim that this is true in most cases. If not,
Kent> or if we're petrified at the thought of an occasional bad abstraction,
Kent> we should outlaw all abstraction.
That isn't the issue---the problem is that you're abstracting over a
non-hygienic construct. "Normal" R5RS-style abstraction just doesn't
have the property that you can do:
Kent> ... but I don't know how this argues against abstraction. You are
Kent> again implying that abstraction could somehow make the situation worse,
Kent> but a well-designed abstraction would not do so. In particular, an
Kent> abstraction may make the set of identifiers being imported more rather
Kent> than less clear, i.e., more rather than less "hygienic".
I just haven't seen any evidence of this---examples might help.
Kent> So the information you consider crucial is crucial because it's explicit
Kent> and easily found, which is why you're arguing that we should make it
Kent> explicit and easily found. This seems a bit circular to me, so surely
Kent> I've misunderstood your meaning.
Yes. The information is crucial because I want to be able to find the
binding occurrence for an identifier bound by an import easily and via
a deterministic procedure. Macro-expanding into a definition may
obscure the identifier locally, but it becomes explicit by going
through an export.
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
More information about the R6RS