lum@osu-eddie.UUCP (Lum Johnson) (12/20/86)
[It's unclear who made remarks prefaced by ">> ". Sorry.] In article <3987@watmath.UUCP> rbutterworth@watmath.UUCP (Ray Butterworth) writes: >In article <5458@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn) writes: >>> The standard should specify .. escape sequences for implementations that >>> use the USASCII or Latin 1 alphabets, ... >> >> So long as we don't mandate ASCII/ISO character sets, this is infeasible. > > [M]any things .. are .. inappropriate for some machines, and the standard > should not mandate their existence, but there is no reason [not to] say > something about them. > > The committee has refused to define "\e" as the string escape sequence for > the ASCII character ESC on the grounds that [for implementations that] won't > be using ASCII .. this would be impossible .. to implement. But [that]'s no > reason for not [saying] "for implementations using the ASCII character set, > '\e' will be the ESC character" [or defining] appropriate escapes for other > common character sets such as Latin 1. > > There are many such instances where something that would be useful in some > implementations has been omitted from the standard because it cannot > reasonably be required in all implementations. This means that each > individual implementation that wants such a feature is going to have to > invent its own method (as the standard allows), and that many of these > implementations will be needlessly different. I believe that may be intentional. Have you ever heard of the principle of "Equal Disadvantage"? If we put "\e" into the standard just because it is obviously correct for ASCII implementations, it would be a significant disadvantage to vendors of alien equipment which use non-standard char sets. ASCII implementations would become even more interportable than they now are. To reduce the already fearsome disadvantage to alien vendors, it is necessary to mandate an uneven playing field which treats them as more equal than they truly are. In other words, omissions in the standard may be (and I believe should be viewed as) a covert non-economic subsidy to such alien vendors. They will not lead to "needless" differences at all; differences, yes, but needless, no, not from the viewpoint of protecting said alien vendors. Frankly, I think it's time for us to crush this anti-standard bias once and for all by simply adopting a level playing field that clearly recognizes and _respects_ the existence of various well-known standards and does not unnecessarily avert the appropriate penalties for willfully ignoring them. If this "standard" will not address such things then there ought to be a supplementary standard written by and for those who follow such standards to specify compliance with those standards for implementors of this standard. Lum Johnson lum@ohio-state.arpa ..!cbosgd!osu-eddie!lum Enufk is enufk - that's all I can takes, I can't takes no more. - Popeye
lum@osu-eddie.UUCP (Lum Johnson) (12/24/86)
In article <2758@osu-eddie.UUCP> lum@osu-eddie.UUCP (Lum Johnson) writes: >> The committee has refused to define "\e" as the string escape sequence for >> the ASCII character ESC on the grounds that [for implementations that] won't >> be using ASCII .. this would be impossible .. to implement. But [that]'s no >> reason for not [saying] "for implementations using the ASCII character set, >> '\e' will be the ESC character" [or defining] appropriate escapes for other >> common character sets such as Latin 1. >> > I believe that may be intentional. Have you ever heard of the principle of > "Equal Disadvantage"? If we put "\e" into the standard just because it is > obviously correct for ASCII implementations, it would be a significant > disadvantage to vendors of alien equipment which use non-standard char sets. > ASCII implementations would become even more interportable than they now are. > To reduce the already fearsome disadvantage to alien vendors, it is necessary > to mandate an uneven playing field which treats them as more equal than they > truly are. In other words, omissions in the standard may be (and I believe > should be viewed as) a covert non-economic subsidy to such alien vendors. > They will not lead to "needless" differences at all; differences, yes, but > needless, no, not from the viewpoint of protecting said alien vendors. Before anyone mistakes this for a personal attack, I wish to say that this was definitely _not_ so intended. I am impugning the process, not the people. I'm just PO'd that the process is failing even to mention other well-known standards, let alone to state definitively how this standard should interact with them, when there is no objective reason for permitting such an omission. Lum Johnson lum@ohio-state.arpa ..!cbosgd!osu-eddie!lum Enufk is enufk - that's all I can stands, I can't stands no more. - Popeye (Corrected quote - It's funnier with "stands" instead of "takes", anyhow.)