On Sep 10, 2009, at 4:06 PM, John Cowan wrote: > Brian Mastenbrook scripsit: > >> What do you mean by procedure redefinition, and how does it differ >> from variable redefinition? > > Note the word "calls" vs. "uses". I meant to allow for the > possibility > that a compiler had inlined calls to procedures, but not simple > references > to variables whether procedure-valued or otherwise (which would be the > same as treating the variables as constants).
How is a procedure call different from a variable reference? What is the justification for treating the reference to `v' in (v a) different than the reference in (a v)? If it's allowed to inline procedure calls, surely it should be allowed to inline references to non- procedure-valued variables as well, should it not? This is a Big Question, of course. I personally don't think it's acceptable to grant implementors any wiggle room for procedure calls that is not also granted for non-call uses of procedure-valued variables, or to any reference to global variables. I'd prefer not to see this wiggle room at all. The semantics of inlining, to me, only make sense when the use and definition are closely lexically linked, such that a change in the definition will also cause the use to be recompiled, or when the definition will never, ever be modified by a user program. The former semantics are easily expressible in standard Scheme now. The latter perhaps may serve as a motivation to introduce some kind of library sealing to the language. > I am assuming, perhaps falsely, that no systems fail to expand > macros at > definition time. I can't think of how you would *not* do this and preserve hygiene. >> If I re-load a library, am I creating a fresh set of syntactic >> bindings, or altering the existing set? > > Here's my mental model: > > 0) We load files, we import modules. > > 1) Loading a file is the same as typing its contents (or its source, > if it is compiled) to the REPL, whether or not it's been loaded > before. > > 2) There are modules, and then there is the top level, which behaves > like > a module too. Top-level definitions in any module alter the > environment > in that module. > > 3) Importing module foo into module bar causes the exported > definitions of > foo to be as if typed into bar, but of course hygienically with > respect > to the names used therein. > > So when I load a file, any definitions not in modules alter the top > level, and any definitions in modules affect that module, but *not* > any other modules unless (re)imported into them. I don't see any problems with your mental model, but I'm having trouble at the point of conclusion. If the module `foo' is already defined, and I either type at the REPL or load a file containing a re- definition of the module, am I altering the existing bindings in that module, or am I creating new syntactic bindings? If the top level "behaves like a module too", I believe the former semantics are the only sensible semantics. Suppose for the moment that I have a Scheme web application defined as a (collection of) libraries. If I make a change to the application and re-load the appropriate files, I need to be able to access the new bindings from the top-level without losing any of my top-level bindings, especially since those bindings may contain essential state about the application. If, instead, library redefinition creates a fresh set of syntactic bindings, there's a substantial risk of losing *all* state when evolving a running program. Users will wind up creating little locative-like libraries to hold variables whose values should not be lost when reloading libraries. I consider this a very undesirable outcome. (As an aside, I'm somewhat confused by the use of the word "module" here. Is this being done deliberately to distinguish something being proposed from the R6RS libraries, and if so, why?) -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
