If something is defined in library A and might, via exports
and imports, be visible in library B, R6RS seems to prohibit
any mutation of it at all, whether by library A *or* library
B. I quote from the second-to-last paragraph of sec.7.1:
"Bindings defined with a library are not visible in code
outside of the library, unless the bindings are explicitly
exported from the library." ... "All explicitly exported
variables are immutable in both the exporting and importing
libraries. It is thus a syntax violation if an explicitly
exported variable appears on the left-hand side of a set!
expression, either in the exporting or importing libraries."
I think that's excessively restrictive, and would prefer to
see mutation semantics like those which have protected primitives
like 'car' in at least R4RS, R5RS, and R6RS applied to exported
and imported forms.
To wit: Redefinitions of primitive procedures (such as car and
cdr) or primitive syntax (such as lambda) do not alter the
semantics of other primitive procedures (such as length), even
if the latter is defined in terms of the former.
Also: (also R4RS, R5RS, R6RS) using set! to change a binding is
only allowed if it is in the scope of a define that establishes
that binding. IOW, you can only mutate a definition created by
your own code. So, if you shadow the variable whose name is 'cdr',
by placing a 'define' in your own scope, you can mutate it all
you want but that doesn't affect the binding in the larger
"zeroth" scope in which the primitive (that other procedures
depend on) is defined.
Code that's in another (imported) library IMO should be treated
just like code that defines the primitives. It should be an
error to mutate it unless you have redefined it (thus, you're
allowed to mutate the binding you created, but not the one
the library created). And redefining something that's imported
from a library should have no effect on other things imported
from that library (because shadowing a variable in the current
scope doesn't alter the binding visible in a larger scope).
Also, I do not see a pressing need to prohibit a library from
modifying the bindings of its own exported variables during
runtime (both routine-valued and other variables), and in
some circumstances (runtime patching of high-availability
servers which cannot be allowed to go down) it is necessary
to allow it, so I think that it should not be prohibited.
However, I don't see any way to allow runtime modification of
syntax, exported or otherwise, given scheme's current
semantics.
A runtime modification of syntax effectively requires that
every invocation of that syntax has to be restored to source
form and then reexpanded - or else the under-the-hood implementation
of syntax has to be done in terms of first-class environments
(whether exposed to the user or not) rather than in terms of
code rewriting. Either way it requires drastic changes to
the implementations and wouldn't be accepted.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
