The notion of “top-level program” is new in R6RS and replaces the notion of “Scheme program” in R5RS. The two are quite different: While a R6RS top-level program is defined to be a complete, textual entity, an R5RS program could evolve by being entered piecemeal into a running Scheme system. Many Scheme systems have interactive command-line environments based on the semantics of R5RS programs. However, the specification of R5RS programs was not really sufficient do describe how to operate an arbitrary Scheme system: The R5RS is ambiguous on some aspects of the semantics such as binding. Moreover, R5RS’s load procedure does say how to load source code into the running system, but the pragmatics of load would often make compiling programs before execution problematic, in particular with regard to macros. Furthermore, Scheme implementations handle treatment of and recovery from errors in wildly different ways.
Tightening the specification of programs from R5RS would have been possible, but could have restricted the design employed by Scheme implementations in undesirable ways. Moreover, alternative approaches to structuring the user interface of a Scheme implementation have emerged since R5RS. Consequently, R6RS makes no attempt of trying to specify the semantics of programs as in R5RS; the design of an interactive environment is now completely in the hands of the implementors. On the other hand, being able to distribute portable programs as one of the goals of the R6RS process. As a result, the notion of top-level program was added to the report.
By allowing the interleaving of definitions and expressions, top-level programs support exploratory and interactive development, without imposing unnecessary organizational overhead on code which may not be intended for reuse.