Files containing Chez Scheme source code conventionally end in .ss (``Scheme source''). Unfortunately, the Scheme mode supplied with XEmacs does not recognize this convention, so Chez Scheme programmers are encouraged to add the following line to their ~/.emacs files:
(setq auto-mode-alist (cons '("\\.ss$" . scheme-mode) auto-mode-alist))As long as you're editing ~/.emacs anyway, I also recommend adding the following lines, the effects of which are explained at the end of this document:
(add-hook 'scheme-mode-hook (lambda () (setq scheme-mit-dialect nil) (auto-fill-mode 1))) (defun run-chez-scheme () (interactive "*") (if (< (count-windows) 2) (split-window)) (run-scheme "/usr/local/bin/scheme")) (global-set-key [f1] 'run-chez-scheme) (global-set-key [kp_enter] 'xscheme-send-previous-expression)In Scheme mode, pressing the <Tab> key automatically indents the line containing the editing cursor to the correct position. If you follow every carriage return with a tab, you'll always have correctly indented Scheme code.
One of the traditional hazards for novice Scheme programmers is keeping track of the parentheses in a deeply nested expression and making sure that they are matched up correctly. XEmacs simplifies this process by automating it. Every time you type a right parenthesis in Scheme mode, XEmacs inserts it and then briefly highlights the corresponding left parenthesis (without changing the point at which subsequent characters will be inserted). By watching the highlighting as you type in right parentheses, you can ensure that each of them matches the appropriate left parenthesis, or make a correction if any of them does not.
To transfer definitions and expressions from an XEmacs editing window to a Chez Scheme interactive interface running in a visible hpterm window, you can simply cut and paste: Move the mouse pointer to the beginning of the definition or expression, press and hold the left mouse button, drag to the end of the definition or expression, release the left mouse button, move the mouse pointer into the window where Chez Scheme is running, and click on the middle mouse button. The selected text will be submitted to Chez Scheme, just as if you had typed it in from the keyboard.
Once a file is saved, however, there are simpler ways of getting Chez Scheme to read it. One is to name the file on the command line that starts up Chez Scheme:
bourbaki% scheme frogs.ss Chez Scheme Version 5.0c Copyright (c) 1994 Cadence Research Systems >Chez Scheme reads and processes the program in frogs.ss before going into interactive mode and issuing the prompt. This is handy if you have a library of definitions that you want to load in before beginning to interact with Chez Scheme. Any number of files may be named on the command line in this way.
It is also possible to load a Scheme program in the middle of a session by
Load takes one
argument, a string (enclosed in double quotation marks) giving the name of
the file containing the program. The procedure opens up that file and
causes its contents to be read in and compiled,
bourbaki% scheme > (load "frogs.ss") >If there is no such file -- for instance, if the programmer forgot to have XEmacs save it before trying to load it -- Chez Scheme prints an error message and generates a new prompt:
> (load "foo.ss") Error in open-input-file: error opening "foo.ss": No such file or directory. Type (debug) to enter the debugger. >A typical cycle in the development of a program is discovering an error by experimentation in the interactive interface, fixing it in XEmacs by revising a definition in a Scheme program file, saving the file from XEmacs, reloading it with the
loadprocedure, and resuming testing. It would not be unusual to have both the hpterm window running Chez Scheme and the XEmacs window containing a Scheme program open, side by side, throughout a programming session.
Since XEmacs still wants to provide full-window editing, it does not transmit definitions and expressions to the interactive interface when a line break is inserted (as for instance when the programmer presses the <Enter> key that is just above the right-hand <Shift> key, on the typewriter part of the HP keyboard. Instead, XEmacs requires the programmer to signal explicitly that she has finished editing a definition or an expression and wants Chez Scheme to deal with it. The other <Enter> key, the one in the lower right-hand corner of the numeric keypad, is used for this purpose. When it is pressed, XEmacs collects all of the Scheme definition or expression that immediately precedes the editing cursor and transmits it to Chez Scheme for processing -- no matter which subwindow the editing cursor is in. Chez Scheme always displays its response in the subwindow where it is running.
Of course, it is also possible to cut and paste between subwindows within XEmacs, and some programmers will find that the contents of the Scheme buffer are easier to read if they use this technique every time they want to submit something to Chez Scheme. But it is also possible to edit a definition in whichever subwindow happens to be more convenient and then simply press the keypad <Enter> key to load that definition into Chez Scheme.
When Chez Scheme is running in an XEmacs window, you can't shut it down
with <Control/D>, since XEmacs regards this as a
delete-character command. Type
(exit) instead. Although this
has the syntax of a procedure call, Chez Scheme recognizes it as a shutdown
(Here's the effect of the extra lines that I recommended adding to ~/.emacs: (1) On entry to Scheme mode, XEmacs is informed that you are running some implementation of Scheme other than MIT Scheme, and word wrapping is turned on. (2) An XEmacs command is defined that runs the Chez Scheme interactive interface in an XEmacs window. (3) This command is bound to function key <F1> on the HP keyboard, and the XEmacs command that sends the Scheme expression that immediately precedes the editing cursor to the Chez Scheme interactive interface is bound to the <Enter> key over on the numeric keypad.)
Workshop front door ... Running Chez Scheme ... Debugging ... Scheme bibliography
John David Stone (firstname.lastname@example.org)