...parser generator. :)

Yesterday, I started to write a recursive-descent parser for my language, on the grounds that this appears to be the only way to be able to generate useful error messages on syntax errors. Recursive descent is a fairly limited technique, which makes this an inherently annoying process. So I wrote a small program that calculates the LL(1) parse tables for a given grammar and prints them out in HTML, so that I could consult it while hand-rolling the parser. It struck me that this was a tool of a class that I've rarely seen before in development: something whose purpose is not to completely automate a task, but to semi-automate it. In this case, I eliminate the manual scutwork of checking for ambiguities in my grammar, but I am still the one writing the parser.

Can anyone come up with more examples? I'll bet the sysadmins here will be able to come up with a lot, since the job involves taking essentially random human requests and convincing a machine to do them. But I could be wrong....

I'm not sure what I'm talking about, either. :) I have a vague notion that this represents a subcategory of tools, but can't put into precise language yet.

Something like grep doesn't count, because it takes a description and does some actions, and neither does a debugger doesn't count, either, because you don't give it a spec, but instead manually frob the program. But something like tsort would be much closer, because it takes a data file and produces some more data. I guess in a Unixy sense I'm thinking of things that would nearly always called as part of a pipeline, except that in this case a human is part of the pipeline. Maybe.

I need to make a list of tools to say "yes" or "no" to, so that I can determine which properties are common to the classification my brain is using.