<< 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