program size

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> It has been suggested that an alternative to flex might exist.  What do
> y'all know of this subject?  Anybody interested in taking on the task of
> testing alternatives?

Offhand, I know about ANTLR/DLG (recent versions only emit C++ and Java
though), and I seem to recall something like e2c or something that also
builds parsers, and we might do individual parsers manually.

Is there some profiling option in terms of code complexity in flex?

OTOH, can we make some "functional" (or equivalent) approach for our
lexers (call it daisy chaining if you like)? If we have one "parser"
call into another, we might split "parsers" across logical levels. A
low-level one could parse the message into MIME parts and swallow the
attachments, a higher level one might do what the old lexer_text or
lexer_html did. These lexer_{text,html} would call into the mime parser
when they need more input. I hope the low-level lexer doesn't need to
buffer much more than a line of input.

The old multi-lexer approach suffered because we switched between lexers
rather than cascading them, which led to troubles with mail boundary
detection (we had to have mbox "^From " recognition code in all the
lexers).

-- 
Matthias Andree