[R6RS] Modules

[Michael Sperber]

>>>>> "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:

(let ()
  (an-identifier-bound-to-i-dont-know-what)
  new-identifier-that-is-not-lexically-apparent)

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