[Guile-commits] GNU Guile branch, master, updated. release_1-9-5-214-g61521ea

[Andy Wingo]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Guile".

http://git.savannah.gnu.org/cgit/guile.git/commit/?id=61521ea0341286251d615b89e7ee9cd73a42201c

The branch, master has been updated
       via  61521ea0341286251d615b89e7ee9cd73a42201c (commit)
      from  9331f91cc411fc2a09a59308bb889f3f5f735e49 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 61521ea0341286251d615b89e7ee9cd73a42201c
Author: Andy Wingo <address@hidden>
Date:   Sun Dec 13 20:18:50 2009 +0100

    more NEWS updates
    
    * NEWS: Update some more.

-----------------------------------------------------------------------

Summary of changes:
 NEWS |  157 +++++++++++++++++++++++++++++++++++-------------------------------
 1 files changed, 83 insertions(+), 74 deletions(-)

diff --git a/NEWS b/NEWS
index 96f044b..662b3a9 100644
--- a/NEWS
+++ b/NEWS
@@ -22,17 +22,18 @@ to execute on the same stack, unifying multiple-value 
return semantics,
 providing for proper tail recursion between interpreted and compiled
 code, and simplifying debugging.
 
-goes along with a new c evaluator -- memoization completely before
-evaluation -- threadsafe, not debug-happy
+As part of this change, the evaluator no longer mutates the internal
+representation of the code being evaluated in a thread-unsafe manner.
 
-loadsa c interface changes, see changelog
+There are two negative aspects of this change, however. First, Guile
+takes a lot longer to compile now. Also, there is less debugging
+information available for debugging interpreted code. We hope to improve
+both of these situations.
 
-remove local-eval
-
-** GOOPS dispatch in scheme
-
-not much user-level change, but neat to note; possibility for method
-combinations &c
+There are many changes to the internal C evalator interface, but all
+public interfaces should be the same. See the ChangeLog for details. If
+we have inadvertantly changed an interface that you were using, please
+contact address@hidden
 
 ** Elisp compiler
 
@@ -44,7 +45,7 @@ address@hidden
 ** Faster SRFI-9 record access
 
 SRFI-9 records are now implemented directly on top of Guile's structs,
-and their accessors are defined in such a way that normal callsites
+and their accessors are defined in such a way that normal call-sites
 inline to special VM opcodes, while still allowing for the general case
 (e.g. passing a record accessor to `apply').
 
@@ -94,6 +95,28 @@ patch, and Kent Dybvig for the code.
 `scm_c_make_struct' and `scm_c_make_structv' are new varargs and array
 constructors, respectively, for structs. You might find them useful.
 
+** Applicable struct support
+
+One may now make structs from Scheme that may be applied as procedures.
+To do so, make a struct whose vtable is `<applicable-struct-vtable>'.
+That struct will be the vtable of your applicable structs; instances of
+that new struct are assumed to have the procedure in their first slot.
+`<applicable-struct-vtable>' is like Common Lisp's
+`funcallable-standard-class'. Likewise there is
+`<applicable-struct-with-setter-vtable>', which looks for the setter in
+the second slot. This needs to be better documented.
+
+** GOOPS dispatch in scheme
+
+As an implementation detail, GOOPS dispatch is no longer implemented by
+special evaluator bytecodes, but rather directly via a Scheme function
+associated with an applicable struct. There is some VM support for the
+underlying primitives, like `class-of'.
+
+This change will in the future allow users to customize generic function
+dispatch without incurring a performance penalty, and allow us to
+implement method combinations.
+
 ** Procedures-with-setters are now implemented using applicable structs
 
 From a user's perspective this doesn't mean very much. But if, for some
@@ -101,12 +124,19 @@ odd reason, you used the SCM_PROCEDURE_WITH_SETTER_P, 
SCM_PROCEDURE, or
 SCM_SETTER macros, know that they're deprecated now. Also, scm_tc7_pws
 is gone.
 
-** Bit twiddlings
+** No more `local-eval'
 
-*** smob to tc7
+`local-eval' used to exist so that one could evaluate code in the
+lexical context of a function. Since there is no way to get the lexical
+environment any more, as that concept has no meaning for the compiler,
+and a different meaning for the interpreter, we have removed the
+function.
 
-Fluids, dynamic states, and hash tables used to be SMOB objects, but now
-they have statically allocated typecodes.
+If you think you need `local-eval', you should probably implement your
+own metacircular evaluator. It will probably be as fast as Guile's
+anyway.
+
+** Bit twiddlings
 
 *** Remove old evaluator closures
 
@@ -118,40 +148,17 @@ details.
 
 *** Simplify representation of primitive procedures
 
-Remove scm_tc7_cxr, scm_tc7_rpsubr, scm_tc7_asubr, scm_tc7_dsubr.
-Remove scm_tc7_subr_* and scm_tc7_lsubr_*
-
-| |     implement transcendental sin, cos etc in c; deprecate $sin, $cos, etc
-| |     
-| |     * libguile/deprecated.h:
-| |     * libguile/deprecated.c (scm_asinh, scm_acosh, scm_atanh): Deprecate
-| |       these stand-ins for the C99 asinh, acosh, and atanh functions. Guile
-| |       is not gnulib.
-| |       (scm_sys_atan2): Deprecate as well, in favor of scm_atan.
-| |     
-| |     * libguile/numbers.h:
-| |     * libguile/numbers.c (scm_sin, scm_cos, scm_tan)
-| |       (scm_sinh, scm_cosh, scm_tanh)
-| |       (scm_asin, scm_acos, scm_atan)
-| |       (scm_sys_asinh, scm_sys_acosh, scm_sys_atanh): New functions,
-| |       replacing the combination of dsubrs and boot-9 wrappers with C subrs
-| |       that handle complex values. The latter three have _sys_ in their 
names
-| |       due to the name conflict with the deprecated scm_asinh et al.
-...
-| |       Remove the $abs, $sin etc "dsubrs".
-| | 
-| |     expt implemented in C, handles complex numbers
-| |     
-| |     * libguile/numbers.h:
-| |     * libguile/numbers.c (scm_expt): Rename from scm_sys_expt, and handle
-| |       the complex cases as well.
-| |     
-| |     * libguile/deprecated.h:
-| |     * libguile/deprecated.c (scm_sys_expt): Add a deprecated shim.
-| |     
-| |     * module/ice-9/boot-9.scm (expt): Remove definition, scm_expt does all
-| |       we need.
-| | 
+It used to be that there were something like 12 different typecodes
+allocated to primitive procedures, each with its own calling convention.
+Now there is only one, the gsubr. This may affect user code if you were
+defining a procedure using scm_c_make_subr rather scm_c_make_gsubr. The
+solution is to switch to use scm_c_make_gsubr. This solution works well
+both with the old 1.8 and and with the current 1.9 branch.
+
+*** Some SMOB types changed to have static typecodes
+
+Fluids, dynamic states, and hash tables used to be SMOB objects, but now
+they have statically allocated tc7 typecodes.
 
 *** Preparations for changing SMOB representation
 
@@ -169,43 +176,45 @@ VM stack. Now Guile's procedures only run on the VM 
stack, simplifying
 much of the C API. See the ChangeLog for details. The Scheme API has not
 been changed significantly.
 
-** define!
-
-a procedure to do a toplevel define
-
-** applicable struct support
-
-** eqv not a generic
+** New procedure, `define!'
 
-** deprecate trampolines
+`define!' is a procedure that takes two arguments, a symbol and a value,
+and binds the value to the symbol in the current module. It's useful to
+programmatically make definitions in the current module, and is slightly
+less verbose than `module-define!'.
 
-| |       (scm_the_root_module): Undeprecate, it's actually a useful function,
-| |       that other parts of the code use.
+** eqv? not a generic
 
-** deval/ceval distinction removed
+One used to be able to extend `eqv?' as a primitive-generic, but no
+more. Because `eqv?' is in the expansion of `case' (via `memv'), which
+should be able to compile to static dispatch tables, it doesn't make
+sense to allow extensions that would subvert this optimization.
 
