Re: empty quoted strings and other oddities

"Gary Feldman" <gaf@ziplink.net> Thu, 03 October 2002 02:25 UTC

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g932Pj500541 for ietf-822-bks; Wed, 2 Oct 2002 19:25:45 -0700 (PDT)
Received: from relay-2.ziplink.net (relay-2.ziplink.net [206.15.168.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g932Piv00535 for <ietf-822@imc.org>; Wed, 2 Oct 2002 19:25:44 -0700 (PDT)
Received: from alice (reston-ip-206136-138.dynamic.ziplink.net [206.15.136.138]) by relay-2.ziplink.net (8.11.6+Sun/8.10.2) with SMTP id g932Pks25719 for <ietf-822@imc.org>; Wed, 2 Oct 2002 22:25:46 -0400 (EDT)
Message-ID: <000e01c26a84$9358e8a0$0201010a@alice>
From: "Gary Feldman" <gaf@ziplink.net>
To: <ietf-822@imc.org>
References: <200210011513.g91FDk027592@astro.cs.utk.edu> <002001c26a0f$f05437a0$b7880fce@alice> <20021002163610.C1650@melkebalanse.gulbrandsen.priv.no>
Subject: Re: empty quoted strings and other oddities
Date: Wed, 2 Oct 2002 22:28:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

>From: "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
>Sent: Wednesday, October 02, 2002 10:36 AM

>
> Well, assume for the sake of argument that it's relevant. Is it also
> valuable enough to justify changing email after 25 years of production
> use, with a user base presumably in the hundreds of millions, using god
> knows how many thousands of different programs?

I don't buy that argument either.  People upgrade routinely.  Supporting
obscure and
old programs, while not entirely a non-issue, nevertheless should have a
limited and
controlled ability to hamper progress.

> Each extra syntax check involves writing at least one more test in the
> code, at least two more test cases to verify the code's correctness, some
> documentation and some (UI and documentation) translations. And then
> there's the (slightly) increased cost of learning the code for the
> subsequent maintainers, and the UI for the users.

The main problem with this analysis is that it ignores the comparison with
semantic side catching of the problem.  Also, the issue at hand is a
boundary
condition, and hence the test cases need to be there, regardless of how it's
defined.  Finally, whether or not it actually causes that extra effort and
cost
of learning depends on how it's implemented in the first place.  It could,
for
example, be done with (a descendant of) lex, or a homegrown table driven
lexical analyzer, or with a Perl pattern, or any number of other
well-structured
lexical or syntactic analysis techniques.  Granted, many implementations
won't
be so eloquent, but again, the extent to which that should be allowed to
hamper progress should be limited.

I apologize for the depth of this digression.  I realize that it's far more
an
issue of philosophy than the relatively minor issue of this point of syntax.

Gary