little stuff on manual

[bpt/guile.git] / NEWS

Guile NEWS --- history of user-visible changes.  -*- text -*-
Copyright (C) 1996, 1997 Free Software Foundation, Inc.
See the end for copying conditions.

Please send Guile bug reports to bug-guile@prep.ai.mit.edu.
\f
Changes since Guile 1.0 (Sun 5 Jan 1997):

\f
Guile 1.0b3

User-visible changes from Thursday, September 5, 1996 until Guile 1.0:

* Changes to the 'guile' program:

** Guile now loads some new files when it starts up.  Guile first
searches the load path for init.scm, and loads it if found.  Then, if
Guile is not being used to execute a script, and the user's home
directory contains a file named `.guile', Guile loads that.

** 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 read-eval-print loop no longer prints #<unspecified>
results.  If the user wants to see this, she can evaluate the
expression (assert-repl-print-unspecified #t), perhaps in her startup
file. 

** Guile no longer shows backtraces by default when an error occurs;
however, it does display a message saying how to get one, and how to
request that they be displayed by default.  After an error, evaluate
   (backtrace)
to see a backtrace, and
   (debug-enable 'backtrace)
to see them by default.



* Changes to Guile Scheme:

** 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.


** 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.

** The facilities for loading Scheme source files have changed.

*** 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.

*** The variable %load-extensions now tells Guile which extensions to
try appending to a filename when searching the load path.  Its value
is a list of strings.  Its default value is ("" ".scm").

*** (%search-load-path FILENAME) searches the directories listed in the
value of the %load-path variable for a Scheme file named FILENAME,
with all the extensions listed in %load-extensions.  If it finds a
match, then it returns its full filename.  If FILENAME is absolute, it
returns it unchanged.  Otherwise, it returns #f.

%search-load-path will not return matches that refer to directories.

*** (primitive-load FILENAME :optional CASE-INSENSITIVE-P SHARP)
uses %seach-load-path to find 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
`read' function.

*** load uses the same searching semantics as primitive-load.

*** The functions %try-load, try-load-with-path, %load, load-with-path,
basic-try-load-with-path, basic-load-with-path, try-load-module-with-
path, and load-module-with-path have been deleted.  The functions
above should serve their purposes.

*** If the value of the variable %load-hook is a procedure,
`primitive-load' applies its value to the name of the file being
loaded (without the load path directory name prepended).  If its value
is #f, it is ignored.  Otherwise, an error occurs.

This is mostly useful for printing load notification messages.


** The function `eval!' is no longer accessible from the scheme level.
We can't allow operations which introduce glocs into the scheme level,
because Guile's type system can't handle these as data.  Use `eval' or
`read-and-eval!' (see below) as replacement.

** The new function read-and-eval! reads an expression from PORT,
evaluates it, and returns the result.  This is more efficient than
simply calling `read' and `eval', since it is not necessary to make a
copy of the expression for the evaluator to munge.

Its optional arguments CASE_INSENSITIVE_P and SHARP are interpreted as
for the `read' function.


** The function `int?' has been removed; its definition was identical
to that of `integer?'.

** The functions `<?', `<?', `<=?', `=?', `>?', and `>=?'.  Code should
use the R4RS names for these functions.

** The function object-properties no longer returns the hash handle;
it simply returns the object's property list.

** Many functions have been changed to throw errors, instead of
returning #f on failure.  The point of providing exception handling in
the language is to simplify the logic of user code, but this is less
useful if Guile's primitives don't throw exceptions.

** The function `fileno' has been renamed from `%fileno'.

** The function primitive-mode->fdes returns #t or #f now, not 1 or 0.


* Changes to Guile's C interface:

** The library's initialization procedure has been simplified.
scm_boot_guile now has the prototype:

void scm_boot_guile (int ARGC,
                     char **ARGV,
                     void (*main_func) (),
                     void *closure);

scm_boot_guile calls MAIN_FUNC, passing it CLOSURE, ARGC, and ARGV.
MAIN_FUNC should do all the work of the program (initializing other
packages, reading user input, etc.) before returning.  When MAIN_FUNC
returns, call exit (0); this function never returns.  If you want some
other exit value, MAIN_FUNC may call exit itself.

scm_boot_guile arranges for program-arguments to return the strings
given by ARGC and ARGV.  If MAIN_FUNC modifies ARGC/ARGV, should call
scm_set_program_arguments with the final list, so Scheme code will
know which arguments have been processed.

scm_boot_guile establishes a catch-all catch handler which prints an
error message and exits the process.  This means that Guile exits in a
coherent way when system errors occur and the user isn't prepared to
handle it.  If the user doesn't like this behavior, they can establish
their own universal catcher in MAIN_FUNC to shadow this one.

Why must the caller do all the real work from MAIN_FUNC?  The garbage
collector assumes that all local variables of type SCM will be above
scm_boot_guile's stack frame on the stack.  If you try to manipulate
SCM values after this function returns, it's the luck of the draw
whether the GC will be able to find the objects you allocate.  So,
scm_boot_guile function exits, rather than returning, to discourage
people from making that mistake.

The IN, OUT, and ERR arguments were removed; there are other
convenient ways to override these when desired.

The RESULT argument was deleted; this function should never return.

The BOOT_CMD argument was deleted; the MAIN_FUNC argument is more
general.


** Guile's header files should no longer conflict with your system's
header files.

In order to compile code which #included <libguile.h>, 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 <libguile.h> need appear in your #include path; you must
refer to all Guile's other header files as <libguile/mumble.h>.
Guile's installation procedure puts libguile.h in $(includedir), and
the rest in $(includedir)/libguile.


** Two new C functions, scm_protect_object and scm_unprotect_object,
have been added to the Guile library.

scm_protect_object (OBJ) protects OBJ from the garbage collector.
OBJ will not be freed, even if all other references are dropped,
until someone does scm_unprotect_object (OBJ).  Both functions
return OBJ.

Note that calls to scm_protect_object do not nest.  You can call
scm_protect_object any number of times on a given object, and the
next call to scm_unprotect_object will unprotect it completely.

Basically, scm_protect_object and scm_unprotect_object just
maintain a list of references to things.  Since the GC knows about
this list, all objects it mentions stay alive.  scm_protect_object
adds its argument to the list; scm_unprotect_object remove its
argument from the list.


** scm_eval_0str now returns the value of the last expression
evaluated.

** The new function scm_read_0str reads an s-expression from a
null-terminated string, and returns it.

** The new function `scm_stdio_to_port' converts a STDIO file pointer
to a Scheme port object.

** The new function `scm_set_program_arguments' allows C code to set
the value teruturned by the Scheme `program-arguments' function.

\f
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.

\f
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.