Node:GH deprecation, Next:gh preliminaries, Up:GH
Historically, the GH interface was the product of a practical problem
and a neat idea. The practical problem was that the interface of the
scm_ functions with which Guile itself was written (inherited
from Aubrey Jaffer's SCM) was so closely tied to the (rather arcane)
details of the internal data representation that it was extremely
difficult to write a Guile extension using these functions. The neat
idea was to define a high level language extension interface in such a
way that other extension language projects, not just Guile, would be
able to provide an implementation of that interface; then applications
using this interface could be compiled with whichever of the various
available implementations they chose. So the GH interface was created,
and advertised both as the recommended interface for application
developers wishing to use Guile, and as a portable high level interface
that could theoretically be implemented by other extension language
projects.
Time passed, and various things changed. Crucially, an enormous number
of improvements were made to the scm_ interface that Guile itself
uses in its implementation, with the result that it is now both easy and
comfortable to write a Guile extension with this interface. At the same
time, the contents of the GH interface were somewhat neglected by the
core Guile developers, such that some key operations -- such as smob
creation and management -- are simply not possible using GH alone.
Finally, the idea of multiple implementations of the GH interface did
not really crystallize (apart, I believe, from a short lived
implementation by the MzScheme project).
For all these reasons, the Guile developers have decided to deprecate
the GH interface -- which means that support for GH will be completely
removed after the next few releases -- and to focus only on the
scm_ interface, with additions to ensure that it is as easy to
use in all respects as GH was.
It remains an open question whether a deep kind of interface portability would be useful for extension language-based applications, and it may still be an interesting project to attempt to define a corresponding GH-like interface, but the Guile developers no longer plan to try to do this as part of the core Guile project.