-** --disable-discouraged builds cleanly.
+** Deprecate trampolines
 
-** new metatables: scm_standard_vtable_vtable,
-scm_applicable_struct_vtable_vtable, 
scm_applicable_struct_with_setter_vtable_vtable
+There used to be C functions `scm_trampoline_0', `scm_trampoline_1', and
+so on. The point was to do some precomputation on the type of the
+procedure, then return a specialized "call" procedure. However this
+optimization wasn't actually an optimization, so it is now deprecated.
+Just use `scm_call_0', etc instead.
 
-| |       (scm_init_struct): Define <applicable-struct-vtable>, a magical 
vtable
-| |       like CL's funcallable-standard-class. Also define
-| |       <applicable-struct-with-setter-vtable>.
+** Undeprecate `scm_the_root_module ()'
 
-** hidden slots
+It's useful to be able to get the root module from C without doing a
+full module lookup.
 
-** better (?) intptr support
+** New struct slot allocation: "hidden"
 
-| |     * libguile/__scm.h (SCM_T_UINTPTR_MAX, SCM_T_INTPTR_MIN,
-| |       SCM_T_INTPTR_MAX): New macros.
-| |     * libguile/_scm.h (SIZEOF_SCM_T_BITS): New macro.
-| |     * libguile/gen-scmconfig.c (main): Produce typedefs for `scm_t_intptr'
-| |       and `scm_t_uintptr'.
-| |     * libguile/gen-scmconfig.h.in (SCM_I_GSC_T_INTPTR, SCM_I_GSC_T_UINPTR):
-| |       New macros.
+A hidden slot is readable and writable, but will not be initialized by a
+call to make-struct. For example in your layout you would say "ph"
+instead of "pw". Hidden slots are useful for adding new slots to a
+vtable without breaking existing invocations to make-struct.
 
+** New type definitions for `scm_t_intptr' and friends.
 
+`SCM_T_UINTPTR_MAX', `SCM_T_INTPTR_MIN', `SCM_T_INTPTR_MAX',
+`SIZEOF_SCM_T_BITS', `scm_t_intptr' and `scm_t_uintptr' are now
+available to C. Have fun!
 
 ** And of course, the usual collection of bugfixes
  


hooks/post-receive
-- 
GNU Guile