🚀 go-pugleaf

Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)

The problem is that in the current environment saying "Don't make us
write test methods" really means "We think it's better to send the
standard our a little half-baked than to take the time to remove another
round of ambiguities."  That *may* be the right answer.  It may very
well be that more ambiguities will be exposed and interpreted by getting
the standard out for people to implement.  On the other hand, it also
may be that each implementor will guess and interpret when faced with
ambiguity, rather than seeking interpretation through inconvenient and
possibly slow official channels.

What is important about the test method requirement is that it requires
the standard writers to translate the specification into another form.
There is no structural guarantee that the alternative form will be
complete or perfect, but there is a high probability that *some*
ambiguities will be exposed.

My experience with trying to get a system to meet a standard that was
intended to be quite unambiguous (the 88000 version of the SVR4 ABI) is
that none of the existing standards is there yet and that forcing the
authors to think about them a little longer and in a different form is
for the good, though I must also acknowledge that I don't know how my
own work group is going to get that work done, either.

If we can't keep our people and our companies interested, we're going to
be stuck with one unambiguous standard: what runs successfully on NT on
the architecture whose name I prefer to leave unuttered...  I think that
would be for the worse, and I hope I would feel that way even if it were
our architecture that were the common reference.

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550


Volume-Number: Volume 30, Number 17