🚀 go-pugleaf

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: pc@hillside.co.uk (Peter Collinson)
>September the 16th, 1992... the IEEE Standards Board is due to approve P1003.2
>as an IEEE Full Use Standard...

Which is a pity, unfortunately, because despite all the delays, if ever a
standard deserved to spend some time at the intermediate stage of Trial
Use Standard, it's this one...

The fundamental problem is that most of 1003.2 has never been implemented
*from scratch* by people working only from the spec.  The folks who claim
to have implemented it have been hacking existing implementations to fix
what they think are the differences between their code and the standard.
They've missed all the interesting little places where the behavior called
for by 1003.2 is subtly different from what the existing code does, or
isn't even sufficiently well-defined to determine whether the existing
code meets it.

I've been only lightly involved with 1003.2, but in the three areas where
I have paid careful attention -- regular expressions, awk, and grep -- we
*know* there are still bugs in 1003.2.  Not big ones, but not entirely
trivial either.  The scary part is that both 1003.2 regular expressions
and 1003.2 awk were considerably improved at the eleventh hour because I
actually *tried* from-scratch implementations (although only a partial
one in the case of awk), and the lengthy 1003.2-bug lists that resulted
arrived (just) in time to get things fixed.  Unfortunately, I and others
have found more since, and it's too late.

Understand:  this is not the result of gross negligence.  I reviewed several
of the earlier regular-expression drafts; I *thought* they looked fine.  As
did other competent people.  Similarly, the awk draft looked fine to me --
and to people who have implemented awk -- until I actually tried to write
a parser from it, at which point I noticed that (for example) nobody had
ever specified the precedence of the "|" operator...

It's too late to do anything about 1003.2, I'm afraid, except to push for
a revised version soon (but not instantly -- we desperately need some more
implementation experience first), and meanwhile be aware that the standard
is seriously flawed and *is* likely to get revised.  But I'm deeply
concerned about the wider implications.  There isn't much wrong with
1003.1, but it sure looks to me like that happy state of affairs isn't
going to be repeated for the later POSIX standards, especially the big
and complex ones like 1003.2.

What can be done?  Just getting more people involved is *not* the answer,
although it can't hurt and might help a little.  In the three areas I
mentioned above, the specs were already being reviewed by some of the
Unix community's top experts in the topics, including major implementors.
You just canNOT find these problems without writing code from the spec.
Nothing else works.  We need to find some way to encourage more early
implementations (from scratch, not as modifications of existing ones,
so the specification problems get faced squarely), and preferably some
way to keep the standards from getting cast in concrete until at least
the early returns are in.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 29, Number 33

Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)

Henry Spencer writes:
> You just canNOT find these problems without writing code from the spec.
> Nothing else works.

Seems about time to repeat this:

What makes standard-writing so attractive is that it strokes your ego.
You get to write down your musings about how the world should work, and
boom! Everyone does what you say. You don't have to waste time actually
*implementing* your ideas, or working out the problems, or competing
with people who were foolish enough to try their non-POSIX-approved
products on the market. You've got an _ego standard_.

This psychological explanation may sound a bit nasty, but it explains a
lot. It explains why POSIX members react emotionally to any hint that
their standards don't reflect the real world or are technically
inferior. It explains why no POSIX ``standard'' describes the state of
any actual system at the time of standardization. It explains why POSIX
people are so incredibly enthusiastic about writing standards, when in
the real world writing a standard means drudging through existing
documentation and rehashing it in the dullest possible language.

I wish POSIX would stop shooting off into the cosmos, come back to
earth, and spend some time documenting what UNIX systems actually *do*.

---Dan

Volume-Number: Volume 29, Number 34

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

In article <190k6vINN5g9@ftp.UU.NET> brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein) writes:
>   I wish POSIX would stop shooting off into the cosmos, come back to
>   earth, and spend some time documenting what UNIX systems actually *do*.

Funny, the POSIX meetings I've been to have tended to involve a lot of
discussion of existing practice and a lot of drudging through existing
documentation and rehashing it in the dullest possible language.  What
that drudging has generally led to is a realization that none of the
existing documentation specifies *anything* completely enough and that
every vendor's UNIX system is different.  So you have to write a
standard that specifies things nobody specified before and you have to
try to merge different versions of the same functionality.  And if
you're a responsible engineer, you have to resist standardizing bad
practice just because it is existing practice.

scott
--
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 29, Number 35

Submitted-by: mike@getafix.cs.uoregon.edu (Michael John Haertel)

In article <192n6aINNlt2@ftp.UU.NET> preece@urbana.mcd.mot.com (Scott E. Preece) writes:
>And if
>you're a responsible engineer, you have to resist standardizing bad
>practice just because it is existing practice.

The problem is that often one person's bad practice is another's holy
grail.  Certainly, we can all agree that some things are bad practice.
But there are also many more things that lots of people still don't
agree on.  For example, I happen to think that Berkeley's socket
interface is a terrible way to do networks.  I know lots of people who
agree with me.  But I also know lots of people who disagree, often
quite vehemently.

So where do you draw the line between resisting the standardization
of bad practice, and gratuitously standardizing some committee member's
notion of the One True Way (existing implementations be damned)?

Existing systems all have their flaws, but at least we know what they
are.  Any new invention, by a standardization commitee or anyone else,
will inevitably include new flaws.  I feel the scope of standards
should be restricted to what's well-understood.  Introducing new flaws
that are not well understood to a standard that is to be carved in
stone is not a Good Idea.


Volume-Number: Volume 29, Number 36

Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)

Scott E. Preece writes:
> So you have to write a
> standard that specifies things nobody specified before and you have to
> try to merge different versions of the same functionality.

Ah, but you never _have_ to write a standard.

You see that systems vary widely in, e.g., the output format of ``who'',
and even the type of information stored in /etc/utmp (or whatever file
``who'' reads). Does this mean you have to apply your imagination,
specify what the market hasn't specified, merge what the market hasn't
merged? No. It's a very strong signal that standardization is premature.
You shouldn't standardize ``who'' at all. Wait for market convergence.

You see that the market has come to agree on what you are sure is bad
practice. Does this mean you have to resist documenting that practice in
a standard? No. It means that your conceptions of what's good and bad
are out of sync with the market. Your responsibility as standards-writer
is to document what's being done, not to dream up new solutions. ``Only
those who code have the right to dream.'' If you can identify a
technical flaw in the bad practice, go ahead and document that! If
you're sure that you can make a better solution, try it on the market!

---Dan, still wondering why POSIX [:digit:] is better than Perl \d


Volume-Number: Volume 29, Number 37