I wonder if you thought I meant "a bug in 20 lines" when I meant a "20 line program".
EDIT: e.g. 20 lines is enough for SQL http://web.archive.org/web/20060505221834/http://kx.com/q/e/...
What is this blasphemy?!
Here's an excellent introduction to K: http://archive.vector.org.uk/art10010830
Most kdb users use Q though, which is something else.
The typical '1000 line program' could be compacted like your program is and all fit onscreen at the same time, if you really wanted. It's not anywhere close to 50 times as much code.
Most of the functions are independent, with the exception of the parse utilities, so it's easier to list the exceptions: cre depends on col, w depends on w0 and w1; v and w are used in e (for tokenising); where (wh) is reused by select (sel) and update (upd). c and a are used for the pull parser.
On the other hand, i'm the kind of guy that has read 20 lines of code and missed possible null value bugs. Sucks when you have to tell customers to wait for the next point release before they can use this new feature.