🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2684

ISO 646 alternate representation

#2684
From: Keld J|rn Simonsen
Date: Fri, 05 Apr 1991 17:22
61 lines
3639 bytes
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
Technical Details
Message-ID: <keld.670872140@dkuugin>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!bloom-beacon!eru!hagbard!sunic!dkuug!dkuugin!keld
References: <keld.670436534@dkuugin> <15651@smoke.brl.mil> <keld.670719584@dkuugin> <1991Apr4.171657.27791@murdoch.acc.Virginia.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!bloom-beacon!eru!hagbard!sunic!dkuug!dkuugin!keld
From: keld@login.dkuug.dk (Keld J|rn Simonsen)
Newsgroups: comp.std.c
Subject: ISO 646 alternate representation
Message-ID: <keld.670872140@dkuugin>
Date: 5 Apr 91 17:22:20 GMT
References: <keld.670436534@dkuugin> <15651@smoke.brl.mil> <keld.670719584@dkuugin> <1991Apr4.171657.27791@murdoch.acc.Virginia.EDU>
Sender: news@slyrf.dkuug.dk
Lines: 61