ietf-822
[Top] [All Lists]

Re: text/enriched

1993-09-03 06:18:21
<< I particularly agree with this.   << introduces "special case" logic that
<< I think we could avoid.   It's a state machine;  keep it simple.

< It hits my parser in a completely different way that does require "special
< case"  logic.   Everywhere else I can  "look between the angle brackets",
< but here I have to explicitly look for an immediate following second open
< angle bracket,  and if it's there I must NOT look for a close.

Parsers can be written in many ways, some of which work better with the
rules than others. If you were writing this in lex, the rules to handle
<< and <...> would look something like

        <<              return '<';
        </[^>]*>        strcpy(token, yytext); return RTOKEN;
        <[^>]*>         strcpy(token, yytext); return TOKEN;

That doesn't look like any special case logic to me! :-)

Now, if you want to talk about special case logic, how about the fact that
<lt> doesn't have a corresponding </lt>? Now THAT's a special case! :-)

Sorry, to me, your arguments aren't sufficient to override the fact that
"<<" LOOKS better than <lt>. Which means that I completely disagree with the
semi-statement made here.

< To avoid rehashing the olde argument,  I won't say anything about
< cosmetics being totally unimportant to processable text.

                                        Tony Hansen
                            hansen(_at_)pegasus(_dot_)att(_dot_)com, 
tony(_at_)attmail(_dot_)com
                                att!pegasus!hansen, attmail!tony

<Prev in Thread] Current Thread [Next in Thread>