Release Notes

This chapter describes interesting features and problems for the 7.3 release.

News

The last full release of the MIT Scheme system was version 7.1.3 in 1991. Since that time, there was a partial release of version 7.2 for i386/i486 machines and some MIPS R3000 machines. This section summarizes the changes that have occurred since version 7.1.3. The changes are divided into two parts: those that were incorporated in the 7.2 partial release, and those that were subsequently incorporated.

Changes from Release 7.2 to 7.3

This is an abbreviated list of the changes that have been incorporated in the 7.3 release since the (partial) 7.2 release.

• Support for MS Windows (3.1 and NT).
• Native compiled-code support for DEC Alpha.
• Compiler can now generate C code. This is used to support the Sun SPARC and IBM RS6000 architectures.
• Support for dynamic loading of compiled C code on several operating systems, including HP-UX, OSF/1, SunOS 4, and AIX.
• New data structures: red/black trees and weight-balanced trees.
• Redesign of hash tables makes them much faster and somewhat more flexible.
• Completely new random-number generator. The interface to the random-number generator has been changed to be like that of Common Lisp.
• Record abstraction now uses a special record type to represent records (previously it used vectors). define-structure now creates records by default; these records are identical to those created with the record abstraction.
• call-with-current-continuation is now properly tail-recursive.
• New command-line switch -no-suspend-file prevents the generation of `scheme_suspend' files.
• Uncompression of compiled-code debugging information is now memoized to save time when doing many accesses to the same information (a common occurrence).
• Constant space now grows automatically when needed.
• New procedures:

  call-with-values                ;replaces with-values
  current-load-pathname
  error-output-port
  fold-left
  fold-right
  interaction-i/o-port
  notification-output-port
  prompt-for-command-char
  prompt-for-command-expression
  prompt-for-confirmation
  prompt-for-evaluated-expression
  prompt-for-expression
  standard-unparser-method        ;replaces unparser/standard-method
  stream-first
  stream-rest
  symbol<?
  trace-output-port
  

• string-pad-left now truncates from the left instead of the right.
• Argument to make-graphics-device is now a symbol.
• Each REPL now has its own working directory pathname and pathname defaults. set-working-directory-pathname! changes only the value for the current REPL.
• The definitions of the following procedures have been changed to implement more useful behavior:

  string-capitalized?
  string-lower-case?
  string-upper-case?
  substring-capitalized?
  substring-lower-case?
  substring-upper-case?
  

• New Edwin features:

  M-x dabbrev-expand
  M-x describe-syntax
  M-x rcs-ci-locked-files
  M-x rcs-diff
  M-x rcs-list-locked-files
  M-x rcs-log
  M-x recover-file
  M-x show-parameter-list
  M-x sort-lines and other sorting commands
  auto-mode-alist variable (as in Emacs)
  Encryption/decryption of files in Dired
  Undo upgraded to match GNU Emacs 18.57
  Buffers grow/shrink with constant amortized time
  Emacs 19 tags support (multiple tags files, inclusion)
  

• Edwin compression/uncompression commands changed to use gzip instead of compress.
• Edwin now has text-properties mechanism that permits implementation of highlighted and mouse-sensitive regions.

Changes from Release 7.1 to 7.2

This is an abbreviated list of the changes that were incorporated in the (partial) 7.2 release since the 7.1 release.

• Support for MS DOS.
• Native compiled-code support for the Intel i386 and i486 architectures.
• Fixes to MIPS compiled-code support MIPS R3000 with large cache-line sizes.
• Complete redesign of the error system.
• X11 graphics interface redesigned. The new design is smarter about interaction with the window manager (for example, it implements the WM_DELETE_WINDOW protocol) and has some limited support for event handling. Windows are now closed when they are reclaimed by the garbage collector.
• Redesign of I/O ports. New design supports ports that perform both input and output.
• Ports now have better-defined control over blocking mode and terminal mode. Flushing of output buffers is not done automatically, except for the console port.
• New procedures:

  *default-pathname-defaults*
  ->namestring
  ->truename
  close-port
  directory-namestring
  directory-pathname
  directory-pathname-as-file
  enough-namestring
  enough-pathname
  file-access
  file-attributes-direct          ;same as file-attributes
  file-modification-time-direct
  file-modification-time-indirect ;same as file-modification-time
  file-namestring
  file-pathname
  file-readable?
  host-namestring
  i/o-port?
  make-generic-i/o-port
  make-i/o-port
  open-i/o-file
  pathname-simplify
  pathname-wild?
  pathname=?
  port/copy
  port/input-channel
  port/operation
  port/operation-names
  port/output-channel
  port/state
  port?
  record-copy
  record-modifier                 ;replaces record-updater
  set-port/state!
  

• with-input-from-file and with-output-to-file no longer close the port when they are exited abnormally.
• Redefined #!optional and #!rest to be something distinct from symbols.
• Strings now accept "\nnn" octal character escapes, much like those in C.
• Redesign of pathname abstraction. New design is very similar to the Common Lisp pathname abstraction.
  • ->PATHNAME no longer accepts a symbol as an argument. Only strings and pathnames are valid.
  • Procedures eliminated:

    canonicalize-input-filename
    canonicalize-input-pathname
    canonicalize-output-filename
    canonicalize-output-pathname
    canonicalize-overwrite-filename
    canonicalize-overwrite-pathname
    home-directory-pathname
    init-file-truename
    pathname->absolute-pathname
    pathname->input-truename
    pathname->output-truename
    pathname->overwrite-truename
    pathname->string
    pathname-components
    pathname-default-host
    pathname-directory-path
    pathname-directory-string
    pathname-name-path
    pathname-name-string
    pathname-new-host
    pathname-relative?
    string->pathname
    symbol->pathname
    

  • pathname-default no longer accepts a host argument.
  • Representation of pathname directories changed to match Common Lisp. Directory is now either #f or a list of symbols and strings with first element either absolute or relative.
  • Unix pathnames now set device and version to unspecific. unspecific now means that the field is not used by the operating system.
  • Parsing rules for unix filenames changed: the file type is the part of the name after the last dot, if any. If the dot occurs at the beginning or end of the filename, then it doesn't count -- in that case there is no type. Thus, names like `.' and `..' have no type.
