The report does not specify how source code is represented and stored. The only requirement the report imposes is that the source code of a top-level program (see report section on “Top-level program syntax”) or a script (see section D.2) be delimited. The source code of a library is self-delimiting in the sense that, if the beginning of a library form can be identified, so can the end.
Implementations may take radically different approaches to storing source code for libraries, among them: files in the file system where each file contains an arbitrary number of library forms, files in the file system where each file contains exactly one library form, records in a database, and data structures in memory.
Similarly, programs and scripts may be stored in a variety of formats. Platform constraints may restrict the choices available to an implementation, which is why the report neither mandates nor recommends a specific method for storage.
Implementations may provide a means for importing libraries coming from the outside via an interface that accepts a UTF-8 text file in Unicode Normalization Form C where line endings are encoded as linefeed characters. Such text files may contain an arbitrary number of library forms. (Authors of such files should include an #!r6rs comment if the file is written purely with the lexical and datum syntax described in the report. See report section on “Whitespace and comments”.) After importing such a file, the libraries defined in it should be available to other libraries and files. An implementation may store the file as is, or convert it to some storage format to achieve this.
Similarly, implementations may provide a means for executing a program represented as a UTF-8 text file containing its source code. Again, authors of such files should include an #!r6rs comment if the file is written purely with the lexical and datum syntax described in the report. This report does not describe a file format that allows both libraries and programs to appear in the same file.