keld@login.dkuug.dk (Keld J|rn Simonsen) (04/06/91)
rja@altair.cho.ge.com (Randall Atkinson) writes: >[ The quoting here is getting confusing, so I'm putting Keld's remarks with > the greater than symbol and Doug's remarks with the percent symbol. :-) rja ] >In article <keld.670719584@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes as a reply to an article of Keld's: I broke the reply up in two parts. This latter is breaking up old wounds, and is quite unrelated to the former. It is much history and politics, and does not have much tecnical nor constructive texture. >Keld appears to acknowledge that there is NO technical problem >with the standard. But watch how he ignores this down below: >>ANSI and DS (Danish Standards, the Danish equivalent to ANSI in ISO) >>have disagreed on the necessity of a *readable* and *writeable* alternative >>to a representation of C source in invariant ISO 646. Invariant ISO 646 >>is the same as ASCII with 12 positions left undefined - to be decided by >>national ISO bodies. ANSI decided on the ASCII character set, a lot of >>other ISO member bodies - especially in Europe - decided to use these >>positions for national letters and the like. Then invariant ISO 646 is >>the greatest common denominator for these character sets, all derived >>from the international standard ISO 646. >However, all of western Europe is moving rapidly to the ISO 8859/1 >standard which has none of the ISO 646 problems at the source level >and moreover the trigraphs address the ISO 646 technical problem >(which I emphasise is a temporary problem already starting to fade). Yes, it is fading, but slowly. I have recently been involved in discussions about 8-bit SMTP and there many *Americans* said that there will be a considerable amount of people over there sticking to American 7-bit, on one or the other way. The same is true here. I run on a 8-bit capable PC, but still run the Danish 7-bit code, for various reasons. I hope to convert soon, tho. >The POLITICAL issue is coming from the Danes who feel that their >local character set standard based in ISO 646 should be the focus >of the whole world and that long standing C practice should be >broken to make them feel better. It is not our local standard we want supported, but ISO 646 invariant, which is an *international* standard, and the base for all national ISO 646 standards. >WG14 passed resolutions both ways depending on who had spoken more >recently to the group, whether the history of the question at the >X3J11 level and the history of the C language was presented, >and also some political grounds. The Danes ignored the WG14 decisions >against them and then turn around and accuse X3J11 of being indifferent >for their insistence on sticking to technical merit rather than >political issues. WG14 only let us down once, and that was after X3J11 ignoring WG14 resolutions for a long period, and after X3J11 at a combined meeting made it clear that they were very reluctant in implementing the WG14 resolutions. WG14 are now fully behind this Danish requirement. Keld Simonsen
gwyn@smoke.brl.mil (Doug Gwyn) (04/06/91)
In article <keld.670872140@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >It is not our local standard we want supported, but ISO 646 invariant, >which is an *international* standard, and the base for all national >ISO 646 standards. And which the existing C standard does support. >WG14 are now fully behind this Danish requirement. That is not what I hear from other WG14 members.
keld@login.dkuug.dk (Keld J|rn Simonsen) (04/07/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <keld.670872140@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >>It is not our local standard we want supported, but ISO 646 invariant, >>which is an *international* standard, and the base for all national >>ISO 646 standards. >And which the existing C standard does support. ISO 9899:1990 supports ISO DIS 646 IRV, not the invariant part of 646. >>WG14 are now fully behind this Danish requirement. >That is not what I hear from other WG14 members. I think these members are not that well informed then. I quote the #10 resolution from the WG14 Copenhagen meeting 90-11-27 "It is the opinion of WG14 that the problems caused by national variants of ISO 646 have to be solved" This resolution was unanimously approved.
rja@altair.CHO.GE.COM (Randall Atkinson) (04/07/91)
In article <keld.670872140@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: [ Randall Atkinson`s previous article text is preceded by %'s ] % However, all of western Europe is moving rapidly to the ISO 8859/1 % standard which has none of the ISO 646 problems at the source level % and moreover the trigraphs address the ISO 646 technical problem % (which I emphasise is a temporary problem already starting to fade). >Yes, it is fading, but slowly. I have recently been involved in >discussions about 8-bit SMTP and there many *Americans* said >that there will be a considerable amount of people over there >sticking to American 7-bit, on one or the other way. >The same is true here. I run on a 8-bit capable PC, but still run >the Danish 7-bit code, for various reasons. I hope to convert soon, tho. % The POLITICAL issue is coming from the Danes who feel that their % local character set standard based in ISO 646 should be the focus % of the whole world and that long standing C practice should be % broken to make them feel better. >It is not our local standard we want supported, but ISO 646 invariant, >which is an *international* standard, and the base for all national >ISO 646 standards. Actually, what Keld acknowledges above but conveniently ignores here is that the ISO 646 standard has been SUPERCEDED by the ISO 8859/* family of standards referred to above. There is no need for anything but trigraphs to support the temporary issue of ISO 646 that Keld acknolwedges is fading. Trigraphs are a sufficient solution and the Danish proposal will add incompatible permanent changes to resolve a very temporary problem. The folks at X3J11 were very careful to standardise existing practice and avoid all needless deviance from existing practice. The Danes however are proposing adding needless and potentially dangerous deviations. >>WG14 passed resolutions both ways depending on who had spoken more >>recently to the group, whether the history of the question at the >>X3J11 level and the history of the C language was presented, >>and also some political grounds. The Danes ignored the WG14 decisions >>against them and then turn around and accuse X3J11 of being indifferent >>for their insistence on sticking to technical merit rather than >>political issues. > >WG14 only let us down once, and that was after X3J11 ignoring WG14 >resolutions for a long period, and after X3J11 at a combined meeting >made it clear that they were very reluctant in implementing the WG14 >resolutions. WG14 are now fully behind this Danish requirement. What Keld ignores is that on the occasions when WG14 has sided with the Danes, there was inadequate representation of the history of X3J11's decisions and rationale to WG14. At the only hearing where that was present, WG14 supported X3J11 after hearing both arguments. I hear far too much dissent from other folks on WG14 for the claim "fully behind" to be accurate. Keld still has never posted any definitive TECHNICAL description of the Danish "problem" on this list and I think that if he is going to continue to raise this "problem" here that he should post a full and complete technical problem statement here for further discussion by all. Randall Atkinson
gwyn@smoke.brl.mil (Doug Gwyn) (04/08/91)
In article <keld.671027491@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >ISO 9899:1990 supports ISO DIS 646 IRV, not the invariant part of 646. I hope you'll explain this, as I thought that ISO 9899:1990 supported use of that portion of ISO 646 that was common to all national variants. If that is not "the invariant part", then what is?
enag@ifi.uio.no (Erik Naggum) (04/12/91)
In article <keld.671027491@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes:
I think these members are not that well informed then.
I quote the #10 resolution from the WG14 Copenhagen meeting 90-11-27
"It is the opinion of WG14 that the problems caused by national
variants of ISO 646 have to be solved"
This resolution was unanimously approved.
Keld,
I'm completely at loss why this is a problem. I have TWO terminals:
One Norwegian (using ISO 646 with ISO registration number 60, ISO 2022
announcer ESC 2/8 6/0), which I would use to type letters, memoranda,
reports, etc, and one American (using ISO 646 with ISO Registration
number 2, ISO 2022 announcer ESC 2/8 4/2) for source code in a number
of languages. This is the hardware solution to the problem you state
above. It's elegant, simple and a little less expensive to implement
than your proposals.
The other hardware-oriented solution is to get a terminal which can
switch between ISO 646 Reg no 2 and ISO Reg no 60 via ISO 2022
announcer sequences. This is an even less expensive solution than the
above (despite the fact a terminal which can do this is slightly more
expensive than each of the two I have).
With user-definable fonts (as in X11 applications), this is also a
tremendous non-issue.
If we're talking about printers which use ISO 646 and national
variants, I can only say that I have yet to see a printer which
doesn't accept a "language setting". Since a good programmer puts all
the strings a user will ever see into a separate file, anyhow, there
is no problem to this issue, either.
If I get your proposal right, you wish to solve a problem which is
experienced by programmers who have too poor or too sloppy employers
to provide them with proper terminals. Is that really the proper
stuff for International Standards?
If there is ever going to be an International Standard on this, I hope
it will say:
A user of the programming language specified in this Inter-
national Standard should use the proper hardware to view his
code such that the ISO 646 IRV characters are displayed rather
than a national variant. Conformance to this requirement is
outside the scope of this International Standard.
But I realize that this is definitely not the proper stuff for
International Standards...
--
[Erik Naggum] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>keld@login.dkuug.dk (Keld J|rn Simonsen) (04/12/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <keld.671027491@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >>ISO 9899:1990 supports ISO DIS 646 IRV, not the invariant part of 646. >I hope you'll explain this, as I thought that ISO 9899:1990 supported >use of that portion of ISO 646 that was common to all national variants. >If that is not "the invariant part", then what is? ISO 646 is very much like ASCII (actually ASCII is the ANSI version of ISO 646). ISO 646 has defined 12 positions for national use, these positions you can call the "variant positions". These 12 characters are: #$@[\]^`{|}~ The remaining 83 graphical codes in ISO 646 are called "the invariant part" of 646. This is actually what the trigraphs are for: to represent ISO/ANSI C in invariant 646, which is the greatest common denominator between national 7-bit character sets. ISO 646 IRV means International reference version. Here the 12 positions are defined, currently as something a little different from ASCII, but it is expected that ISO 646 IRV will be equivalent to ASCII quite soon. The ISO C standard supports the invariant 646 via the trigraphs. Trigraphs were not designed for readability and writability, and WG14 is looking into a more readable and writable support in C in the invariant ISO 646 character set. Keld Simonsen