multiline parsers, take 372576259327

[Erik Ostrom <eostrom@research.att.com>]

>Let me give an algorithm for _data-tag less parsing of multiline data
>so that you can see how simple it is.

That sentence might be read as a little bit condescending.

While it seems clear that there exist simple algorithms for parsing
multiline data with _multiple_ data tags, I'm still puzzled by your
assertion that it "greatly simplifies" your parser.  The two multiline
parsers that I've worked on haven't seemed unnecessarily complicated.
Is it possible that there's some obscurity in the spec that led you to
a much more complex implementation than is necessary for the
single-data-tag case?

I was going to sketch an algorithm for single-tag parsing--it's
obvious, but it seemed appropriate--but I see Ken's already sent one.
It looks like it's a decision of where you want to put your
complexity.  Multiple data tags allow you to handle continuation lines
with a single lookup.  Single data tags allow you to handle the end
line with no effort at all.  And other assorted differences that, all
in all, seem difficult to compare.

And, of course, it's not so much a matter of what the algorithms allow
as what these implementations do.  For example, it would be simple
enough to do continuation lines with a single lookup in the multi-tag
case:  Just construct your key by appending the data tag, a space, and
the field name.

But that's just efficiency details.  My main point is, I don't see how
this decision affects parser complexity much.  (I've been speaking of
complexity of the code, in some human sense, rather than computational
complexity, but I believe the same statements hold.)

Okay, that's all.

--Erik