From: Robert Klemme <bob.news@...>
Date: 2004-10-06T17:24:50+09:00
Subject: Re: Table-driven dispatch


"James B Crigler" <james.b.crigler@lmco.com> schrieb im Newsbeitrag
news:4162E782.C8ED4164@lmco.com...
> I like this solution, except it solves the wrong problem.  That's
> my fault because I didn't quite give enough of the problem
> specification.  I have over a thousand individual files to scan, some
> with a couple of thousand lines.  Some fields are not tagged, but
> ASCII paragraphs, and these can be interspersed with the tagged lines.

Well, maybe you start over again by describing the use case.  Some
questions that might help in doing this:

 - What problem are you trying to solve?
 - What's the input? (format, size)
 - What's the expected output?

> Also, Robert's solution applies a capturing Regexp to every line of
> the file.  (I didn't specify it, but performance is at a premium here.)

Well, your original solution did apply multiple regexps per line if I
remember correctly (i.e. in the case where you are searching for more than
one type).  A regexp match against the line is cheap, and you have to
check *somehow* what kind of line you have.  After all, how else do you
want to find out which lines are tagged and which lines aren't?

> I will probably use the part about putting the fields into a local
> hash as the fields I want are parsed out.  Also the tag translation
> hashes are a nice touch.
>
> Consider what happens in Robert's solution when confronted with this
> (not exactly according to my document specification, but you'll get
> the idea):
>
> -----------
> Title:  A Tale Of Two Cities
> Author: Charles Dickens
> Analysis:
> There are many different ways of interpreting Mr. Dickens's
> Title:  It is reminiscent of, for instance, the title of
> St. Augustine's book, The City of God.
> -----------
>
> (This is easily programmed around (just take the first title, author,
> whatever).)
>
> In the problem I'm trying to solve, I am making ad hoc queries at the
> command line and turning them into a filter procedure in an eval.
> I don't know which fields I'll be querying or printing until after
>
>     filter = eval "proc { |#{mode}| #{filter_expr} }"
>
> is evaluated.

But you know them at the start of the script (afer evaluating of the
command line arguments):

>  ("mode" contains the subclass of document, e.g.,
> "novel"; "filter_expr" contains the filter expression (surprise! ;-)
> passed in from the command line, and it is supposed to contain stuff
> like "novel.title =~ /city/i" and so on.)  A separate bit of command
> line syntax selects fields to print.

So you have two selection mechanisms:

 1. the records to choose
 2. the fields of the result records to print

Code generation for 1. is certainly a good idea, because that usually
yields superior performance.  I won't go into more detail at the moment
partly because I feel there's not yet enough information and partly I
don't have the time right now.

Regards

    robert