Better support for transition to guile-1.6

[Mikael Djurfeldt]

Hi,

The guile-1.6 release will be a real pain for many application
developers.

The transitions between versions up till now have been reasonably
smooth.  Between 1.4 and 1.6, large parts of the API has changed.
Even though many of these changes have been announced in the 1.4
release (deprecation), the 1.6 release will cause substantial work.

Here is a couple of proposals which might ease the transition:

1. Our policy requires the Guile developer to write an entry for every
   deprecated feature what the application programmer should use
   instead (HACKING/Coding standards/The normal way of removing a
   function, macro or variable/paragraph 4).  That way, as soon as
   something fails when compiling against a new Guile, the programmer
   can always look up the feature in NEWS and know what to do.

   Unfortunately, this has not been done for everything
   deprecated/removed.  I know from my own experience that this causes
   a lot of extra work, because one has to try to trace down the
   reason why the thing has been removed, possibly even checking out
   an older version to look at what has been changed in the Guile
   source.

*  I propose that we postpone the 1.6 release until *all* removed
   features have got an entry in NEWS.

2. Many application developers will want not just to upgrade to
   guile-1.6 but *maintain backward compatibility* with older Guile
   releases.  This will cause every application programmer to invent
   the wheel in parallel.

   I propose that we, in the guile 1.6 release, include a section of
   tests for configure.in + a backward compatibility header file
   "compat.h" with standard solutions for at least the most common
   cases.

   Example:

   For configure.in:

   ### BEGIN compatibility checks ###

   AC_CACHE_VAL(ac_cv_have_scm_t_bits,
   [AC_TRY_COMPILE([#include <libguile.h>],
   [scm_t_bits a;],
   ac_cv_have_scm_t_bits=yes, ac_cv_have_scm_t_bits=no)])
   AC_MSG_RESULT($ac_cv_have_scm_t_bits)
   if test $ac_cv_have_scm_t_bits = yes; then
     AC_DEFINE(HAVE_SCM_T_BITS)
   fi

   ...

   ### END compatibility checks ###

   In compat.h:

   #ifndef HAVE_SCM_T_BITS
   typedef scm_bits_t scm_t_bits;
   typedef scm_array scm_t_array;
   typedef scm_array_dim scm_t_array_dim;
   typedef scm_mutex_t scm_t_mutex;
   typedef scm_cond_t scm_t_cond;
   typedef scm_key_t scm_t_key;
   typedef scm_catch_body_t scm_t_catch_body
   #endif

   Application writers can then simply change instances of scm_bits_t
   to scm_t_bits while maintaining backward compatibility.

*  I propose that we postpone the 1.6 release until we have compiled
   configure tests and a backward compatibility header file for the
   API changes which most likely will influence applications using
   Guile.

Mikael