• New Edwin features:

  M-x manual-entry
  M-x outline-mode
  M-x shell-resync-dirs
  M-x shell-command
  M-x shell-command-on-region
  M-x telnet
  RMAIL summary
  RMAIL sort
  REPL mode and asynchronous evaluation
  Printing commands
  "run light" for evaluation commands
  Reading and writing of compressed files (".Z" suffix)
  Reading and writing of encrypted files (".KY" suffix)
  Compress/uncompress commands for Dired
  Support for X protocols: WM_DELETE_WINDOW and WM_TAKE_FOCUS
  Time, load, and mail notification in mode line
  

C Back-End Release Notes

This release introduces an important new feature: the compiler can generate output in C, which can then be compiled and linked using the usual C development tools. This feature is being used to support architectures, such as the SPARC and IBM RS6000, for which the compiler does not have native-code support.

MIT Scheme systems that have been built using this compiler feature are referred to as C back-end systems. This section provides a brief description of the features and known problems for such systems.

General Notes

This section describes the general design of C back-end systems.

• The C back end was written very recently, and we do not use it ourselves for development--we have native back ends for the hardware that we use regularly. Furthermore, most of the system-building tools and changes were put together and tested immediately preceding the release. It is not unlikely that there are serious problems and shortcomings. We'd like to hear about them so we can fix them or bypass them for a future release. If something does not work, do not assume that we know about it. Please report it. The worse that can happen is that we hear about it several times.
• The compiler produces C code that works in the context of the MIT Scheme runtime library. It is not stand-alone code, and there is currently no way to generate stand-alone executables.
• We have done some performance testing on machines where we have both a native back end and the C back end. The C back end code is somewhat larger and slower than the native code. The speed varies depending primarily on the number of inter-C-procedure calls (even within a single source file). In some cases the C code is somewhat faster than the native code, but it is usually noticeably slower. The average is about 2.5 times slower.
• The output code should work on virtually any modern general-purpose architecture with an ANSI-compliant (perhaps even a traditional K&R) C compiler. We've tried it on several 32-bit architectures (HP PA, Sparc, Motorola 68040, RS6000/Power) and a 64-bit architecture (Alpha). However, there may very well be assumptions of the following form:
  • Memory is byte-addressable.
  • Addresses and ordinary data live in the same memory. Some special-purpose processors do not satisfy this constraint.
  • unsigned data items and addresses fit into the same memory, and if union-ed, take the same space.
  • Signed integers are represented using 2s-complement representation.
  • The machine/OS uses the ASCII character set. This is not a property of the compiler per-se, but of the MIT Scheme system.
  In addition, some configuration of the compiler, microcode and build-scripts would have to be done for new architectures/operating systems. The things that come to mind are:
  • Dynamic loading primitives are OS-dependent.
  • Basic microcode configuration, including:
    • OS interface.
    • Choosing a new machine type (FASL numbers in `config. h').
  • Build scripts dispatch on the OS and architecture type, and only understand a handful of types.
  • The compiler has a table of C compiler and linker switches for the configurations we have tried. It needs to be extended for new configurations, although this can be done easily.
  If you are interested in bringing up the system on a new configuration, please contact us for further instructions, and to obtain the set of crude tools that we use to do this.
• The performance of the output code could be greatly improved by judicious use of assembly language to achieve faster cross-module tail recursion. So far, we've given more weight to portability than to performance.
• The resulting C code can be compiled and statically linked with the MIT Scheme microcode (the runtime library is linked in this way), or compiled and dynamically loaded and linked if the operating system supports this feature. The C code must be compiled defining the COMPILE_FOR_STATIC_LINKING if it is to be statically linked into the microcode or collected into a larger dynamically-loadable library (e.g. edwin or the compiler). If you'd like to put together a shared library of a large subsystem that you have written, please contact us for advice on how it can be done.

Problems with the C Back-End

This section details problems and shortcomings of the system that are specific to the C back-end.

• compile-procedure and compile-scode do not work. This will be fixed for a future release and is not very hard to bypass in most cases. compile-procedure gives an error. compile-scode returns something which is not a compiled expression. cf and compile-bin-file work.
• Dynamically loaded compiled modules are not unloaded when no longer accessed. In particular, after a disk-restore, previously loaded modules are still mapped. In addition, at least in some versions of unix, the shared object file cannot be deleted while it is loaded, so recompilation of a module in place will fail if some process has it already loaded.
• Multiple loading does not work. This is bad for development. After loading a compiled module once, it cannot be reloaded (presumably after recompilation).
• fasdump does not work for compiled code. It gives an error. Only bands can be dumped.
• Several C compilers are unhappy about the size of the resulting C procedures. They often turn their optimizers off.
• Some C compilers/optimizers produce non-working code for some of the output. In particular, we've had serious problems with the RS6000/AIX-3.2 C compiler.
• Several C compilers give copious "statement not reached" warnings about the resulting code. This arises from the heavy use of macros expanding into the pattern

  do
  {
    body
  } while (0)
  

  Most of these macros are not really necessary, and the code generator could just issue the body directly.
• The mechanism for accreting object files into large dynamically-loadable libraries is currently ad-hoc.

PC Release Notes

Known Problems in this Beta Release

• The Windows version of MIT Scheme is more robust under NT than Windows 3.1
• [NT] Exclusive file access problems. Edwin sometimes can't write a file that is still open for reading. Typically you will have entered (load "foo.scm") in the interaction buffer and got an error, say a mis-matched parenthesis. You then switch to the foo.scm buffer, fix the problem and then try to save the file. Edwin refuses, saying

  Unable to open file "your-path\\foo.scm" because: Unknown
  

  Work-around: In the interaction buffer: Quit to top level. Do a (gc-flip), which forces the file to be closed when the file port is garbage-collected. Now you will be able to save the file.
• MITSCHEME_INF_DIRECTORY sometimes does not work. The runtime system cannot find the debugging information unless it is on the `C:' drive. To test if the debugging information is available, try

  (pp pp)
  

  If the debugging information is available the pp procedure pretty-prints procedures as Scheme code. If the information cannot be found then it prints the procedure as an opaque object, similar to this:

  #[compiled-procedure 13 ("pp" #x2) #xF #x646BF7]
  

• Edwin autoloads. A few files that are automatically part of Edwin under unix are not part of Edwin in the PC. These can be loaded manually from the auto-load directory, for example, by putting

  (edwin-load "dabbrev")
  

  in your `edwin.ini' file.
• DOS version 6. Although we have not tested the DOS version under anythig other than MS-DOS 5.0, we have the following anecdotal evidence:
  • On DOS 6.2 with emm386 you may have to put the following in `config.sys':

    device=emm386 noems novcpi