Guile NEWS --- history of user-visible changes.
-Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
See the end for copying conditions.
Please send Guile bug reports to bug-guile@gnu.org.
you will get threads that are implemented with the portable POSIX
threads. These threads can run concurrently (unlike the previous
"coop" thread implementation), but need to cooperate for things like
-the GC. See the manual for details. [XXX - write this.]
+the GC.
The default is "pthreads", unless your platform doesn't have pthreads,
in which case "null" threads are used.
+See the manual for details, nodes "Initialization", "Multi-Threading",
+"Blocking", and others.
+
+** There is the new notion of 'discouraged' features.
+
+This is a milder form of deprecation.
+
+Things that are discouraged should not be used in new code, but it is
+OK to leave them in old code for now. When a discouraged feature is
+used, no warning message is printed like there is for 'deprecated'
+features. Also, things that are merely discouraged are nevertheless
+implemented efficiently, while deprecated features can be very slow.
+
+You can omit discouraged features from libguile by configuring it with
+the '--disable-discouraged' option.
+
+** Deprecation warnings can be controlled at run-time.
+
+(debug-enable 'warn-deprecated) switches them on and (debug-disable
+'warn-deprecated) switches them off.
+
** New module (ice-9 serialize):
(serialize FORM1 ...) and (parallelize FORM1 ...) are useful when
C code primitive), enabling the computations to run in parallel
while the scripting code runs single-threadedly.
-** New module (srfi srfi-26)
+** Support for require-extension, SRFI-55, has been added.
+
+The SRFI-55 special form `require-extension' has been added. It is
+available at startup, and provides a portable way to load Scheme
+extensions. SRFI-55 only requires support for one type of extension,
+"srfi"; so a set of SRFIs may be loaded via (require-extension (srfi 1
+13 14)).
+
+** New module (srfi srfi-26) provides support for `cut' and `cute'.
-This is an implementation of SRFI-26.
+The (srfi srfi-26) module is an implementation of SRFI-26 which
+provides the `cut' and `cute' syntax. These may be used to specialize
+parameters without currying.
** New module (srfi srfi-31)
Support for translating the documentation into HTML is now always
provided. Use 'make html'.
+** The configure option '--disable-arrays' has been removed.
+
+Support for arrays and uniform numeric arrays is now always included
+in Guile.
+
* Changes to the stand-alone interpreter
** New command line option `-L'.
* Changes to Scheme functions and syntax
+** Guardians have changed back to their original semantics
+
+Guardians now behave like described in the paper by Dybvig et al. In
+particular, they no longer make guarantees about the order in which
+they return objects, and they can no longer be greedy.
+
+They no longer drop cyclic data structures.
+
+The C function scm_make_guardian has been changed incompatibly and no
+longer takes the 'greedy_p' argument.
+
+** New function hashx-remove!
+
+This function completes the set of 'hashx' functions.
+
+** The concept of dynamic roots has been factored into continuation
+ barriers and dynamic states.
+
+Each thread has a current dynamic state that carries the values of the
+fluids. You can create and copy dynamic states and use them as the
+second argument for 'eval'. See "Fluids and Dynamic States" in the
+manual.
+
+To restrict the influence that captured continuations can have on the
+control flow, you can errect continuation barriers. See "Continuation
+Barriers" in the manual.
+
+The function call-with-dynamic-root now essentially temporarily
+installs a new dynamic state and errects a continuation barrier.
+
** The default load path no longer includes "." at the end.
Automatically loading modules from the current directory should not
There is the new notion of 'generalized vectors' and corresponding
procedures like 'generalized-vector-ref'. Generalized vectors include
-strings bitvectors, ordinary vectors, and uniform numeric vectors.
+strings, bitvectors, ordinary vectors, and uniform numeric vectors.
-Arrays use generalized vectors their storage, so that you still have
-arrays of characters, bits, etc. However, uniform-array-read! and
-uniform-array-write can no longer read/write strings and bitvectors.
+Arrays use generalized vectors as their storage, so that you still
+have arrays of characters, bits, etc. However, uniform-array-read!
+and uniform-array-write can no longer read/write strings and
+bitvectors.
** There is now support for copy-on-write substrings, mutation-sharing
substrings and read-only strings.
guile> #: foo
#:foo
+** The printing of symbols that might look like keywords can be
+ controlled.
+
+The new printer option 'quote-keywordish-symbols' controls how symbols
+are printed that have a colon as their first or last character. The
+default now is to only quote a symbol with #{...}# when the read
+option 'keywords' is not '#f'. Thus:
+
+ guile> (define foo (string->symbol ":foo"))
+ guile> (read-set! keywords #f)
+ guile> foo
+ :foo
+ guile> (read-set! keywords 'prefix)
+ guile> foo
+ #{:foo}#
+ guile> (print-set! quote-keywordish-symbols #f)
+ guile> foo
+ :foo
+
** 'while' now provides 'break' and 'continue'
break and continue were previously bound in a while loop, but not
These are convenient ways to run calculations in parallel in new
threads. See "Parallel forms" in the manual for details.
-** Fair mutexes and condition variables
-
-Fair mutexes and condition variables have been added. The fairness
-means that scheduling is arranged to give as equal time shares as
-possible and that threads are awakened in a first-in-first-out
-manner. This is not guaranteed with standard mutexes and condition
-variables.
-
-In addition, fair mutexes are recursive. Locking a fair mutex that
-you have already locked will succeed. Every call to lock-mutex must
-be matched with a call to unlock-mutex. Only the last call to
-unlock-mutex will actually unlock the mutex.
-
-A fair condition variable must be used together with a fair mutex,
-just as a standard condition variable must be used together with a
-standard mutex.
-
-*** New functions: make-fair-mutex, make-fair-condition-variable'
-
-Make a new fair mutex and a new fair condition variable respectively.
-
** New function 'try-mutex'.
This function will attempt to lock a mutex but will return immediately
C code can use the new functions scm_sigaction_for_thread and
scm_system_async_mark_for_thread to pass the new thread argument.
+When a thread blocks on a mutex, a condition variable or is waiting
+for IO to be possible, it will still execute system asyncs. This can
+be used to interrupt such a thread by making it execute a 'throw', for
+example.
+
** The function 'system-async' is deprecated.
You can now pass any zero-argument procedure to 'system-async-mark'.
* Changes to the C interface
-** There is the new notion of 'discouraged' features.
+** The functions scm_hash_fn_remove_x and scm_hashx_remove_x no longer
+ take a 'delete' function argument.
-This is a milder form of deprecation.
+This argument makes no sense since the delete function is used to
+remove a pair from an alist, and this must not be configurable.
-Things that are discouraged should not be used in new code, but it is
-OK to leave them in old code for now. When a discouraged feature is
-used, no warning message is printed like there is for 'deprecated'
-features. Also, things that are merely discouraged are nevertheless
-implemented efficiently, while deprecated features can be very slow.
+This is an incompatible change.
-You can omit discouraged features from libguile by configuring it with
-the '--disable-discouraged' option.
+** The GH interface is now subject to the deprecation mechanism
+
+The GH interface has been deprecated for quite some time but now it is
+actually removed from Guile when it is configured with
+--disable-deprecated.
+
+See the manual "Transitioning away from GH" for more information.
** A new family of functions for converting between C values and
Scheme values has been added.
the latter returns the true name of the keyword, not the 'dash name',
as SCM_KEYWORDSYM used to do.
+** A new way to access arrays in a thread-safe and efficient way has
+ been added.
+
+See the manual, node "Accessing Arrays From C".
+
** The old uniform vector and bitvector implementations have been
unceremoniously removed.
-This implementation exposed the detailes of the tagging system of
+This implementation exposed the details of the tagging system of
Guile. Use the new C API explained in the manual in node "Uniform
-Numeric Vectors" and "Bit Vector", respectively.
+Numeric Vectors" and "Bit Vectors", respectively.
The following macros are gone: SCM_UVECTOR_BASE, SCM_SET_UVECTOR_BASE,
SCM_UVECTOR_MAXLENGTH, SCM_UVECTOR_LENGTH, SCM_MAKE_UVECTOR_TAG,
SCM_SET_UVECTOR_LENGTH, SCM_BITVECTOR_P, SCM_BITVECTOR_BASE,
SCM_SET_BITVECTOR_BASE, SCM_BITVECTOR_MAX_LENGTH,
SCM_BITVECTOR_LENGTH, SCM_MAKE_BITVECTOR_TAG,
-SCM_SET_BITVECTOR_LENGTH.
+SCM_SET_BITVECTOR_LENGTH, SCM_BITVEC_REF, SCM_BITVEC_SET,
+SCM_BITVEC_CLR.
+
+** The macros dealing with vectors have been deprecated.
+
+Use the new functions scm_is_vector, scm_vector_elements,
+scm_vector_writable_elements, etc, or scm_is_simple_vector,
+SCM_SIMPLE_VECTOR_REF, SCM_SIMPLE_VECTOR_SET, etc instead. See the
+manual for more details.
+
+Deprecated are SCM_VECTORP, SCM_VELTS, SCM_VECTOR_MAX_LENGTH,
+SCM_VECTOR_LENGTH, SCM_VECTOR_REF, SCM_VECTOR_SET, SCM_WRITABLE_VELTS.
+
+The following macros have been removed: SCM_VECTOR_BASE,
+SCM_SET_VECTOR_BASE, SCM_MAKE_VECTOR_TAG, SCM_SET_VECTOR_LENGTH,
+SCM_VELTS_AS_STACKITEMS, SCM_SETVELTS, SCM_GC_WRITABLE_VELTS.
+
+** Some C functions and macros related to arrays have been deprecated.
+
+Migrate according to the following table:
+
+ scm_make_uve -> scm_make_typed_array, scm_make_u8vector etc.
+ scm_make_ra -> scm_make_array
+ scm_shap2ra -> scm_make_array
+ scm_cvref -> scm_c_generalized_vector_ref
+ scm_ra_set_contp -> do not use
+ scm_aind -> scm_array_handle_pos
+ scm_raprin1 -> scm_display or scm_write
+
+ SCM_ARRAYP -> scm_is_array
+ SCM_ARRAY_NDIM -> scm_c_array_rank
+ SCM_ARRAY_DIMS -> scm_array_handle_dims
+ SCM_ARRAY_CONTP -> do not use
+ SCM_ARRAY_MEM -> do not use
+ SCM_ARRAY_V -> scm_array_handle_elements or similar
+ SCM_ARRAY_BASE -> do not use
** SCM_CELL_WORD_LOC has been deprecated.
Thus the call to scm_frame_unwind_handler above could be replaced with
simply scm_frame_free (mem).
-** New way to block and unblock asyncs
+** New functions scm_c_call_with_blocked_asyncs and
+ scm_c_call_with_unblocked_asyncs
+
+Like scm_call_with_blocked_asyncs etc. but for C functions.
+
+** New functions scm_frame_block_asyncs and scm_frame_unblock_asyncs
In addition to scm_c_call_with_blocked_asyncs you can now also use
scm_frame_block_asyncs in a 'frame' (see above). Likewise for
scm_c_call_with_unblocked_asyncs and scm_frame_unblock_asyncs.
+** The macros SCM_DEFER_INTS, SCM_ALLOW_INTS, SCM_REDEFER_INTS,
+ SCM_REALLOW_INTS have been deprecated.
+
+They do no longer fulfill their original role of blocking signal
+delivery. Depending on what you want to achieve, replace a pair of
+SCM_DEFER_INTS and SCM_ALLOW_INTS with a frame that locks a mutex,
+blocks asyncs, or both. See node "Critical Sections" in the manual.
+
+** The value 'scm_mask_ints' is no longer writable.
+
+Previously, you could set scm_mask_ints directly. This is no longer
+possible. Use scm_c_call_with_blocked_asyncs and
+scm_c_call_with_unblocked_asyncs instead.
+
** New way to temporarily set the current input, output or error ports
C code can now use scm_frame_current_<foo>_port in a 'frame' (see
This is an incompatible change.
-** The value 'scm_mask_ints' is no longer writable.
-
-Previously, you could set scm_mask_ints directly. This is no longer
-possible. Use scm_c_call_with_blocked_asyncs and
-scm_c_call_with_unblocked_asyncs instead.
-
-** New functions scm_c_call_with_blocked_asyncs and
- scm_c_call_with_unblocked_asyncs
-
-Like scm_call_with_blocked_asyncs etc. but for C functions.
-
** New snarfer macro SCM_DEFINE_PUBLIC.
This is like SCM_DEFINE, but also calls scm_c_export for the defined
** The snarfer macro SCM_SNARF_INIT is now officially supported.
-** New macros SCM_VECTOR_REF and SCM_VECTOR_SET.
-
-Use these in preference to SCM_VELTS.
-
-** The SCM_VELTS macros now returns a read-only vector. For writing,
-use the new macros SCM_WRITABLE_VELTS or SCM_VECTOR_SET. The use of
-SCM_WRITABLE_VELTS is discouraged, though.
-
** Garbage collector rewrite.
The garbage collector is cleaned up a lot, and now uses lazy
variables GUILE_MAX_SEGMENT_SIZE, GUILE_INIT_SEGMENT_SIZE_2,
GUILE_INIT_SEGMENT_SIZE_1, and GUILE_MIN_YIELD_2 should be used.
+For understanding the memory usage of a GUILE program, the routine
+gc-live-object-stats returns an alist containing the number of live
+objects for every type.
+
+
** The function scm_definedp has been renamed to scm_defined_p
The name scm_definedp is deprecated.
This function is like scm_port_for_each but takes a pointer to a C
function as the callback instead of a SCM value.
+** The names scm_internal_select, scm_thread_sleep, and
+ scm_thread_usleep have been discouraged.
+
+Use scm_std_select, scm_std_sleep, scm_std_usleep instead.
+
+** The GC can no longer be blocked.
+
+The global flags scm_gc_heap_lock and scm_block_gc have been removed.
+The GC can now run (partially) concurrently with other code and thus
+blocking it is not well defined.
+
** Many definitions have been removed that were previously deprecated.
scm_lisp_nil, scm_lisp_t, s_nil_ify, scm_m_nil_ify, s_t_ify,