Guile NEWS --- history of user-visible changes. 2 Aug 1996 -*- text -*- Copyright (C) 1996 Free Software Foundation, Inc. See the end for copying conditions. Please send Guile bug reports to bug-guile@prep.ai.mit.edu. Guile 1.0b3 Changes since Thursday, September 5: * Guile now distinguishes between #f and the empty list. This is for compatibility with the IEEE standard, the (possibly) upcoming Revised^5 Report on Scheme, and many extant Scheme implementations. Guile used to have #f and '() denote the same object, to make Scheme's type system more compatible with Emacs Lisp's. However, the change caused too much trouble for Scheme programmers, and we found another way to reconcile Emacs Lisp with Scheme that didn't require this. * You can now use Guile as a shell script interpreter. To paraphrase the SCSH manual: When Unix tries to execute an executable file whose first two characters are the `#!', it treats the file not as machine code to be directly executed by the native processor, but as source code to be executed by some interpreter. The interpreter to use is specified immediately after the #! sequence on the first line of the source file. The kernel reads in the name of the interpreter, and executes that instead. It passes the interpreter the source filename as its first argument, with the original arguments following. Consult the Unix man page for the `exec' system call for more information. Now you can use Guile as an interpreter, using a mechanism which is a compatible subset of that provided by SCSH. Guile now recognizes a '-s' command line switch, whose argument is the name of a file of Scheme code to load. It also treats the two characters `#!' as the start of a comment, terminated by `!#'. Thus, to make a file of Scheme code directly executable by Unix, insert the following two lines at the top of the file: #!/usr/local/bin/guile -s !# Guile treats the argument of the `-s' command-line switch as the name of a file of Scheme code to load, and treats the sequence `#!' as the start of a block comment, terminated by `!#'. For example, here's a version of 'echo' written in Scheme: #!/usr/local/bin/guile -s !# (let loop ((args (cdr (program-arguments)))) (if (pair? args) (begin (display (car args)) (if (pair? (cdr args)) (display " ")) (loop (cdr args))))) (newline) Why does `#!' start a block comment terminated by `!#', instead of the end of the line? That is the notation SCSH uses, and although we don't yet support the other SCSH features that motivate that choice, we would like to be backward-compatible with any existing Guile scripts once we do. Furthermore, if the path to Guile on your system is too long for your kernel, you can start the script with this horrible hack: #!/bin/sh exec /really/long/path/to/guile -s "$0" ${1+"$@"} !# Note that some very old Unix systems don't support the `#!' syntax. * You can now run Guile without installing it. Previous versions of the interactive Guile interpreter (`guile') couldn't start up unless Guile's Scheme library had been installed; they used the value of the environment variable `SCHEME_LOAD_PATH' later on in the startup process, but not to find the startup code itself. Now Guile uses `SCHEME_LOAD_PATH' in all searches for Scheme code. To run Guile without installing it, build it in the normal way, and then set the environment variable `SCHEME_LOAD_PATH' to a colon-separated list of directories, including the top-level directory of the Guile sources. For example, if you unpacked Guile so that the full filename of this NEWS file is /home/jimb/guile-1.0b3/NEWS, then you might say export SCHEME_LOAD_PATH=/home/jimb/my-scheme:/home/jimb/guile-1.0b3 * Guile's header files should no longer conflict with your system's header files. In order to compile code which #included , previous versions of Guile required you to add a directory containing all the Guile header files to your #include path. This was a problem, since Guile's header files have names which conflict with many systems' header files. Now only need appear in your #include path; you must refer to all Guile's other header files as . Guile's installation procedure puts libguile.h in $(includedir), and the rest in $(includedir)/libguile. * Guile's delq, delv, delete functions, and their destructive counterparts, delq!, delv!, and delete!, now remove all matching elements from the list, not just the first. This matches the behavior of the corresponding Emacs Lisp functions, and (I believe) the Maclisp functions which inspired them. I recognize that this change may break code in subtle ways, but it seems best to make the change before the FSF's first Guile release, rather than after. * The compiled-library-path function has been deleted from libguile. * A variable and two new functions have been added to libguile: ** The variable %load-path now tells Guile which directories to search for Scheme code. Its value is a list of strings, each of which names a directory. ** (%search-load-path FILENAME) searches the directories listed in the value of the %load-path variable for a Scheme file named FILENAME. If it finds a match, then it returns its full filename. Otherwise, it returns #f. %search-load-path will not return matches that refer to directories. ** (%try-load-path FILENAME :optional CASE-INSENSITIVE-P SHARP) searches the directories listed in %load-path for a file named FILENAME, and loads it if it finds it. If it can't read FILENAME for any reason, it throws an error. The arguments CASE-INSENSITIVE-P and SHARP are interpreted as by the %try-load function. Older changes: * Guile no longer includes sophisticated Tcl/Tk support. The old Tcl/Tk support was unsatisfying to us, because it required the user to link against the Tcl library, as well as Tk and Guile. The interface was also un-lispy, in that it preserved Tcl/Tk's practice of referring to widgets by names, rather than exporting widgets to Scheme code as a special datatype. In the Usenix Tk Developer's Workshop held in July 1996, the Tcl/Tk maintainers described some very interesting changes in progress to the Tcl/Tk internals, which would facilitate clean interfaces between lone Tk and other interpreters --- even for garbage-collected languages like Scheme. They expected the new Tk to be publicly available in the fall of 1996. Since it seems that Guile might soon have a new, cleaner interface to lone Tk, and that the old Guile/Tk glue code would probably need to be completely rewritten, we (Jim Blandy and Richard Stallman) have decided not to support the old code. We'll spend the time instead on a good interface to the newer Tk, as soon as it is available. Until then, gtcltk-lib provides trivial, low-maintenance functionality. Copyright information: Copyright (C) 1996 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and this permission notice are preserved, thus giving the recipient permission to redistribute in turn. Permission is granted to distribute modified versions of this document, or of portions of it, under the above conditions, provided also that they carry prominent notices stating who last changed them.