On Fri, Aug 5, 2011 at 6:43 AM, John Cowan <[email protected]> wrote: > Alex Shinn scripsit: > >> The result is that any program can be cut&paste into >> an interactive REPL and still work, and any interactive >> session can be saved and used as a program, so long >> as it's prefixed with (import (scheme base)). > > Yes to the first, no to the second, because the REPL session > may use names bound in the REPL but not imported into the > top-level environment. This is precisely why I don't want > the top-level environment to be different from the REPL. > If you want a clean environment, write a module.
We voted on this in #159, but we can certainly revisit it. I think I see what Denis was complaining about originally. Not that we should copy the R6RS section on top-level programs, but that we should provide a definition of what the top-level is. R5RS leaves the term "top-level" vague, but R5RS effectively gives no way of reliably writing a portable program, even ignoring differences in unspecified behavior - the available bindings diff between implementations. So (mumble) may work in your own Scheme but not be available elsewhere. Obviously for precise namespace management we want modules, but people still want to write top-level programs and I really think we need to define exactly what bindings are available. On the other hand, "batch" and "interactive" don't describe the whole picture. A remote RPC server doesn't quite follow either definition, and an initial environment in an extension language may be referenced in arbitrary manners by callbacks. So rather than provide a definition, I intentionally kept the R5RS vagueness and described the one exception case - if an implementation provides a REPL, it provides at least (scheme base) by default. However, since we leave room for implementation-specific extensions, and the batch/interactive modes are by far the most common cases, it probably makes sense to focus on them. I'll write a more clear definition. -- Alex _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
