[R6RS] modules

[Michael Sperber]

>>>>> "Kent" == R Kent Dybvig <dyb at cs.indiana.edu> writes:

Kent> The point is that the "import" may not actually appear in the code, just
Kent> a symbol, keyword, or local variable with the same name; the a in (a x)
Kent> may expand into quote, or x may be a auxiliary keyword recognized by a,
Kent> or x may be bound by some enclosing imported construct.  Maybe a couple of
Kent> more elaborate examples would help.  Let's say instead of (a x) we have:

Kent> (module ---
Kent>   (require (only new-math sin asin))
Kent>   (require (only case-tools state-case bind-stuff))
Kent>   ---
Kent>   (bind-stuff ((x sin) ---)
Kent>     (state-case (find-next q)
Kent>       ---
Kent>       [(sin x) (make-sine-wave x)]
Kent>       ---))
Kent>   ---)

Kent> Is there a reference to the new-math sin in this code?  Not if bind-stuff
Kent> creates a local binding for sin or state-case treats it as a keyword or
Kent> quoted symbol.

The examples in this thread are beginning to trouble me more and more:
You seem to expect that, with some unhygienic extension of
SYNTAX-RULES in place, it will *and should* be common for programmers
to introduce forms that implicitly bind (not explicitly named)
identifiers.  (As, in fact, a local import form would do.)  Is this
inference correct?

If it is, the more I think about it, the less I like this scenario,
and I think it will lead to code so hard to read that eliminating
superfluous imports will be the least of the programmer's problems.

Kent> It's just this kind of thing:

Kent>   (let ((cons 3))
Kent>     (require only-for-syntax scheme)
Kent>     cons)

Kent> I prefer that this be an out-of-context error, since I don't like
Kent> having two visible bindings, usable or not, for the same identifier in
Kent> the same scope.  But one could say that the require-for-syntax doesn't
Kent> shadow run-time bindings, just compile-time bindings, so that it should
Kent> evaluate to 3.

Ah.  Oh.  From the name "only-for-syntax" I was quite sure that
"*only* for syntax" would mean *no* run-time binding.  This would
imply that there's no way the CONS in the LET body could and should be
affected by an "only-for-syntax" REQUIRE.

I think I would really like the import form to be clearly and
explicitly phased, with no form that does both at the same time.
This, I think, will encourage a much clearer expression of the phase
separation in the code.

(For all of these phase separation issues, however, I completely defer
to and agree with Matthew, who I (currently) believe has it all
figured out.)

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