14.5 Limitations and Future Plans
We hope you find dgawk useful and enjoyable to work with,
but as with any program, especially in its early releases, it still has
some limitations. A few which are worth being aware of are:
- At this point, dgawk does not give a detailed explanation of
what you did wrong when you type in something it doesn't like. Rather, it just
responds ‘syntax error’. When you do figure out what your mistake was,
though, you'll feel like a real guru.
- If you perused the dump of opcodes in Miscellaneous Dgawk Commands,
(or if you are already familiar with gawk internals),
you will realize that much of the internal manipulation of data
in gawk, as in many interpreters, is done on a stack.
Op_push
, Op_pop
, etc., are the “bread and butter” of
most gawk code. Unfortunately, as of now, dgawk
does not allow you to examine the stack's contents.
That is, the intermediate results of expression evaluation are on the
stack, but cannot be printed. Rather, only variables which are defined
in the program can be printed. Of course, a workaround for
this is to use more explicit variables at the debugging stage and then
change back to obscure, perhaps more optimal code later.
- There is no way to look “inside” the process of compiling
regular expressions to see if you got it right. As an awk
programmer, you are expected to know what
/[^[:alnum:][:blank:]]/
means.
- dgawk is designed to be used by running a program (with all its
parameters) on the command line, as described in dgawk invocation.
There is no way (as of now) to attach or “break in” to a running program.
This seems reasonable for a language which is used mainly for quickly
executing, short programs.
- dgawk only accepts source supplied with the -f option.
Look forward to a future release when these and other missing features may
be added, and of course feel free to try to add them yourself!