Guile NEWS --- history of user-visible changes.
-Copyright (C) 1996-2014 Free Software Foundation, Inc.
+Copyright (C) 1996-2015 Free Software Foundation, Inc.
See the end for copying conditions.
Please send Guile bug reports to bug-guile@gnu.org.
+\f
+Changes in 2.1.1 (changes since the 2.0.x series):
+
+* Notable changes
+
+** Speed
+
+The biggest change in Guile 2.2 is a complete rewrite of its virtual
+machine and compiler internals. The result is faster startup time,
+better memory usage, and faster execution of user code. See the
+"Performance improvements" section below for more details.
+
+** Better thread-safety
+
+This new release series takes the ABI-break opportunity to fix some
+interfaces that were difficult to use correctly from multiple threads.
+Notably, weak hash tables are now transparently thread-safe. Ports are
+also thread-safe; see "New interfaces" below for details on the changes
+to the C interface.
+
+** Better space-safety
+
+It used to be the case that, when calling a Scheme procedure, the
+procedure and arguments were always preserved against garbage
+collection. This is no longer the case; Guile is free to collect the
+procedure and arguments if they become unreachable, or to re-use their
+slots for other local variables. Guile still offers good-quality
+backtraces by determining the procedure being called from the
+instruction pointer instead of from the value in slot 0 of an
+application frame, and by using a live variable map that allows the
+debugger to know which locals are live at all points in a frame.
+
+** Off-main-thread finalization
+
+Following Guile 2.0.6's change to invoke finalizers via asyncs, Guile
+2.2 takes the additional step of invoking finalizers from a dedicated
+finalizer thread, if threads are enabled. This avoids concurrency
+issues between finalizers and application code, and also speeds up
+finalization. If your application's finalizers are not robust to the
+presence of threads, see "Foreign Objects" in the manual for information
+on how to disable automatic finalization and instead run finalizers
+manually.
+
+** Better locale support in Guile scripts
+
+When Guile is invoked directly, either from the command line or via a
+hash-bang line (e.g. "#!/usr/bin/guile"), it now installs the current
+locale via a call to `(setlocale LC_ALL "")'. For users with a unicode
+locale, this makes all ports unicode-capable by default, without the
+need to call `setlocale' in your program. This behavior may be
+controlled via the GUILE_INSTALL_LOCALE environment variable; see the
+manual for more.
+
+** Complete Emacs-compatible Elisp implementation
+
+Thanks to the work of BT Templeton, Guile's Elisp implementation is now
+fully Emacs-compatible, implementing all of Elisp's features and quirks
+in the same way as the editor we know and love.
+
+** Dynamically expandable stacks
+
+Instead of allocating fixed stack sizes for running Scheme code, Guile
+now starts off each thread with only one page of stack, and expands and
+shrinks it dynamically as needed. Guile will throw an exception for
+stack overflows if growing the stack fails. It is also possible to
+impose a stack limit during the extent of a function call. See "Stack
+Overflow" in the manual, for more.
+
+This change allows users to write programs that use the stack as a data
+structure for pending computations, as it was meant to be, without
+reifying that data out to the heap. Where you would previously make a
+loop that collect its results in reverse order only to re-reverse them
+at the end, now you can just recurse without worrying about stack
+overflows.
+
+Using the stack also allows more code to be continuation-safe. For
+example, returning multiple times from a `map' procedure in Guile 2.0
+would change the value of previously returned result lists, because
+`map' built its result list in reverse order then used `reverse!' to
+return the proper result. Now in Guile 2.2, `map' is implemented using
+straightforward recursion, which eliminates this bug while maintaining
+good performance as well as good space complexity.
+
+** Out-of-memory improvements
+
+Instead of aborting, failures to allocate memory will now raise an
+unwind-only `out-of-memory' exception, and cause the corresponding
+`catch' expression to run garbage collection in order to free up memory.
+
+** GOOPS core reimplemented in Scheme
+
+Guile's object orientation system, GOOPS, has been mostly reimplemented
+in Scheme. This decreases its maintenance burden on the rest of Guile,
+while also makes it possible to implement new features in the future,
+such as method combinations or `eqv?' specializers.
+
+* Performance improvements
+
+** Faster programs via new virtual machine
+
+Guile now compiles programs to instructions for a new virtual machine.
+The new virtual machine's instructions can address their source and
+destination operands by "name" (slot). This makes access to named
+temporary values much faster than in Guile 2.0, and removes a lot of
+value-shuffling that the old virtual machine had to do. The end result
+is that loop-heavy code can be two or three times as fast with Guile 2.2
+as in 2.0. Your mileage may vary, of course; see "A Virtual Machine for
+Guile" in the manual for the nitties and the gritties.
+
+** Better startup time, memory usage with ELF object file format
+
+Guile now uses the standard ELF format for its compiled code. (Guile
+has its own loader and linker, so this does not imply a dependency on
+any particular platform's ELF toolchain.) The benefit is that Guile is
+now able to statically allocate more data in the object files. ELF also
+enables more sharing of data between processes, and decreases startup
+time (about 40% faster than the already fast startup of the Guile 2.0
+series). Guile also uses DWARF for some of its debugging information.
+Much of the debugging information can be stripped from the object files
+as well. See "Object File Format" in the manual, for full details.
+
+** Better optimizations via compiler rewrite
+
+Guile's compiler now uses a Continuation-Passing Style (CPS)
+intermediate language, allowing it to reason easily about temporary
+values and control flow. Examples of optimizations that this permits
+are optimal contification, optimal common subexpression elimination,
+dead code elimination, parallel moves with at most one temporary,
+allocation of stack slots using precise liveness information, and
+closure optimization. For more, see "Continuation-Passing Style" in the
+manual.
+
+** Faster interpreter
+
+Combined with a number of optimizations to the interpreter itself,
+simply compiling `eval.scm' with the new compiler yields an interpreter
+that is consistently two or three times faster than the one in Guile
+2.0.
+
+** Allocation-free dynamic stack
+
+Guile now implements the dynamic stack with an actual stack instead of a
+list of heap objects, avoiding most allocation. This speeds up prompts,
+the `scm_dynwind_*' family of functions, fluids, and `dynamic-wind'.
+
+** Optimized UTF-8 and Latin-1 ports, symbols, and strings
+
+Guile 2.2 is faster at reading and writing UTF-8 and Latin-1 strings
+from ports, and at converting symbols and strings to and from these
+encodings.
+
+** Optimized hash functions
+
+Guile 2.2 now uses Bob Jenkins' `hashword2' (from his `lookup3.c') for
+its string hash, and Thomas Wang's integer hash function for `hashq' and
+`hashv'. These functions produce much better hash values across all
+available fixnum bits.
+
+** Optimized generic array facility
+
+Thanks to work by Daniel Llorens, the generic array facility is much
+faster now, as it is internally better able to dispatch on the type of
+the underlying backing store.
+
+* New interfaces
+
+** New `cond-expand' feature: `guile-2.2'
+
+Use this feature if you need to check for Guile 2.2 from Scheme code.
+
+** New predicate: `nil?'
+
+See "Nil" in the manual.
+
+** New compiler modules
+
+Since the compiler was rewritten, there are new modules for the back-end
+of the compiler and the low-level loader and introspection interfaces.
+See the "Guile Implementation" chapter in the manual for all details.
+
+** New functions: `scm_to_intptr_t', `scm_from_intptr_t'
+** New functions: `scm_to_uintptr_t', `scm_from_uintptr_t'
+
+See "Integers" in the manual, for more.
+
+** New thread-safe port API
+
+For details on `scm_c_make_port', `scm_c_make_port_with_encoding',
+`scm_c_lock_port', `scm_c_try_lock_port', `scm_c_unlock_port',
+`scm_c_port_type_ref', `scm_c_port_type_add_x', `SCM_PORT_DESCRIPTOR',
+and `scm_dynwind_lock_port', see XXX.
+
+There is now a routine to atomically adjust port "revealed counts". See
+XXX for more on `scm_adjust_port_revealed_x' and
+`adjust-port-revealed!',
+
+All other port API now takes the lock on the port if needed. There are
+some C interfaces if you know that you don't need to take a lock; see
+XXX for details on `scm_get_byte_or_eof_unlocked',
+`scm_peek_byte_or_eof_unlocked' `scm_c_read_unlocked',
+`scm_getc_unlocked' `scm_unget_byte_unlocked', `scm_ungetc_unlocked',
+`scm_ungets_unlocked', `scm_fill_input_unlocked' `scm_putc_unlocked',
+`scm_puts_unlocked', and `scm_lfwrite_unlocked'.
+
+** New inline functions: `scm_new_smob', `scm_new_double_smob'
+
+These can replace many uses of SCM_NEWSMOB, SCM_RETURN_NEWSMOB2, and the
+like. See XXX in the manual, for more.
+
+** New low-level type accessors
+
+For more on `SCM_HAS_TYP7', `SCM_HAS_TYP7S', `SCM_HAS_TYP16', see XXX.
+
+`SCM_HEAP_OBJECT_P' is now an alias for the inscrutable `SCM_NIMP'.
+
+`SCM_UNPACK_POINTER' and `SCM_PACK_POINTER' are better-named versions of
+the old `SCM2PTR' and `PTR2SCM'. Also, `SCM_UNPACK_POINTER' yields a
+void*.
+
+** <standard-vtable>, standard-vtable-fields
+
+See "Structures" in the manual for more on these
+
+** Convenience utilities for ports and strings.
+
+See XXX for more on `scm_from_port_string', `scm_from_port_stringn',
+`scm_to_port_string', and `scm_to_port_stringn'.
+
+** New expressive PEG parser
+
+See "PEG Parsing" in the manual for more. Thanks to Michael Lucy for
+originally writing these, and to Noah Lavine for integration work.
+
+** `make-stack' now also works on delimited continuations
+
+** Better URI-reference support
+
+The `(web uri)' module now has interfaces for handling URI references,
+which might not have a scheme. The Location header of a web request or
+response is now a URI reference instead of a URI. Also,
+`request-absolute-uri' now has an optional default scheme argument. See
+"Web" in the manual for full details.
+
+** formal-name->char, char->formal-name
+
+See "Characters", in the manual.
+
+* Incompatible changes
+
+** ASCII is not ISO-8859-1
+
+In Guile 2.0, if a user set "ASCII" or "ANSI_X3.4-1968" as the encoding
+of a port, Guile would treat it as ISO-8859-1. While these encodings
+are the same for codepoints 0 to 127, ASCII does not extend past that
+range, whereas ISO-8859-1 goes up to 255. Guile 2.2 no longer treats
+ASCII as ISO-8859-1. This is likely to be a problem only if the user's
+locale is set to ASCII, and the user or a program writes non-ASCII
+codepoints to a port.
+
+** String ports default to UTF-8
+
+Guile 2.0 would use the `%default-port-encoding' when creating string
+ports. This resulted in ports that could only accept a subset of valid
+characters, which was surprising to users. Now string ports default to
+the UTF-8 encoding. Sneaky users can still play encoding conversion
+games with string ports by explicitly setting the encoding of a port
+after it is open. See "Ports" in the manual for more.
+
+** `scm_from_stringn' and `scm_to_stringn' encoding arguments are never NULL
+
+These functions now require a valid `encoding' argument, and will abort
+if given `NULL'.
+
+** All r6rs ports are both textual and binary
+
+Because R6RS ports are a thin layer on top of Guile's ports, and Guile's
+ports are both textual and binary, Guile's R6RS ports are also both
+textual and binary, and thus both kinds have port transcoders. This is
+an incompatibility with respect to R6RS.
+
+** Vtable hierarchy changes
+
+In an attempt to make Guile's structure and record types integrate
+better with GOOPS by unifying the vtable hierarchy, `make-vtable-vtable'
+is now deprecated. Instead, users should just use `make-vtable' with
+appropriate arguments. See "Structures" in the manual for all of the
+details. As such, `record-type-vtable' and `%condition-type-vtable' now
+have a parent vtable and are no longer roots of the vtable hierarchy.
+
+** Syntax parameters are a distinct type
+
+Guile 2.0's transitional implementation of `syntax-parameterize' was
+based on the `fluid-let-syntax' interface inherited from the psyntax
+expander. This interface allowed any binding to be dynamically rebound
+-- even bindings like `lambda'. This is no longer the case in Guile
+2.2. Syntax parameters must be defined via `define-syntax-parameter',
+and only such bindings may be parameterized. See "Syntax Parameters" in
+the manual for more.
+
+** Defined identifiers scoped in the current module
+
+Sometimes Guile's expander would attach incorrect module scoping
+information for top-level bindings made by an expansion. For example,
+given the following R6RS library:
+
+ (library (defconst)
+ (export defconst)
+ (import (guile))
+ (define-syntax-rule (defconst name val)
+ (begin
+ (define t val)
+ (define-syntax-rule (name) t))))
+
+Attempting to use it would produce an error:
+
+ (import (defconst))
+ (defconst foo 42)
+ (foo)
+ =| Unbound variable: t
+
+It wasn't clear that we could fix this in Guile 2.0 without breaking
+someone's delicate macros, so the fix is only coming out now.
+
+** Pseudo-hygienically rename macro-introduced bindings
+
+Bindings introduced by macros, like `t' in the `defconst' example above,
+are now given pseudo-fresh names. This allows
+
+ (defconst foo 42)
+ (defconst bar 37)
+
+to introduce different bindings for `t'. These pseudo-fresh names are
+made in such a way that if the macro is expanded again, for example as
+part of a simple recompilation, the introduced identifiers get the same
+pseudo-fresh names. See "Hygiene and the Top-Level" in the manual, for
+details.
+
+** Fix literal matching for module-bound literals
+
+`syntax-rules' and `syntax-case' macros can take a set of "literals":
+bound or unbound keywords that the syntax matcher treats specially.
+Before, literals were always matched symbolically (by name). Now they
+are matched by binding. This allows literals to be reliably bound to
+values, renamed by imports or exports, et cetera. See "Syntax-rules
+Macros" in the manual for more on literals.
+
+** `dynamic-wind' doesn't check that guards are thunks
+
+Checking that the dynamic-wind out-guard procedure was actually a thunk
+before doing the wind was slow, unreliable, and not strictly needed.
+
+** All deprecated code removed
+
+All code deprecated in Guile 2.0 has been removed. See older NEWS, and
+check that your programs can compile without linker warnings and run
+without runtime warnings. See "Deprecation" in the manual.
+
+** Remove miscellaneous unused interfaces
+
+We have removed accidentally public, undocumented interfaces that we
+think are not used, and not useful. This includes `scm_markstream',
+`SCM_FLUSH_REGISTER_WINDOWS', `SCM_THREAD_SWITCHING_CODE', `SCM_FENCE',
+`scm_call_generic_0', `scm_call_generic_1', `scm_call_generic_2'
+`scm_call_generic_3', `scm_apply_generic', and `scm_program_source'.
+`scm_async_click' was renamed to `scm_async_tick', and `SCM_ASYNC_TICK'
+was made private (use `SCM_TICK' instead).
+
+** Many internal compiler / VM changes
+
+As the compiler and virtual machine were re-written, there are many
+changes in the back-end of Guile to interfaces that were introduced in
+Guile 2.0. These changes are only only of interest if you wrote a
+language on Guile 2.0 or a tool using Guile 2.0 internals. If this is
+the case, drop by the IRC channel to discuss the changes.
+
+** Defining a SMOB or port type no longer mucks exports of `(oop goops)'
+
+It used to be that defining a SMOB or port type added an export to
+GOOPS, for the wrapper class of the smob type. This violated
+modularity, though, so we have removed this behavior.
+
+** Bytecode replaces objcode as a target language
+
+One way in which people may have used details of Guile's runtime in
+Guile 2.0 is in compiling code to thunks for later invocation. Instead
+of compiling to objcode and then calling `make-program', now the way to
+do it is to compile to `bytecode' and then call `load-thunk-from-memory'
+from `(system vm loader)'.
+
+** Weak pairs removed
+
+Weak pairs were not safe to access with `car' and `cdr', and so were
+removed.
+
+** Weak alist vectors removed
+
+Use weak hash tables instead.
+
+** Weak vectors may no longer be accessed via `vector-ref' et al
+
+Weak vectors may no longer be accessed with the vector interface. This
+was a source of bugs in the 2.0 Guile implementation, and a limitation
+on using vectors as building blocks for other abstractions. Vectors in
+Guile are now a concrete type; for an abstract interface, use the
+generic array facility (`array-ref' et al).
+
+** scm_t_array_implementation removed
+
+This interface was introduced in 2.0 but never documented. It was a
+failed attempt to layer the array implementation that actually
+introduced too many layers, as it prevented the "vref" and "vset"
+members of scm_t_array_handle (called "ref" and "set" in 1.8, not
+present in 2.0) from specializing on array backing stores.
+
+Notably, the definition of scm_t_array_handle has now changed, to not
+include the (undocumented) "impl" member. We are sorry for any
+inconvenience this may cause.
+
+** `scm_make' is now equivalent to Scheme `make'
+
+It used to be that `scm_make' only implemented a hard-wired object
+allocation and initialization protocol. This was because `scm_make' was
+used while GOOPS booted its own, more complete `make' implementation in
+Scheme. Now that we've re-implemented everything in Scheme, the C
+`scm_make' now dispatches directly to Scheme `make', which implements
+the full protocol. This change is incompatible in some ways, but on the
+whole is good news for GOOPS users.
+
+** GOOPS slot definitions are now objects
+
+Slot definitions are now instances of a <slot> class, instead of being
+specially formatted lists. To most user code, this is transparent, as
+the slot definition accessors like `slot-definition-name' continue to
+work. However, code that for example uses `car' to get the name of a
+slot definition will need to be updated to use the accessors.
+
+** Class slot changes
+
+Class objects no longer have a `default-slot-definition-class' slot,
+which was never used. They also no longer have slots for hashsets
+(`h0', `h1', and so on up to `h7'), which have been unused since Guile
+2.0 and were not a great idea.
+
+There is a new class option, `#:static-slot-allocation?'. See the
+manual for details.
+
+** Removal of internal, unintentionally exposed GOOPS C interfaces
+
+These include: `scm_sys_fast_slot_ref', `scm_sys_fast_slot_set_x'
+`scm_basic_basic_make_class', `scm_sys_compute_slots',
+`scm_sys_prep_layout_x' `scm_t_method', `SCM_METHOD',
+`scm_s_slot_set_x', `SCM_CLASS_CLASS_LAYOUT', `scm_si_slotdef_class',
+`scm_si_generic_function', `scm_si_specializers', `scm_si_procedure',
+`scm_si_formals', `scm_si_body', `scm_si_make_procedure',
+`SCM_CLASS_CLASS_LAYOUT', `SCM_INSTANCE_HASH', `SCM_SET_HASHSET', `union
+scm_t_debug_info', `scm_pure_generic_p', `SCM_PUREGENERICP',
+`SCM_VALIDATE_PUREGENERIC', `SCM_VTABLE_FLAG_GOOPS_PURE_GENERIC',
+`SCM_CLASSF_PURE_GENERIC', `scm_c_extend_primitive_generic',
+`scm_sys_initialize_object', `SCM_CLASS_CLASS_LAYOUT',
+`scm_si_redefined', `scm_si_direct_supers', `scm_si_direct_slots',
+`scm_si_direct_subclasses', `scm_si_direct_methods', `scm_si_cpl'
+`scm_si_slots', `scm_si_getters_n_setters', `SCM_N_CLASS_SLOTS',
+`SCM_OBJ_CLASS_REDEF', `SCM_INST', `SCM_ACCESSORS_OF',
+`scm_sys_allocate_instance', and `scm_sys_invalidate_class_x'.
+
+* New deprecations
+
+** SCM_WTA_DISPATCH_0, SCM_WTA_DISPATCH_1, SCM_WTA_DISPATCH_2, SCM_WTA_DISPATCH_N
+** SCM_GASSERT0, SCM_GASSERT1, SCM_GASSERT2, SCM_GASSERTn
+** SCM_WTA_DISPATCH_1_SUBR
+
+These macros were used in dispatching primitive generics. They can be
+replaced by using C functions (the same name but in lower case), if
+needed, but this is a hairy part of Guile that perhaps you shouldn't be
+using.
+
+** scm_compute_applicable_methods and scm_find_method
+
+Use `compute-applicable-methods' from Scheme instead.
+
+** scm_no_applicable_method
+
+Fetch no-applicable-method from the GOOPS exports if you need it.
+
+** scm_class_boolean, scm_class_char, scm_class_pair
+** scm_class_procedure, scm_class_string, scm_class_symbol
+** scm_class_primitive_generic, scm_class_vector, scm_class_null
+** scm_class_real, scm_class_complex, scm_class_integer
+** scm_class_fraction, scm_class_unknown, scm_class_top
+** scm_class_object, scm_class_class, scm_class_applicable
+** scm_class_applicable_struct, scm_class_applicable_struct_with_setter
+** scm_class_generic, scm_class_generic_with_setter, scm_class_accessor
+** scm_class_extended_generic, scm_class_extended_generic_with_setter
+** scm_class_extended_accessor, scm_class_method
+** scm_class_accessor_method, scm_class_procedure_class
+** scm_class_applicable_struct_class, scm_class_number, scm_class_list
+** scm_class_keyword, scm_class_port, scm_class_input_output_port
+** scm_class_input_port, scm_class_output_port, scm_class_foreign_slot
+** scm_class_self, scm_class_protected, scm_class_hidden
+** scm_class_opaque, scm_class_read_only, scm_class_protected_hidden
+** scm_class_protected_opaque, scm_class_protected_read_only
+** scm_class_scm, scm_class_int, scm_class_float, scm_class_double
+** scm_port_class, scm_smob_class
+
+These class exports are now deprecated. Instead, look up the ones you
+need from the GOOPS module, or use `scm_class_of' on particular values.
+
+** scm_get_keyword
+
+Instead from Scheme use kw-arg-ref or real keyword arguments, and from C
+use `scm_c_bind_keyword_arguments'.
+
+** scm_slot_ref_using_class, scm_slot_set_using_class_x
+** scm_slot_bound_using_class_p, scm_slot_exists_using_class_p
+
+Instead use the normal `scm_slot_ref' and similar procedures.
+
+* Changes to the distribution
+
+** New minor version
+
+The "effective version" of Guile is now 2.2, which allows parallel
+installation with other effective versions (for example, the older Guile
+2.0). See "Parallel Installations" in the manual for full details.
+Notably, the `pkg-config' file is now `guile-2.2'.
+
+** Bump required libgc version to 7.2, released March 2012.
+
+** The readline extension is now installed in the extensionsdir
+
+The shared library that implements Guile's readline extension is no
+longer installed to the libdir. This change should be transparent to
+users, but packagers may be interested.
+
+
+\f
Changes in 2.0.11 (since 2.0.10):
This release fixes an embarrassing regression introduced in the C
HCoop / bpt / guile.git / blobdiff