On Fri, 2009-09-11 at 11:05 -1000, Shiro Kawai wrote:
> If we relax the restriction and allow shadowing define, we need
> to clearify resolution of forward reference. For example:
> (import (foo-library)) ; imports name "foo", possibly a syntax.
> (define x (foo 42))
> (define (foo n) (* n n))
> Which "foo" should be used to compute x, the imported one or
> the one defined in the current module?
I would advocate the simple one-pass semantics of having
(import (foo-library)) start the extent of 'foo' bound to the
library-exported value (immutable in the current scope because
the binding does not belong to the current scope) and the
shadowing redefinition end it (by starting the scope of a
different binding of 'foo' bound to a different value in
the current scope).
This is effectively equivalent to treating 'define' as a 'let'
whose scope contains the remainder of the enclosing lexical
scope.
Relaxing this no-redefinition restriction would eliminate the
need for the complicated R6RS import forms that rename things,
since it would then be trivial to bind the imported values to
different names using machinery (define, set!, let, lambda, etc)
that scheme already provides for the purposes of assigning
names to values.
And there's that elusive aesthetic goal expressed in the first
paragraph of the report - removing restrictions that have made
complex things seem to be necessary.
> I think the extreme end of dynamism, in which redefinition
> can alter the behavior of all procedures that depend on
> the redefined binding, isn't desirable for most of the cases.
If supported at all, a form allowing one module to alter
bindings established in another, with immediate effects on
code in yet further modules depending on that other, should
appear next to a big red stopsign in the documentation that
says, "warning, this is almost always a bad idea and will
cause changes in the semantics of all modules that depend
on that library; changes which you probably won't anticipate,
may not even understand, and which will be hell to debug."
It might be appropriate for a lisp intended as a "universal
mechanical translation target" or UNCOL, but would tend to
extremes of bad hygiene and damnably subtle bugs in any
software engineering process involving merely mortal
programmers.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
