Probable Future Extensions
==========================
AWK is a language similar to PERL, only considerably more elegant.
Arnold Robbins
Hey!
Larry Wall
This minor node briefly lists extensions and possible improvements
that indicate the directions we are currently considering for `gawk'.
The file `FUTURES' in the `gawk' distribution lists these extensions as
well.
Following is a list of probable future changes visible at the `awk'
language level:
Loadable Module Interface
It is not clear that the `awk'-level interface to the modules
facility is as good as it should be. The interface needs to be
redesigned, particularly taking namespace issues into account, as
well as possibly including issues such as library search path order
and versioning.
`RECLEN' variable for fixed length records
Along with `FIELDWIDTHS', this would speed up the processing of
fixed-length records. `PROCINFO["RS"]' would be `"RS"' or
`"RECLEN"', depending upon which kind of record processing is in
effect.
Additional `printf' specifiers
The 1999 ISO C standard added a number of additional `printf'
format specifiers. These should be evaluated for possible
inclusion in `gawk'.
Databases
It may be possible to map a GDBM/NDBM/SDBM file into an `awk'
array.
Large Character Sets
It would be nice if `gawk' could handle UTF-8 and other character
sets that are larger than eight bits.
More `lint' warnings
There are more things that could be checked for portability.
Following is a list of probable improvements that will make `gawk''s
source code easier to work with:
Loadable Module Mechanics
The current extension mechanism works (Note:Adding New Built-in
Functions to `gawk'.), but is rather
primitive. It requires a fair amount of manual work to create and
integrate a loadable module. Nor is the current mechanism as
portable as might be desired. The GNU `libtool' package provides
a number of features that would make using loadable modules much
easier. `gawk' should be changed to use `libtool'.
Loadable Module Internals
The API to its internals that `gawk' "exports" should be revised.
Too many things are needlessly exposed. A new API should be
designed and implemented to make module writing easier.
Better Array Subscript Management
`gawk''s management of array subscript storage could use revamping,
so that using the same value to index multiple arrays only stores
one copy of the index value.
Integrating the DBUG Library
Integrating Fred Fish's DBUG library would be helpful during
development, but it's a lot of work to do.
Following is a list of probable improvements that will make `gawk'
perform better:
An Improved Version of `dfa'
The `dfa' pattern matcher from GNU `grep' has some problems.
Either a new version or a fixed one will deal with some important
regexp matching issues.
Compilation of `awk' programs
`gawk' uses a Bison (YACC-like) parser to convert the script given
it into a syntax tree; the syntax tree is then executed by a
simple recursive evaluator. This method incurs a lot of overhead,
since the recursive evaluator performs many procedure calls to do
even the simplest things.
It should be possible for `gawk' to convert the script's parse tree
into a C program which the user would then compile, using the
normal C compiler and a special `gawk' library to provide all the
needed functions (regexps, fields, associative arrays, type
coercion, and so on).
An easier possibility might be for an intermediate phase of `gawk'
to convert the parse tree into a linear byte code form like the
one used in GNU Emacs Lisp. The recursive evaluator would then be
replaced by a straight line byte code interpreter that would be
intermediate in speed between running a compiled program and doing
what `gawk' does now.
Finally, the programs in the test suite could use documenting in
this Info file.
Note:Making Additions to `gawk', if you are interested
in tackling any of these projects.