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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,67ca96c42837a9ca X-Google-Attributes: gid103376,public From: dewar@gnat.com Subject: Re: Getting GNAT to issue ARM error messages Date: 1999/02/17 Message-ID: <7ad77n$s4v$1@nnrp1.dejanews.com> X-Deja-AN: 445147159 References: <79oj1f$e8p$1@nnrp1.dejanews.com> <1999Feb10.073547.1@eisner> <7a1a9i$2kq$1@nnrp1.dejanews.com> <36C47579.3D0CAFCB@averstar.com> <7a490k$snr$1@plug.news.pipex.net> <7a5b71$d25$1@nnrp1.dejanews.com> <7a7aat$mse$1@plug.news.pipex.net> <7a86hj$ka1$1@nnrp1.dejanews.com> <36C9C0BC.EA9C114E@lmco.com> X-Http-Proxy: 1.0 x1.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Feb 17 01:49:45 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-02-17T00:00:00+00:00 List-Id: In article <36C9C0BC.EA9C114E@lmco.com>, steve quinlan wrote: > I had this same argument with him when I was doing a > compiler trade study (we picked GNAT anyway, but this did > get counted against it). Even if we can't change his > mind, the fact that overwhelmingly users want this seems > like it should move ACT to be more responsive. But they > know best what we need to correct our errors. (;-) Well Steve, you still have not sent in ONE specific suggestion. I actually think almost NO one agrees that ALL messages should have RM references, and in fact it is not at all clear that "overwhelmingly users want this" at all. Most users find the error messages in GNAT to be one of its strong points, and in most trade comparisons that have been done, GNAT comes out ahead on quality of error messages. So I don't think there is by any means general support for including RM references in all messages. Consequently, I think we agree that the idea is to have RM references where they are helpful. Note that Tuck seemed to suggest that he agrees with this as well, even though in the past the Intermetrics front end, following the tradition that I established many years ago in Ada 83 with Ada/Ed, the first compiler to do this, does put RM references in all messages, many of them, in my opinion, and in the opinion of many others, gratuitous (if you have a missing semicolon, it is plain idiotic to give an RM reference, and it does not matter whether or not you are an Ada expert to agree with that :-) Now in the current thread, one of the strong arguers for RM references admitted that he did not know the Ada 95 RM well and had never used GNAT, so could not give any specific examples. Well you have used GNAT, how about making some specific suggestions about error messages where you think a specific RM reference would be helpful. It is striking that we still have never received even ONE such suggestion, and goodness knows we receive loads of suggestions about all sorts of other things! As for using RM terminology, we actually found that the majority of complaints about error messages being obscure (we get many such complaints/suggestions, see one of them below), were to do with the use of less well known RM terms, and we greatly improved the messages (in the opinion of those submitting the reports) by reverting to plain language. For example, an error message that critically depends on knowing what accessibility means is likely to confuse (and just try finding an RM reference to elucidate). Another good example is the case of: procedure q is type r is access all string; m : aliased string (1 .. 3) := "CAT"; z : r := m'access; begin null; end q; Now the error message we used to give was simply: 4. z : r := m'access; | >>> object subtype must statically match designated subtype This uses RM terminology, and the appropriate RM reference would be presumably RM 3.10.2(27) 27 If the designated type of A is tagged, then the type of the view shall be covered by the designated type; if A's designated type is not tagged, then the type of the view shall be the same, and either A's designated subtype shall statically match the nominal subtype of the view, or the designated subtype shall be discriminated and unconstrained; Well I am sure that is a *big* help to someone completely puzzled by the error message. This is incidentally a VERY common case to get confused over, most people have no idea why the above program should be illegal. So we added some warnings (which only come out if you make this error): 3. m : aliased string (1 .. 3) := "CAT"; | >>> warning: aliased object has explicit bounds >>> warning: declare with explicit initialization >>> warning: for use with unconstrained access Now things are much clearer, and the compiler tells you how to fix things. Since we put these warnings in, we have not had one person ask us about this message. That example should I think give a bit better idea of our error message philosophy, which is to give sufficient information for people to fix their programs with a minimum of effort. I personally think that nearly *any* reference to chapter 3 of the RM is likely to be unhelpful -- well of course that is a bit strong, but most of chapter 3 is extremely difficult to follow. I think we can all agree that the main purpose of error messages is to point people quickly to the error they have made and let them fix it. At the same time, hopefully they learn the general principle (note that the warnings above do state the general principle, and they state it in a clear form which you simply cannot find ANYWHERE in the RM. Indeed this particular rule is a consequence of several rather strange (and probably unfortunate) decisions made in the Ada 95 design. Deducing the substance of those warning messages, let alone motivating them, from the RM, is quite a tough job. But anyway the challenge stands, point to particular error messages where an RM reference is useful. I can certainly do so, since we include RM references in quite a number of messages, here are some examples: private function with tagged result must override visible-part function move subprogram to the visible part (RM 3.9.3(10)) exception "..." is declared in generic formal package and therefore cannot appear in handler (RM 11.2(8)) Now how about the "overwhelming majority of users who like RM references" suggest some other useful places to add RM references to GNAT messages, and suggest the actual rule that is helpful. Steve mentions that compiler experts may have trouble coming up with useful messages. I definitely agree, and indeed I think that adding unhelpful RM references is an *instance* of this happening. Someone who understands the RM very well may well see why some apparently irrelevant clause in the RM is indeed the reason for the compiler finding the error, but just remember that even if this is the case, it may still be completely confusing, because the compiler does NOT know what the programmer had in mind. This is just a guessing game. Surely no one thinks that RM references should be supplied when they are unhelpful, and most CERTAINLY no one takes the attitude that RM references are unhelpful in all cases. So there is really no philosophical differences. I am not sure if you trade study unearthed any specific examples where he thought GNAT made the wrong choice of whether or not to include an RM reference, but if so, you sure did not tell us about them :-) You talk about it being "difficult to change my mind", but that is a bit puzzling. What are you trying to change my mind to? To agree that ALL error messages should have RM references? Even Tuck does not seem to believe that :-) To add more RM references? Well that's not a useful goal of itself unless they are useful. To add more useful RM refereces? No problem, I agree that we should add more useful RM references if we can identify them. We have identified those that we felt were most obviously cases where RM references helped. Please help us locate others! Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own