rex@aussie.UUCP (Rex Jaeschke) (04/24/89)
Hi, I'm the new US representative for X3J11 to the ISO C working
group. Although I attended three of the last four ISO C meetings (I
missed last week's joint meeting in Seattle), I did so in an observer
capacity as P.J. Plauger was both the US rep as well as convener.
ISO has announced a policy that they prefer the conveners to be
impartial and not also be a country's rep. Therefore, I have stepped
in to be the new IR (International Rep) for the remainder of the
process (which most of us hope will be very short.) At this stage, the
chances of having identical ANSI and ISO standards is very very good.
(I have also been a member of X3J11 since December 1984.)
The primary objection at this stage comes from the Danes who want
more readable trigraphs (don't we all.) However, all forms of
their proposal have been soundly rejected by ANSI for 3-4 meetings now
and last week in Seattle, even ISO voted not to back them on this
issue. The problem stems from the fact that they use the ISO-646
character set which, as you may know, doesn't have characters such as
[, ], {, }, #, |, and \. They also wanted an infix operator ! as an
alternate to subscripting such that a!b == a[b]. There are technical
problems they have not solved (for example, how to write a[]) and this
is the main reason the proposal has been rejected. Also, their
proposal is in addition to the existing trigraphs, NOT instead of so
it adds more baggage.
The UK still has some doubts about the ANSI standard mostly in that
they want all undefined behavior to be specifically stated so rather
than making it the default. Currently, if nothing is said, it is
unspecified or undefined.
FYI, you may have seen my recent (indirect via Friedl) posting re my
formation of a Numerical C Extensions Group (NCEG). Interest has been
very high and the planned meeting will go ahead May 10-11 at Cray with
20-25 people attending. I'll post a status report within the week. The
plan for NCEG is to build upon ANSI C in a compatible manner. At this
stage, I think it likely that in the near future NCEG will become a
working group within X3J11.
Finally, I must apologize for my garbage test message posting this
last week. I have been trying to resolve a broken link "somewhere in
usenet" for several months now and that test message was not
expected to get through. I intend future postings to have less
garbage.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA
----------------------------------------------------------------------------njk@freja.diku.dk (Niels J|rgen Kruse) (04/25/89)
rex@aussie.UUCP (Rex Jaeschke) writes: >Hi, I'm the new US representative for X3J11 to the ISO C working >The primary objection at this stage comes from the Danes who want ????? Who are they and what do they represent? >issue. The problem stems from the fact that they use the ISO-646 >character set which, as you may know, doesn't have characters such as >[, ], {, }, #, |, and \. They also wanted an infix operator ! as an >alternate to subscripting such that a!b == a[b]. There are technical ^^^ Argh! >problems they have not solved (for example, how to write a[]) and this The solution is to buy equipment that support both ascii and ISO-646, using ascii for programming and ISO-646 for danish text. Even when stuck with ISO-646 only equipment it is not too hard to memorize the ISO-646 characters that map into the bitpatterns recognized by C compilers as {}[]|\. (ISO-646 is identical to ascii except for {}[]|\ ) >Rex -- Name : Niels J|rgen Kruse Organization : DIKU, University of Copenhagen, Computer Science dept. Email : njk@diku.dk Mail : Tustrupvej 7, 2 tv, 2720 Vanlose, Denmark
bph@buengc.BU.EDU (Blair P. Houghton) (04/25/89)
In article <6.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: >[...] >Finally, I must apologize for my garbage test message posting this >last week. I have been trying to resolve a broken link "somewhere in >usenet" for several months now and that test message was not >expected to get through. I intend future postings to have less >garbage. No need to apologize, Rex. It's Net.de.facto that anything marked "test" is to be summarily ignored and forgiven the bandwidth, and usually it is. (Unfortunately/obviously), some of us have more (wit/ego) than (restraint/sense), and can't pass up the opportunity to make our (humor/immaturity) public. I must say I am certainly (sorry/bleraugh!) myself for cluttering this group. That done, on to some std biz. You mention that the Danes are unimpressed with trigraphs, and that the UK want the unspecified specifications to be specified to be unspecified (and I thought I'd stopped joking...well, I have...), so, my question is, Just how much input have foreign countries had in the _A_NSI spec? I'm not being chauvinistic, I just find it odd that ANSI is handling any considerations in deference to other nations. It seems that such things would be better served by writing an ISO spec for C. Consider also that the Danish trigraph complaint is mediated by their reliance on an ISO character set that forces them to use the dreaded things. I realize that it's likely that C is protected by some form of technology-export restriction, but that raises the paradox of "why trigraph to please foreigners if they ain't s'posed to have it?" So, my next question is, when is the ISO C committee forming, and how many boxtops from Kernighan and Ritchie's Sugar Coated C Structs do I have to submit to become a member? --Blair "...and Einstein did get the creamed corn out of his hair..."
barmar@think.COM (Barry Margolin) (04/26/89)
In article <2663@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >Just how much input have foreign countries had in the _A_NSI spec? I'm not in X3J11, but I am in X3J13 (the Common Lisp standardization committee), and international issues come up there, too. In general, there doesn't seem to be a restriction against foreign members of ANSI committees. We have several Japanese and European members in X3J13. >I'm not being chauvinistic, I just find it odd that ANSI is handling any >considerations in deference to other nations. There are several reasons why international issues impact US standards. First of all, the ANSI committee provides the US representation to the corresponding ISO working group. Second, when developing an ISO standard, the best chance of success is provided if you simply propose an existing national standard; in this case, X3J11 would simply propose the ANSI C standard, which already has provisions for national character sets (we're making similar changes to Common Lisp for the same reason). Third, ANSI (or maybe just X3) frequently will not approve a standard that is known to conflict with an ISO standard; many of the members are multinational corporations, and it would be expensive for them to have to produce different versions of their products for domestic and foreign use. They can generally be convinced when national security is used as the excuse (e.g. the prohibition against exporting Unix crypt()), but they'll balk at childish not-invented-here syndrome. Finally, standardizing products that can be marketed outside the US helps US competitiveness in the world market. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
rex@aussie.UUCP (Rex Jaeschke) (04/26/89)
> You mention that the Danes are unimpressed with trigraphs, and that > the UK want the unspecified specifications to be specified to be > unspecified (and I thought I'd stopped joking...well, I have...), so, my > question is, > > Just how much input have foreign countries had in the _A_NSI spec? Anyone from anywhere in the world can attend and participate in ANSI standard meetings. However, you can only vote if you are a fully paid voting member or registered alternate. Voting members are not restricted to US citizens/residents/companies as many people believe. Since my involment in ANSI C (late '84) the regular non-US particpants have been HCR from Toronto (who also supplied the Canadian rep to ISO), IBM (much of their C work is in Don Mills, Ontario) and ICL, the UK's national computer manufacturer. ICL's principal rep is also VERY active in X/OPEN and POSIX (there is also an ISO POSIX group now.) Other nationals provided input on an ad-hoc basis either by attending or via public comment period or e-mail. (Mark Brader comes to mind as does Univ. of Waterloo, who both provided many, many useful changes and additions.) Once we decided to add support for western European character sets via locales the Europeans took quite some interest as did the Japanese who thought it would be nice if we could help them out as well. Hence, the multibyte package was invented. Much of the international interest in these areas was generated through P.J. Plauger's efforts. His company Whitesmiths (now sold to Intermetrics) has an international group of affiliates who, for the most part, are the main or only C vendor "in town." They are very strong in Japan, France and Australia, among other countries. So his affiliates and their customers provided feedback which Plauger collated, distilled and proposed. In his trips to Japan he addressed the Japan C Committee. Also, around this time he took over convenership of ISO C when Steve Hersee resigned (when Lattice was aquired by SAS.) As such, Plauger played a much bigger role in getting the international community involved. He, along with X3J11 and most ISO members quickly agreed that it would be best if ANSI and ISO standards were one and the same. That's why we slipped back probably two years to add the locale and multibyte stuff. I believe that the early interest in non-English environments probably arose because an increasing number of US venders were selling or were interested to sell to Asian and European markets. Then once ISO got involved it made good political sense. Also, doing non-trivial technical standards at the ISO level is difficult and expensive. Meetings are conducted in English (few attendee's first language), voting is done by consensus not majority, and travel is often more expensive and much fewer people would participate. > I'm not being chauvinistic, I just find it odd that ANSI is handling any > considerations in deference to other nations. It seems that such things > would be better served by writing an ISO spec for C. Consider also that > the Danish trigraph complaint is mediated by their reliance on an ISO > character set that forces them to use the dreaded things. I realize that > it's likely that C is protected by some form of technology-export > restriction, but that raises the paradox of "why trigraph to please > foreigners if they ain't s'posed to have it?" Pretty much all national standards bodies are affiliated with ISO and they all agree to not form national standards that violate/preclude, etc., other national interests. That is, all ANSI standards are almost "required" to recognize the existance of character sets such as ISO-646. Also, from ISO's point of view, once ISO convenes a standards working group, any national standard effort already in progress is then considered being done on ISO's behalf. That is, for the last several years all of X3J11's efforts have really been on behalf of the international community. Simply stated, the US has been the caretaker of what was really an international standard even if no ISO working group existed. So the notion that the American National Standards Association (ANSI) is simply for the US alone, is quite wrong. In many cases, ANSI standards are adopted in toto by ISO (or other national standards groups like UK's BSI) or are only slightly extended. To the best of my knowledge there is no restraint on shipping language technology out of the country. Certainly, the Soviet Embassy can buy a copy of Microsoft or Turbo C and ship it out of the country. Of course, reverse engineering it is more difficuly but why bother. Let Borland maintain it and get a copy of the next release and make 1,000 pirated copies within the USSR. Getting s/w for VAX, IBM mainframes etc., is not so simple. Plus you should understand the the Soviet Union is a member of ISO. In fact, to the best of my knowledge, the three official languages of ISO publications are English, French and Russian. Of course, the Russians do their own translation and are glad to since they are getting all the good information. ISO has no political boundaries and I don't see that ANSI does either since we allow non-US voting members. Heck, the Soviet block is probably monitoring this newsfeed. (As a side note, the DEC Professional, of which I amd C Editor, received notification from a Soviet technical journal that it had translated some of my articles and they sent me copies of the abstracts, in Russian.) ISO meetings are more like state department summits - it's often more diplomacy than technical substance. And since ANSI did most of the technical work the US reps quite often have to go on the defensive to explain why they did what they did. In my three ISO meeings (Paris, Amsterdam and London) I have felt a hint from a few members of "here the come the Americans riding rough shod over us trying to impose THEIR solution on us." I have certainly never felt that way. Interestingly, I'm Australian-born having been in the US only 10 years. But I guess I'm guilty by association. Actually, I understand the Japanese are ecstatic with our efforts - we did more than they ever expected. > So, my next question is, when is the ISO C committee forming, and how > many boxtops from Kernighan and Ritchie's Sugar Coated C Structs do I > have to submit to become a member? ISO/TC97/SC22/WG14 otherwise known as the ISO Working Group for C, first met in Chicago in mid-'86 I think, with Hersee as convener. It has met approximately every 6 months since having joint meetings with ANSI X3J11 in Paris 1987 and Seattle last week. I'm not sure how one joins or why you would want to. First a country nominates a primary and alternate representative who actual can vote. Meeting attendence is not compulsory to vote (it is in ANSI) so most countries that vote never attend and vote by letter ballot. The average ISO C meeting (without joint ANSI) is 5-8 people representing perhaps 5 countries. The meetings last for 1- 1 1/2 days. The mailings are very small and few substantive technical issues get resolved there. And, I believe, all significant ISO documents are included in ANSI C mailings. So if you are a paid-up X3J11 voting member (not observer) you should get all such mailings anyway. Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
rex@aussie.UUCP (Rex Jaeschke) (04/26/89)
> >The primary objection at this stage comes from the Danes who want > ????? > Who are they and what do they represent? The principal ISO representative from Denmark (at least at the meetings I attended) was Keld Simonsen. Eunet: keld@diku.dk. He was also supported by a gentleman whose name I forget, from Unisys. At the last 2-3 ISO meetings they proposed trigraph changes with the full support of the Danish Standards Association. (Their C working group is designated S142u22A1). The administrative contact there has been Claus Tondering, ct@dde.uucp. BTW, Keld and/or the Danish Standards Assoc. know Bjarne Stroustrop (the designer of C++) who is also Danish but resident in the US and working at Bell Labs NJ. Several versions of the trigraph proposal drafts actually have Bjarne's endorsement. And somewhere I recall seeing Bjarne's comment that "this shouldn't be too hard to implement" so the Danish rep thinks we just don't want to do it and not that it's technical impossible or undesirable. > The solution is to buy equipment that support both ascii and > ISO-646, using ascii for programming and ISO-646 for danish > text. Even when stuck with ISO-646 only equipment it is not too > hard to memorize the ISO-646 characters that map into the > bitpatterns recognized by C compilers as {}[]|\. (ISO-646 is > identical to ascii except for {}[]|\ ) Which bit patterns in particular are you talking about? Not trigraphs I presume. Whitesmiths (and others) invented digraphs for this some years ago for other alphabets but none has a solution that also handled ISO-646. Hence, ANSI invented trigraphs from scratch chosing characters that graphically resembled their meaning. If you feel you have constructive input to the Danish Standards Assoc. I encourage you to contact Keld and voice your opinions. Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
keld@freja.diku.dk (Keld J|rn Simonsen) (04/26/89)
rex@aussie.UUCP (Rex Jaeschke) writes: >The primary objection at this stage comes from the Danes who want >more readable trigraphs (don't we all.) However, all forms of >their proposal have been soundly rejected by ANSI for 3-4 meetings now >and last week in Seattle, even ISO voted not to back them on this >issue. The problem stems from the fact that they use the ISO-646 >character set which, as you may know, doesn't have characters such as >[, ], {, }, #, |, and \. They also wanted an infix operator ! as an >alternate to subscripting such that a!b == a[b]. There are technical >problems they have not solved (for example, how to write a[]) and this >is the main reason the proposal has been rejected. Also, their >proposal is in addition to the existing trigraphs, NOT instead of so >it adds more baggage. Some comments: I have only seen one real technical reply to the Danish proposal, and that was the response from the third public review on the ANSI draft (p 71). Else I have only seen remarks like "Do we want to discuss the alternate trigraphs issue: straw vote: 40 no, 0 yes". Also it has never been treated by X3J11 as a request from ISO WG14, although it has been adopted by WG14 and WG14 has requested X3J11 that this was a very important thing to accomplish. X3J11 not only has the responsibility of ANSI to do the standard, but also have the technical responsibility of the ISO standard. I think the reason that ISO WG14 backed out on the proposal was that they were tired after asking X3J11 several times to accomodate the proposal, and ANSI resisted every time. The technical problems with the proposal seems to be solvable, according to the formal reply on the third public review by X3J11 itself. At the Seattle meeting a problem was arisen with A[], which already was described in the proposal paper (notation A!; for A[]; ) and another problem with ambiguity with the non-operator was also proposed solved by me by parenthenses, that is higher precedence for the postfix !-operator. I would say if ANSI had meant to give the proposal a chance they would have contacted us to solve the technical problems, this furthermore as they have been asked by the ISO SC22 advisory group in a resolution to do every effort to accomodate the WG14 requests. X3J11's decision on this ISO WG14 proposal (WG14 had changed the Danish proposal to make it acceptable to WG14) was that it would not at all consider a change to the ANSI standard for this proposal. I would not regard that as a try to "do every effort to accomodate WG14's requests". Another thing that X3J11 let down was to follow the guidelines for syncronisation of ANSI/ISO standardisation, which has been proposed by ANSI itself and to the best of my knowledge been approved by ISO SC22. The guidelines would mean that the ANSI C standard would be delayed till ISO had got a DP successfully thru the international ballot. To me it seems like non-US input have had a very hard time getting thru X3J11. Bill Plaugers multibyte support got thru, but this was also written by one of the most prominent members of X3J11, holding both the secretary, the international rep and the convenor position of WG14. Neither the British nor the Danish proposals have got a fair treatment by X3J11, in my humble opinion. Keld Simonsen
henry@utzoo.uucp (Henry Spencer) (04/26/89)
In article <39709@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >>Just how much input have foreign countries had in the _A_NSI spec? > >... In general, >there doesn't seem to be a restriction against foreign members of ANSI >committees. We have several Japanese and European members in X3J13. X3J11 had/has a number of foreign members, and got a number of foreign comments (mine among them) during the public-comment periods. In fact, if you look at the public-comment submissions, you find a remarkably high Canadian content in particular. Why are you USAnians so uninterested in your own standards? :-) :-) As to the general issue of "why?": it is in everyone's interest for standards to be (a) as good as possible, and (b) as widely applicable as possible. Item (a) makes it undesirable to reject potentially valuable contributions because of artificial political boundaries. Item (b) makes it positively desirable to get input from outside the US, especially from non-English-speaking countries (Canada half qualifies, n'est-ce pas?), to avoid the alternative of having several incompatible standards. (As witness the ASCII/ISO646/trigraphs mess that has arisen out of slightly incompatible character sets.) -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (04/26/89)
In article <39709@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >... many of the members are multinational corporations, and it >would be expensive for them to have to produce different versions of >their products for domestic and foreign use. They can generally be >convinced when national security is used as the excuse (e.g. the >prohibition against exporting Unix crypt()), but they'll balk at >childish not-invented-here syndrome... As opposed to the prohibition on exporting crypt(1), which is childish invented-here syndrome... :-) :-) :-) -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
kjell@saturn.ucsc.edu (Kjell Post) (04/26/89)
In article <4617@freja.diku.dk> njk@freja.diku.dk (Niels J|rgen Kruse) writes: >The solution is to buy equipment that support both ascii and >ISO-646, using ascii for programming and ISO-646 for danish >text. Even when stuck with ISO-646 only equipment it is not too I agree!!! Almost every terminal/printer have a switch for flipping between character sets. I can't see any reason to use these ugly trigraphs. Back in Sweden, the Pascal compilers allowed you to use (. and .) instead of [ ] but it was NEVER used by ANYONE. I admit I haven't read the draft so if I've missed some intended purpose, please let me know. --Kjell -- For athletes and programmers, ! Kjell E. Post a woman is the end of their career. ! CIS/CE ! University of California, Santa Cruz -- A.Wickberg ! Email: kjell@saturn.ucsc.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/26/89)
In article <1989Apr26.023157.18763@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >As opposed to the prohibition on exporting crypt(1), which is childish >invented-here syndrome... :-) :-) :-) As I recall, crypt(1 not 3) -- which is of no national security significance since it discloses no secrets and any competent cryptographic agency can readily break it (indeed there is a "crypt breaker's workbench" in the net archives!) -- was removed from recent "international" releases of UNIX by AT&T on their own initiative, to avoid possible hassles, not at the request of any government agency (Commerce Dept. would most likely be the one, and naturally they don't have in-house cryptographic expertise but rely on guidance from other agencies). (How's that for a sentence?) In other words, nearly everybody agrees that it was silly. (Even more so since the code was distributed internationally previously!) But what do you expect when bureaucrats and lawyers are involved?
amanda@iesd.dk (Per Abrahamsen) (04/26/89)
In article <9.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: > Which bit patterns in particular are you talking about? The following "bit patterns" from ascii(7): | 91 [ | 92 \ | 93 ] |123 { |124 | |125 } They look different on an ISO-646 terminal, but the C compiler don't know this. Of course, a danish C compiler might allow the programmer to use [\]{|} as letters in identifiers, and require him to use trigraphs for braces, brackets etc. -- Per Abrahamsen, amanda@iesd.dk, {...}!mcvax!diku!iesd!amanda
rex@aussie.UUCP (Rex Jaeschke) (04/26/89)
> Also it has never been treated by X3J11 as a > request from ISO WG14, although it has been adopted by WG14 > and WG14 has requested X3J11 that this was a very important thing > to accomplish. Absolutely not true. You may recall I spent quite some time with you in Amsterdam at the drafting committee meeting wording your proposal at ACE that evening so it could appear in the ISO minutes and be sumbitted to X3J11. At the next X3J11 meeting it was definitely discussed at X3J11 and presented by Plauger on behalf of ISO. Now I understand that the X3J11 minutes were "light" in this area causing some ISO people to believe the topic was not given a hearing (and that's unfortunate.) Let me assure you, it did. It also addressed the issue again after the London ISO meeting, and again, rejected it. > I think the reason that ISO WG14 backed out on > the proposal was that they were tired after asking X3J11 several times > to accomodate the proposal, and ANSI resisted every time. Why would ISO back down if they really supported you? Actually, I don't recall that Denmark has ever had any direct support for their proposal from other countries. The Dutch and Finnish were not particularly interested and neither was France. However, most of them were not opposed to having the proposal presented to ANSI as part of an ISO report. > I would say if ANSI had meant to give the proposal a chance > they would have contacted us to solve the technical problems, If you are trying to sell an idea to someone and they have absolutely nothing to gain from it and it will cost them extra work to implement, then the burden is on you to show that it can be done, and done elegantly within the spirit of the language, and just exactly what the cost of doing it is. All those not interested in it will likely look for holes in your proposal so they can discard it. That's life. > To me it seems like non-US input have had a very hard time getting thru > X3J11. > Neither the British nor the Danish proposals > have got a fair treatment by X3J11, in my humble opinion. There is plenty of evidence that ANSI has been responsive to non-US input, and I don't just mean Canadian. Considering that most of ANSI voting members are implementers and the whole area of trigraphs is something most of them don't care a hoot about at all, give them some credit in that they even supported the addition of the original trigraph proposal - they didn't even have to do that. That was a significant international goodwill gesture, make no mistake. I don't like trigraphs but I supported their addition. Also, keep in mind that there are plenty of good US proposals that never made it. Tom MAcDonalds numerous proposals on complex arithmetic, for example. I suggest that there is a bigger need for that and parallel/vector support than there is for trigraphs. So, what we're doing via the NCEG is to work on an extensions package and publish it as a technical bulletin. BTW, the views expressed in this forum re ANSO/ISO are entirely my own and do not necessarily replect X3J11's opinion as a group. Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
paul@hcr.UUCP (Paul Jackson) (04/26/89)
In article <6.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP writes: > At this stage, the >chances of having identical ANSI and ISO standards is very very good. >(I have also been a member of X3J11 since December 1984.) I was at the Seattle ISO meeting as the Canadian representative, and unfortunately the above is a little optimistic. The Danish are quite unhappy, mostly because of trigraphs but also because they (or at least their representative) seem to feel that the X3J11 committee hasn't cooperated closely enough with the ISO body. They certainly stated their position as being opposed to the adoption of the standard and they were planning to try and rally the other Scandinavian countries to their support. The British are also very iffy. A compromise position was reached at the meeting that the representative thought he could sell to the British WG14 group. Unfortunately, that group is only an advisory group to the SC22 body who casts the vote, and the British representative was a lot less certain that he could convince them. It is my understanding (I'm not completely sure on all this), that if there are more than 2 negative votes internationally then the ISO will NOT adopt the Ansi draft as the international standard (ie, they vote by a form of modified consensus). In that case, the standards will be different OR there will not be an ISO standard. I personally feel that the Canadian interest would be better served by having NO ISO standard as opposed to having a different standard than the ANSI standard (this is clearly NOT an official Canadian position). -- Paul Jackson HCR Corporation Toronto, Ontario (utzoo|utcsri)!hcr!paul
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/27/89)
In article <4623@freja.diku.dk> keld@freja.diku.dk (Keld J|rn Simonsen) writes: >Some comments: I have only seen one real technical reply to the >Danish proposal, and that was the response from the third public >review on the ANSI draft (p 71). I don't think that should be dismissed lightly. The proposal was thoroughly discussed by X3J11 as part of the third public review, and similar proposals had been discussed previously. The response document on p. 71 spells out X3J11's reasoning in considerable detail. If there is a flaw in the logic, it should be pointed out. I missed most of the debate on this in Seattle due to having to be in two places at once, but nobody has pointed out to me any error in our previous reasoning. >Else I have only seen remarks like "Do we want to discuss the >alternate trigraphs issue: straw vote: 40 no, 0 yes". You weren't present for previous discussions, but I was, and they did occupy a significant amount of X3J11 committee time. If the official minutes don't reflect that, then they're misleading. However, upon looking up the description in the minutes (document number X3J11/88-155, pp. 5-6) I see considerable evidence of the discussion, including specific points raised by Plum and Gwyn, who were by no means the only participants in the discussion. As to "straw vote" etc., here is a direct quote from 88-155, just after several paragraphs summarizing the digraph discussion: To avoid any bias against making the first substantive change, Brodie suggested that the Committee defer a full vote until all substantive issues had been aired. There was no objection. Straw vote: 0 accept digraphs a la 88-134 40 no Our procedure, which was also followed in other X3J11 meetings, was to form a "committee of the whole" for discussion of issues and to take non-binding votes on issues in order to determine the sense of the committee. We termed these "straw votes" since they were basically just polls to discover whether there was strong support for each proposed change to the Draft Standard. Near the end of the meeting, we then resumed "full committee deliberations" and ratified the decisions indicated by the earlier straw votes. This procedure seemed necessary to avoid continual arguments about whether each change was substantive or editorial, as well as to assure that the issues were considered on their merits instead of merely as threats to timely standardization (although that too was a valid concern). Thus, the label "straw vote" is not an indication of the amount of serious consideration given to an issue. X3J11 treated your proposal quite seriously, but in the end did not think that it should be adopted. >Also it has never been treated by X3J11 as a request from ISO WG14, That is simply false. From the same minutes: Plauger presented several papers (88-132, 88-134, 88-108) concerning issues of international concern. He identified as most critical the request from WG14, on behalf of Denmark, to add more readable digraphs to the Standard. ... Plauger reminded the Committee that Denmark felt sufficiently strongly about this capability that they were willing to press for an ISO standard that differs from ANSI, if X3J11 doesn't adopt it. >X3J11 not only has the responsibility of ANSI to do the standard, >but also have the technical responsibility of the ISO standard. Yes, that's true. Technical responsibility means, among other things, judging the technical merits of proposals. X3J11 has many times adopted changes to the Draft Standard that remedied perceived technical deficiencies. I believe that X3J11 did not think that the digraph proposal was a suitable remedy for a perceived technical deficiency. The official response document explained the Committee position on this issue. >The technical problems with the proposal seems to be solvable, Very likely they are. However, in order to work on fixing the problems in the proposal X3J11 would first have to be convinced of the necessity for making any change at all in this area. Clearly, they have not been convinced that there is a necessity. >Another thing that X3J11 let down was to follow the guidelines >for syncronisation of ANSI/ISO standardisation, which has been >proposed by ANSI itself and to the best of my knowledge been >approved by ISO SC22. The guidelines would mean that the ANSI C >standard would be delayed till ISO had got a DP successfully >thru the international ballot. From what you have presented about this "synchronization", I gather that it is up to ANSI to decide whether to delay ratification of the proposed Standard until ISO etc. X3J11 does not control ANSI, nor does ANSI control X3J11. So far as the X3J11 Technical Committee is concerned, our job was to prepare the proposed Draft Standard, and after evaluating public comments to submit a final revision to CBEMA X3 for a ballot, which is what we did. ANSI can delay ratification of the X3-approved proposed Standard, and may even require further work to resolve ISO differences if necessary. Since WG14 voted explicitly to adopt the same draft for the ISO standard, there should be no such differences. >To me it seems like non-US input have had a very hard time getting >thru X3J11. If this is true, it must be due to problems in the "official channels" of communication, which are not under X3J11's control. X3J11 has considered numerous letters from outside the USA: Canada, Japan, and the UK come immediately to mind, but suggestions from other countries were also received. Every suggestion received by X3J11, even those not officially submitted as part of the public review process, was considered, and several of them resulted in improvements to the proposed Standard. I know this because I edited the X3J11 responses to all the suggestions as published in our four response documents (you haven't seen the fourth one yet, it's our response to the letter from Hansberry). >Bill Plaugers multibyte support got thru, but this was >also written by one of the most prominent members of X3J11, ... Bill is certainly one of X3J11's prominent members, but the committee frequently decided against his position on issues. Decisions were almost always made primarily on technical grounds, although I think there were a few minor exceptions. Although it helped to have an advocate on the committee, many suggestions were adopted because of persuasive arguments, not because some prominent committee member pushed for adoption. It happens that I was author of the major alternative proposal to multibyte characters, namely the "short char" proposal. (The Japanese had suggested a similar "long char" solution, but mine did not require additional library routines.) I felt about the fate of my proposal much as you must feel about the fate of yours. I too think that my proposal should have been adopted by the Committee, but they were not convinced. There has to be room for "reasonable people to disagree" on these issues. So long as my proposal was given a fair hearing, which I believe was the case, I simply have to accept the decision. >Neither the British nor the Danish proposals have got a fair >treatment by X3J11, in my humble opinion. The British "undefined behavior" proposal was accepted in principle, with details to be worked out early during the future "interpretations" phase of X3J11. It was agreed that their concerns were not sufficient to further delay adoption of the proposed Standard as it now stands (they did not involve technical errors); the British WG14 representative indicated that this was acceptable to him, and WG14 so voted in Seattle. I'm sorry that you don't feel the digraph proposal received a fair hearing, but my experience (having been involved in the debate as well as in the formulation of the official response) suggests that it did receive a fair hearing, but simply was not adopted because the Committee did not agree with it. I'm sure it must seem to you that no reasonable person could possibly disagree with your reasoning if they would only give it fair consideration, but I'm telling you that that's exactly what happened, just as it happened with my short-char proposal. DISCLAIMER: The above is all my personal opinion and should not be construed as an official statement from X3J11. I hope I have shed more light than heat upon the subject.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/27/89)
In article <12.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: >Considering that most of ANSI voting members are implementers and the >whole area of trigraphs is something most of them don't care a hoot about ... Hey, trigraphs are too an issue for implementors; they have to support them. (And I'm not even an implementor, at least not most of the time.) Trigraphs are well discussed in the Rationale document, and interested parties should refer to it to see why they were invented. I disagree with some of the Rationale (namely the part that implies that we expect people to actually code using trigraphs), but basically it's on the mark.
bill@twwells.uucp (T. William Wells) (04/27/89)
In article <4623@freja.diku.dk> keld@freja.diku.dk (Keld J|rn Simonsen) writes:
: The technical problems with the proposal seems to be solvable,
: according to the formal reply on the third public review
: by X3J11 itself. At the Seattle meeting a problem was arisen
: with A[], which already was described in the proposal paper
: (notation A!; for A[]; ) and another problem with ambiguity
: with the non-operator was also proposed solved by me by
: parenthenses, that is higher precedence for the postfix !-operator.
That something can be done is not sufficient reason to do it.
What technical advantage would be had by those proposals? Don't
answer with esthetic arguments; no one is likely to take them
seriously. I know I won't.
: Another thing that X3J11 let down was to follow the guidelines
: for syncronisation of ANSI/ISO standardisation, which has been
: proposed by ANSI itself and to the best of my knowledge been
: approved by ISO SC22. The guidelines would mean that the ANSI C
: standard would be delayed till ISO had got a DP successfully
: thru the international ballot.
If there was any real delay in the standard, for what is essentially
a bureaucratic reason, zillions of people would have screamed, me
among them. I doubt that strict conformance to those guidelines is a
sufficient reason to inconvenience the rest of the C world.
---
Bill { uunet | novavax } !twwells!billrbutterworth@watmath.waterloo.edu (Ray Butterworth) (04/27/89)
This is getting really interesting. Because some members of ISO don't like trigraphs we might end up with an ISO standard that is different from the ANSI standard. Just imagine if the only difference is the existence of trigraphs. We'd have an iinntteerrnnaattiioonnaall standard wwiitthhoouutt trigraphs (and why not, as many people have pointed out many times, they aren't really necessary) and an AAmmeerriiccaann standard wwiitthh trigraphs. The Americans obviously must have a greater need for trigraphs than anyone else if they are willing to let this happen.
rex@aussie.UUCP (Rex Jaeschke) (04/28/89)
> In article <6.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP writes: > > At this stage, the > >chances of having identical ANSI and ISO standards is very very good. > >(I have also been a member of X3J11 since December 1984.) > > I was at the Seattle ISO meeting as the Canadian representative, and > unfortunately the above is a little optimistic. It wasn't completely wishful thinking - I remain very optimistic despit what went on in Seattle. > It is my understanding (I'm not completely sure on all this), that > if there are more than 2 negative votes internationally then the ISO will NOT > adopt the Ansi draft as the international standard (ie, they vote by a form > of modified consensus). In that case, the standards will be different OR > there will not be an ISO standard. That's how Plauger explained it to me. It is extremely likely that X3 will accept the draft ANSI standard as is within about 3 months. Once that happens, ISO are out on a limb in terms of having something different. Then THEY have to do the extra technical work needed to make a different ISO standard. If the two differ, it is still possible (likely?) that US Govt. validation will be based on ANSI only since the ISO extensions are not needed for US govt purposes. Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
rex@aussie.UUCP (Rex Jaeschke) (04/28/89)
> >Considering that most of ANSI voting members are implementers and the > >whole area of trigraphs is something most of them don't care a hoot about ... > > Hey, trigraphs are too an issue for implementors; they have to support > them. (And I'm not even an implementor, at least not most of the time.) Sure they care 'cos they have to implement them. What I meant was, that most of them are not interested in selling to the marketplaces where trigraphs are needed. As such they would rather trigraphs not exist at all. They will begrudgingly implement them but not be too enthusiastic about it. They will even ship product with __STDC__ set to 1 without having trigraph support (as vendors are already doing). Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/29/89)
In article <25597@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >Just imagine if the only difference is the existence of trigraphs. But that's not one of the likely outcomes.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/29/89)
In article <15.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: >They will even ship product with __STDC__ set to >1 without having trigraph support (as vendors are already doing). That's the first I've heard of this. How about naming such vendors so we can avoid buying their product. Who knows what else they've decided to second-guess in the Standard.
rex@aussie.UUCP (Rex Jaeschke) (04/30/89)
> From: gwyn@smoke.BRL.MIL (Doug Gwyn) > > In article <15.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: > >They will even ship product with __STDC__ set to > >1 without having trigraph support (as vendors are already doing). > > That's the first I've heard of this. How about naming such vendors > so we can avoid buying their product. Who knows what else they've > decided to second-guess in the Standard. Zortec's C++ V1.07c. I presume it's the most recent release since I was recently shipped it for review. It says __STDC__ == 1 and won't hand ??= as #. I'm sure it is missing numerous other things too - that's what my review will find out since it's an ANSI-conformance review for my Programmers Journal column. Rex ---------------------------------------------------------------------------- Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ----------------------------------------------------------------------------
diamond@diamond.csl.sony.junet (Norman Diamond) (05/01/89)
In article <15.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: >>>They will even ship product with __STDC__ set to >>>1 without having trigraph support (as vendors are already doing). From: gwyn@smoke.BRL.MIL (Doug Gwyn) >> That's the first I've heard of this. How about naming such vendors >> so we can avoid buying their product. Who knows what else they've >> decided to second-guess in the Standard. In article <17.UUL1.3#5077@aussie.UUCP> rex@aussie.UUCP (Rex Jaeschke) writes: >Zortec's C++ V1.07c. I presume it's the most recent release since I >was recently shipped it for review. It says __STDC__ == 1 and won't >hand ??= as #. Well, it's hard to say which is more strange: (1) A C++ compiler which claims ANSI-C compatibility; or (2) Someone checking for ANSI-C compatibility in a C++ compiler. Even some things that were supposed to be pure upgrades to C++ still break valid C programs. For example, I had learned to use typedef in a way that helps make code self-documenting (though not popular with C programmers), e.g.: typedef struct my_stuff_t *my_stuff_ptr_t; typedef struct her_stuff_t *her_stuff_ptr_t; typedef struct my_stuff_t { /* my stuff */ her_stuff_ptr_t my_reference; } my_stuff_t; /* this line broken by C++ */ /* (only a warning in g++) */ my_stuff_t joes_stuff; Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?