Some goals for the new API were:
gawkinternals. Changes in
gawkinternals should not be visible to the writer of an extension function.
gawkreleases as long as the API itself does not change.
awk-level code as
awkfunctions do. This means that extensions should have:
gawk’s true arrays of arrays).
Some additional important goals were:
#ifdef __cplusplus’ and ‘
extern "C"’ magic so that a C++ compiler could be used. (If using C++, the runtime system has to be smart enough to call any constructors and destructors, as
gawkis a C program. As of this writing, this has not been tested.)
gawk’s symbols122 by the compile-time or dynamic linker, in order to enable creation of extensions that also work on MS-Windows.
During development, it became clear that there were other features that should be available to extensions, which were also subsequently provided:
gawk’s I/O redirection mechanism. In particular, the
xgawkdevelopers provided a so-called “open hook” to take over reading records. During development, this was generalized to allow extensions to hook into input processing, output processing, and two-way I/O.
--versionoption can provide information about extensions as well.
The requirement to avoid access to
gawk’s symbols is, at first
glance, a difficult one to meet.
One design, apparently used by Perl and Ruby and maybe others, would
be to make the mainline
gawk code into a library, with the
gawk utility a small C
main() function linked against
This seemed like the tail wagging the dog, complicating build and
installation and making a simple copy of the
from one system to another (or one place to another on the same
system!) into a chancy operation.
Pat Rankin suggested the solution that was adopted. See section How It Works at a High Level, for the details.
The symbols are the variables and functions
gawk. Access to these symbols by code
gawk loaded dynamically at runtime is
problematic on MS-Windows.