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:
gawkis a C program. As of this writing, this has not been tested.)
gawk’s symbols118 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.
gawk’s --version option 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 Extension Mechanism Outline, 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.