> From: "Jon Hitchcock" <yyyyyyyyyyyyy@xxxxxxxxxxxxx>
> Date: Fri, 23 Mar 2001 15:39:55 -0000
>
> Gleens Seeds wrote:
> > ..., except
> > that it's very important not make existing conforming implementations
> > non-conformant. It's also important to try to avoid (if
> > possible) making
> > existing portable applications non-portable.
>
> Surely this is back-to-front. Isn't the model that there are a few
> implementations (written by people who have a good understanding of
> standards and the issues involved) and lots of applications (written
> by averagely competent programmers).
I'm afraid that in this particular case, that model has broken down.
We found no implementations that support the full POSIX collating
sequence model and conform to the current POSIX standard.
We also found murky parts of the standard that are rarely used and
which do not match ordinary user expectations: for example, the
current standard requires "[^[:lower:]]" to match "aa" in Danish locales.
This murk and confusion in the standard has contributed to implementer
confusion. It's no coincidence that the murk occurs in the same area
that makes it impossible to write a feasible user-space regular
expression matcher.
Our majority consensus was to reduce the murk by leaving parts of the
behavior unspecified if those parts have proved troublesome in practice.
This allows existing implementations to conform, even though they
don't conform now. (If anybody had written a conforming
implementation, it would also continue to conform. :-)
This makes it possible to write a user-space regular expression matcher.
Keld does not agree with this consensus, and has proposed adding
further requirements to the standard instead. He has some good
arguments which I am sympathetic to. However, my own feeling is that
the committee should not be the innovator in this area. Any changes
that invalidate existing implementations should first be done by at
least one real implementation before being codified into the standard.
|