Node:GH deprecation, Next:, Up:GH



19.1 Why the GH Interface is Now Deprecated

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.