STEPS TO TAKE TO ALLOW SWITCHING BETWEEN
		       RUN AND READ-EVAL-PRINT
		 FOR THE CHARACTER STRING PARSERS OF
		 ESSENTIALS OF PROGRAMMING LANGUAGES
		 (File $Date: 1998/10/16 02:00:43 $)

			   Gary T. Leavens
	Department of Computer Science, Iowa State University
			leavens@cs.iastate.edu

To use the character string parser in teaching EOPL,
one faces a problem because the run procedure and the read-eval-print
loop of Appendix F have fundamentally different ways of interacting with
the parser and scanner.  If you load Appendix F, then the run procedure
doesn't work.  Conversely, if, after loading Appendix F,
you get the run procedure to work by reloading the character string parser,
then the read-eval-print loop will not work.

We wanted to set things up so that the following goals were met:

	1. Students can switch between using run and read-eval-print at will.
	2. Our testing code could use the run procedure, despite the students
	   having already loaded the Appendix F code.
	3. Students would not get any confusing error message.

To meet goal 1, we have the students load a file, either run.scm or rep.scm,
depending on what front-end they want to use.

To meet goal 2, the file that contains the run procedure, run.scm,
has to either reload the character string parser or
reload the definitions that were "clobbered" by the Appendix F code
(as we do).

To meet goal 3, we provide files that "undefine" either the run or
read-eval-print procedures (undefine-run.scm, undefine-read-eval-print.scm)
by defining them to produce a suitable error message.  These files
are loaded by the file that encapsulates the code for a section of EOPL;
so that when students load the code, they have to choose what interface to use.
Another way to do this would be to pick one to be the default.
In addition, loading one interface "undefines" the other, by loading the
appropriate file; thus instead of a confusing error message, a student
will get a message telling which interface to load.

Some details:

The eval-print procedure in Appendix F doesn't work for the interpreters
in section 5.1-2, because it passes the initial environment;
and so we provide rep5-1.scm that has the appropriate definition for those
sections.

The run procedure in section 5.1 only works for such interpreters,
so we provide that procedure in a file run5-1.scm, and one that passes
the initial environment is in the file run.scm.

Similarly, for chapter 7, additional arguments are needed by the
interpreters.  So we provide rep-for-oop.scm for those chapters.

Differences in top-level forms are handled by having each chapter's
file include a different version of the eval-form procedure.

Differences in syntactic sugars are handled by having each chapter's
file include a different version of the syntax-expand procedure.

We use a procedure, load-from-lib, that is loaded by default from a shell
script (scm342) that the students use in class.
Students can port this to their PC or whatever
if they are not using our department's machines.  Alternatively,
this could be defined using the facilities of SCM or SLIB, if those are used.
You would, of course, replace the value of the variable libdir
to customize it.


The files are organized as follows, where
	A
	B    F
	| \ /
	C  E
means that file C.scm loads both A.scm and B.scm,
and that file E.scm loads both A.scm and B.scm and also loads F.scm.


	undefine-read-eval-print
        char-parser-connections 
         |                      \
	run5-1                    run
	        			

                                  eval-print-with-define
	undefine-run             /
        appendix-f     eval-print
         |        \   /
        rep5-1     rep


The files for chapter 7 are organized a bit differently.

	undefine-run
        appendix-f     eval-print-for-oop
                  \   /
                rep-for-oop