From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1025b4,959627a08fbc77c5 X-Google-Attributes: gid1025b4,public X-Google-Thread: 103376,30a9bb3017fa58dd X-Google-Attributes: gid103376,public From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: GNAT versions ( was :Ada compiler for PC?) Date: 1999/05/17 Message-ID: #1/1 X-Deja-AN: 479193253 References: <7g5ju3$qpb$1@nnrp1.dejanews.com> <7gbjhg$s98$1@rtl.cygnus.com> X-Trace: typhoon.nyu.edu 926980746 128.122.140.194 (Mon, 17 May 1999 18:39:06 EDT) Organization: New York University Ultracomputer Research Lab NNTP-Posting-Date: Mon, 17 May 1999 18:39:06 EDT Newsgroups: comp.lang.ada,gnu.misc.discuss Date: 1999-05-17T00:00:00+00:00 List-Id: In article <7gbjhg$s98$1@rtl.cygnus.com> bothner@cygnus.com (Per Bothner) writes: >However, there was at least the perception that in a few case he made some >questionable decisions based on concerns about GNAT. For example, >C++ exception handling was delayed because Kenner had his own ideas >as to how it "ought" to be done. Well, since Mike Stump, the author of the delayed code in question, didn't see it as an issue of concerns with GNAT either then or now, I'm not sure what you mean by "perception". I want to add to some of the comments that Robert Dewar made later in this thread and to complete the history here. A long time ago (perhaps 1992), there was a set of meetings held at NYU on the topic of language-independent exception handling design. At those meetings were folks representing Ada, C++, and Modula. We spent a long time trying to solve the problem of how to implement a language- and machine-independent exception handling model, which was and is a very hard technical problem. These discussions continued on an EH list for a while after that. Subsequently, Robert wrote up a document that contained a draft specification for such a system, which was meant as a basis for implementation. Clearly, once implementation started, we would expect this specification to have to be updated as people learned more about the process. But nobody seemed to have time to do the implementation. Then an exception handling mechanism for GCC "suddenly" appeared *without* there being any revisions or details added to this document. One of the critical things I needed to know was whether or not the basic mechanism embodied in this implementation was or was not based on this document and, if it was, what modifications were made to those details in the process. This is a documentation issue and, as Mike correctly points out, was the main source of the dispute between he and I. I wanted to have the code documented, not just at the detailed level, but to have a specification of the basic strategy being used to implement machine- and language-independent exception processing. After a lot of back and forth (lasting at least a year, probably more), RMS and I agreed to install the code and received in return a promise for such documentation to be written. This was a number of years ago and, so far as I know, there has never been an update of the Robert's design document with the details of the particular implementation. With hindsight, clearly what happened should have been avoided. But, like Mike, I'm not sure *how* it could have been avoided. Perhaps we could have done something similar to what EGCS was originally and set up a parallel fork for the exception handling code where people could work on improving and finishing it, but it would stay out of the GCC releases until it was complete and documented. The problem with approach, of course, is that people would want to *use* the code (in both C++ and Ada) and those requirements would essentially cause this code fork to be its own "release" in much the same manner as EGCS was in its early days and divert the already-limited set of testers to testing *two* releases. How to deal with situations like this is, I believe, one of the more critical issues in open software development and I have no solutions to offer: history tells us what *doesn't* work, but I'm unaware of any solutions that do.