gawk: Extension Other Design Decisions

 
 C.5.3 Other Design Decisions
 ----------------------------
 
 As an arbitrary design decision, extensions can read the values of
 predefined variables and arrays (such as 'ARGV' and 'FS'), but cannot
 change them, with the exception of 'PROCINFO'.
 
    The reason for this is to prevent an extension function from
 affecting the flow of an 'awk' program outside its control.  While a
 real 'awk' function can do what it likes, that is at the discretion of
 the programmer.  An extension function should provide a service or make
 a C API available for use within 'awk', and not mess with 'FS' or 'ARGC'
 and 'ARGV'.
 
    In addition, it becomes easy to start down a slippery slope.  How
 much access to 'gawk' facilities do extensions need?  Do they need
 'getline'?  What about calling 'gsub()' or compiling regular
 expressions?  What about calling into 'awk' functions?  (_That_ would be
 messy.)
 
    In order to avoid these issues, the 'gawk' developers chose to start
 with the simplest, most basic features that are still truly useful.
 
    Another decision is that although 'gawk' provides nice things like
 MPFR, and arrays indexed internally by integers, these features are not
 being brought out to the API in order to keep things simple and close to
 traditional 'awk' semantics.  (In fact, arrays indexed internally by
 integers are so transparent that they aren't even documented!)
 
    Additionally, all functions in the API check that their pointer input
 parameters are not 'NULL'.  If they are, they return an error.  (It is a
 good idea for extension code to verify that pointers received from
 'gawk' are not 'NULL'.  Such a thing should not happen, but the 'gawk'
 developers are only human, and they have been known to occasionally make
 mistakes.)
 
    With time, the API will undoubtedly evolve; the 'gawk' developers
 expect this to be driven by user needs.  For now, the current API seems
 to provide a minimal yet powerful set of features for creating
 extensions.