* Getting GNAT to issue ARM error messages @ 1999-02-08 0:00 David Peterson 1999-02-09 0:00 ` robert_dewar 0 siblings, 1 reply; 35+ messages in thread From: David Peterson @ 1999-02-08 0:00 UTC (permalink / raw) Dear All, I'm fairly new to Ada, and hope that this is the right newsgroup in which to post a question specific to the GNU/ACT GNAT compiler ... Can anybody tell me if/how it is possible to make the GNAT Ada compiler issue references to the Ada Reference Manual rather than, or in addition to, the regular error messages issued by the compiler ? I know that other Ada compilers such as Vertix and VADS can do this, and am surprised that the GNAT compiler does not do this by default. If it was a design decision, I'd be interested to hear the rationale behind it. Regards, David Peterson ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-08 0:00 Getting GNAT to issue ARM error messages David Peterson @ 1999-02-09 0:00 ` robert_dewar 1999-02-10 0:00 ` David Peterson 1999-02-10 0:00 ` Tom Moran 0 siblings, 2 replies; 35+ messages in thread From: robert_dewar @ 1999-02-09 0:00 UTC (permalink / raw) In article <F6tqMF.Lz7@syd.csa.com.au>, davidp!nospam!@!nospam!syd.csa.com.au wrote: > Dear All, > > Can anybody tell me if/how it is possible to make the > GNAT Ada compiler issue references to the Ada Reference > Manual rather than, or in addition to, the regular error > messages issued by the compiler ? > I know that other Ada compilers such as Vertix and VADS > can do this Actually the latter are the wrong comparison points, since these are Ada 83 compilers, and in our view the situation with Ada 95 is quite different from Ada 83. We only give Ada 95 RM references in rare cases where they are actually helpful. In our experience, most of the time if a well thought out error message is not clear to a user, then they probably do not have the level of knowledge necessary to benefit from going to the reference manual. We prefer to work on making the error messages as clear as possible to someone who is NOT a language expert and NOT comfortable reading the reference manual. That is the goal. If there are very specific instances where you think an RM reference would be helpful, by all means point them out, but we definitely think that giving RM references on all error messages is useless and annoying: a := xyz; | xyz is undefined is about as clear as you can get, putting in an RM reference to the rather complicated section of the RM that talks about declaring entities and when they are visible is unlikely to help anyone! Generally people have found GNAT error messages to be very clear -- we certainly put a lot of effort into achieving this goal, and we know lots of people who have chosen GNAT for education and other uses of Ada because of its clear messages. We do NOT think that adding RM references would help in the goal of continued improvement of GNAT messages. This is actually an old thread, discussed before. One point here is that if you are used to an Ada 83 compiler, the comparison is a bit of an apples and oranges one, since the Ada 95 RM, in a (successful) attempt to be more precise is definitely much less accessible than the Ada 83 RM to a novice reader. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-09 0:00 ` robert_dewar @ 1999-02-10 0:00 ` David Peterson 1999-02-10 0:00 ` Larry Kilgallen 1999-02-10 0:00 ` dewar 1999-02-10 0:00 ` Tom Moran 1 sibling, 2 replies; 35+ messages in thread From: David Peterson @ 1999-02-10 0:00 UTC (permalink / raw) Robert, Thankyou for your detailed response to my earlier question regarding GNAT. In article <79oj1f$e8p$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes: > In article <F6tqMF.Lz7@syd.csa.com.au>, > davidp!nospam!@!nospam!syd.csa.com.au wrote: > > Dear All, > > > > Can anybody tell me if/how it is possible to make the > > GNAT Ada compiler issue references to the Ada Reference > > Manual rather than, or in addition to, the regular error > > messages issued by the compiler ? > > > I know that other Ada compilers such as Vertix and VADS > > can do this > > Actually the latter are the wrong comparison points, since > these are Ada 83 compilers, and in our view the situation > with Ada 95 is quite different from Ada 83. > That is an interesting perspective. I have always considered Ada 95 as a superset and extension of Ada 83 (with improvements and fixes), rather than as a *new* language per se. With so much of the language common between the two variants, I didn't consider the comparison of two Ada compilers (one 83, the other 95) on features not related to Ada 95 language issues to be "wrong" or unfair. I was making the comparison on the basis of limited experience with Ada compilers with which I am familiar. > We only give Ada 95 RM references in rare cases where they > are actually helpful. In our experience, most of the time > if a well thought out error message is not clear to a user, > then they probably do not have the level of knowledge > necessary to benefit from going to the reference manual. > Hmmm ... I thought that the rationale should be that if an error message is not clear, you should be able to reference some document to clarify the situation. The solution above assumes that all error messages are clear and well thought out (which may be true!), and that all the required information can be communicated in 1-2 lines of console output (which I find hard to believe). Also, I think that the majority of people developing software in Ada *do* have the intellectual capability and educational background to read the reference manual, which might not be the case in other languages such as C / C++ (a more diverse user base). > We prefer to work on making the error messages as clear as > possible to someone who is NOT a language expert and NOT > comfortable reading the reference manual. That is the goal. > [cut] I certainly accept that, and find GNAT a great compiler to work with. The error messages are clear and concise. However, I do believe that the majority of people developing software in Ada are serious enough programmers to be comfortable reading (or at least attempting to read !) the ARM. > > We do NOT think that adding RM references would help in > the goal of continued improvement of GNAT messages. > > My only comment would be that the addition of a switch or option to toggle the issuing of ARM references in addition to the current set of comments would add flexibility. Those that wished to obtain additional information regarding an error could toggle the option, with the compiler responding with the additional information as required. I agree that in general ARM references can clutter up the error output, and that well thought out "plain english" messages are often preferable to ARM text - but surely access to both would be the best solution ? Again, thanks for your time and comments, and for answering my original question regarding the availability of such a feature in GNAT. Just thought I'd add a few comments (above), but I am certainly not inclined to tread old ground over and over, nor to start a "holy war" on the issue of comments in GNAT ! :-) It's a good compiler, and I'll take it as it comes ... Regards, David Peterson ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-10 0:00 ` David Peterson @ 1999-02-10 0:00 ` Larry Kilgallen 1999-02-12 0:00 ` dewar 1999-02-10 0:00 ` dewar 1 sibling, 1 reply; 35+ messages in thread From: Larry Kilgallen @ 1999-02-10 0:00 UTC (permalink / raw) In article <F6xCoB.Cny@syd.csa.com.au>, davidp!nospam!@!nospam!syd.csa.com.au (David Peterson) writes: > In article <79oj1f$e8p$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes: >> In article <F6tqMF.Lz7@syd.csa.com.au>, >> davidp!nospam!@!nospam!syd.csa.com.au wrote: >> > Dear All, >> > >> > Can anybody tell me if/how it is possible to make the >> > GNAT Ada compiler issue references to the Ada Reference >> > Manual rather than, or in addition to, the regular error >> > messages issued by the compiler ? >> >> > I know that other Ada compilers such as Vertix and VADS >> > can do this >> >> Actually the latter are the wrong comparison points, since >> these are Ada 83 compilers, and in our view the situation >> with Ada 95 is quite different from Ada 83. >> > > That is an interesting perspective. I have always considered Ada 95 as a > superset and extension of Ada 83 (with improvements and fixes), rather than > as a *new* language per se. With so much of the language common between the > two variants, I didn't consider the comparison of two Ada compilers (one 83, > the other 95) on features not related to Ada 95 language issues to be "wrong" or > unfair. Robert's point is not that the two generations of the Ada language are so different, but that the Reference Manuals for those are so different. While a compiler referring a newcomer to a page in the Ada83 reference manual is quite helpful, a compiler referring a newcomer to a page in the Ada95 reference manual could lead to confusion because of the way that book is written. Larry Kilgallen ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-10 0:00 ` Larry Kilgallen @ 1999-02-12 0:00 ` dewar 1999-02-12 0:00 ` Tucker Taft 0 siblings, 1 reply; 35+ messages in thread From: dewar @ 1999-02-12 0:00 UTC (permalink / raw) In article <1999Feb10.073547.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > A compiler referring a > newcomer to a page in the Ada95 reference manual could > lead to confusion because of the way that book is > written. And just to clarify what Larry wrote above, this is not in any way a criticism of the ADa 95 RM, just a comment on its different stylistic approach. Clarity for non-experts and precision for experts are often opposing goals. There are several factors in this opposition: 1. Precision for experts usually requires a more formal style that is less accessible for non-experts. 2. Precision requires considering marginal cases carefully and thoroughly that may confuse non-experts. 3. Redundancy, that is so often helpful in explaining things to non-experts, is a menace in a precise definition, it can only lead to self-contradiction, and adds nothing. 4. In a formal definition, precise terminology, and the style of depending on that terminology is an important tool, but it can often confuse (an example: how many non-expert users immediately understand that a generic package is not a package, so a rule that applies to packages does not [necessarily] apply to generic packages). The viewpoint of the designers of Ada 95 was that the Ada 83 reference manual was insufficiently precise, and that a more formal, more precise approach was desirable. This was a controversial point, and remains moot (undecided and arguable) in my opinion, but that's a separate issue from the current one (whether to put RM references in messages). One thing to remember here is that I was the one who started the idea of putting RM references in messages. The first compiler to do this was Ada/Ed, and at the time it was an innovation. I am not aware of previous compilers for other languages that contained references to the standard in this manner (after all most programmers for other languages don't even know a standard exists, let alone use it as a standard reference source). Other Ada 83 compilers copied this innovation from Ada/Ed. So I certainly don't oppose the general idea, and indeed the general idea is a good one, *if* the standard is written in an aggressively accessible style. For the Ada 83 standard, I think this criterion was usually met. For the Ada 95 standard, it makes better sense to decide on a case by case basis if an RM reference is helpful. That is why my suggestion is to consider individual examples where an RM reference would be helpful, rather than discussing the point as a general abstract issue. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-12 0:00 ` dewar @ 1999-02-12 0:00 ` Tucker Taft 1999-02-13 0:00 ` Nick Roberts 1999-02-14 0:00 ` robert_dewar 0 siblings, 2 replies; 35+ messages in thread From: Tucker Taft @ 1999-02-12 0:00 UTC (permalink / raw) dewar@gnat.com wrote: > > That is why my suggestion is to consider individual > examples where an RM reference would be helpful, rather > than discussing the point as a general abstract issue. For what it is worth, we took an opposite view with AdaMagic, namely that we try to provide a starting point in the RM for every error message we give (though sometimes we give up). This of course may relate to the fact that we are closely affiliated with the primary authors of the RM ;-). I think it also serves to help the user learn their way around the RM, which is admittedly heavy going. But in any case, vive la difference! Competition is a great way to have various approaches available out there. Certainly GNAT has many excellent error messages, and certainly we have many RM references. Personally, I wish we had the best of both ;-), and I suspect all compilers are in fact converging on better error messages, and judicious use of RM references. Specific user suggestions are always welcome (though instant response is not always possible, unfortunately ;-). > Robert Dewar > Ada Core Technologies -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-12 0:00 ` Tucker Taft @ 1999-02-13 0:00 ` Nick Roberts 1999-02-13 0:00 ` bill 1999-02-14 0:00 ` robert_dewar 1999-02-14 0:00 ` robert_dewar 1 sibling, 2 replies; 35+ messages in thread From: Nick Roberts @ 1999-02-13 0:00 UTC (permalink / raw) It seems to me that Robert Dewar's argument is false, really. He seems to be arguing, in essence, that "because it will help very few users, GNAT should not issue references (to the RM95)". But, surely, if the references would help any user at all (e.g. me), they should be included. How could they do any harm? I would happily agree that such references should (almost) never be considered a replacement for a good error message, but only as a supplement. Incidentally, I intend this more as a suggestion than a criticism. [There are many other things one might suppose a compiler 'ought to do'. Some particularly exacting programmers might fully expect their compiler to quote the RM95 fully, as well as correcting their source code in-place automatically, updating a central repository of programmers' typical mistakes and associated corrections, telling a few jokes, and making the coffee. Criticism is easy.] ------------------------------------------- Nick Roberts "The Prophylactic Didactic" ------------------------------------------- ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-13 0:00 ` Nick Roberts @ 1999-02-13 0:00 ` bill 1999-02-14 0:00 ` robert_dewar 1 sibling, 0 replies; 35+ messages in thread From: bill @ 1999-02-13 0:00 UTC (permalink / raw) In article <7a490k$snr$1@plug.news.pipex.net>, "Nick says... I agree it will be nice to have an RM reference if possible added to the error message. as you said, if someone wants to use it, it is there. Bill ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-13 0:00 ` Nick Roberts 1999-02-13 0:00 ` bill @ 1999-02-14 0:00 ` robert_dewar 1999-02-14 0:00 ` Nick Roberts 1 sibling, 1 reply; 35+ messages in thread From: robert_dewar @ 1999-02-14 0:00 UTC (permalink / raw) In article <7a490k$snr$1@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote: > It seems to me that Robert Dewar's argument is false, > really. He seems to be arguing, in essence, that "because > it will help very few users, GNAT should not issue > references (to the RM95)". But, surely, if the references > would help any user at all (e.g. me), they should be > included. How could they do any harm? First of all, most *certainly* useless RM references have the potential for harm. They can send people off on wild goose chases trying to read (to them) incomprehensible stuff in the RM which just adds confusion to lack of understanding. Once again, the GNAT philosophy is to include the RM reference if and only if it is significantly helpful to the majority of users. We do not find many such examples! The argument that extra information should be supplied in an error message even if it is only useful to a very small number of users is dubious. It would for example equally well justify routinely adding a Russian translation of the message, along with a dubious RM reference. Once again, how about a specific example where an RM reference would help general users. Nick, you are writing an Ada compiler, that means you know the RM backwards and forwards and completely (or you don't have a chance), so you are definitely NOT the kind of person to whom the error messages are targetted (indeed I would think anyone knowing the RM that well would not in any case need RM references :-) Robert Dewar Ada Core Technologis -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-14 0:00 ` robert_dewar @ 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` Jerry van Dijk 1999-02-15 0:00 ` dewar 0 siblings, 2 replies; 35+ messages in thread From: Nick Roberts @ 1999-02-14 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote in message <7a5b71$d25$1@nnrp1.dejanews.com>... [...] |First of all, most *certainly* useless RM references have |the potential for harm. They can send people off on wild |goose chases trying to read (to them) incomprehensible |stuff in the RM which just adds confusion to lack of |understanding. Couldn't you just warn users in the GNAT manual not to follow RM references unless they are Ada experts? (On reflection, I think I can see the answer to this one: how many users read the manual? :-) |Once again, the GNAT philosophy is to include the RM |reference if and only if it is significantly helpful to |the majority of users. | |We do not find many such examples! This might argue for the inclusion of a compiler flag (do as GNAT now does by default, but a flag ('-smartass'?) causes references to be added). But, I'll admit, this might be considered just a tad overkill! |The argument that extra information should be supplied in |an error message even if it is only useful to a very small |number of users is dubious. It would for example equally |well justify routinely adding a Russian translation of the |message, along with a dubious RM reference. A very fair point (badly put :-)[supplying versions of an application program (and in this sense a compiler is an application program) for different (human) languages is hard work but usually a worthy exercise]. Plainly, an error message which ran on for seven pages, and included amusing anecdotes on the relevant subject plus a full horoscope, is unlikely to be what any user would want. |Once again, how about a specific example where an RM |reference would help general users. Well I (personally) have to admit to being stumped by this one, for the simple reason that I am not a GNAT user (yet)[I may become a GNAT user in the future, depending on various things]. I can only report that I myself have always appreciated those compilers which gave out references to the approriate sections in their respective manuals. However, I have to admit that this is not entirely a fair comparison, since the RM95 is not any compiler's manual (or at least shouldn't be), and I guess I am not a typical user anyway. |Nick, you are writing an Ada compiler, that means you know |the RM backwards and forwards and completely (or you don't |have a chance), so you are definitely NOT the kind of |person to whom the error messages are targetted Point accepted. Actually, since I am considering using the well-worn trick of putting all my error messages into a big text file (precisely to make it easier to supply multi-language versions by simply supplying different message files with the same compiler), it occurs to me that supplying different versions of the messages file aimed at different kinds of user could be a practical possibility. The problem with this approach, of course, is that, for most compilers, reading in a big text file every time one compiles is likely to be unacceptably slow. [OTOH I have the luxury: I'm not actually going to worry about compiler speed myself (it's not going to be a commercial program).] However, a variation of this trick might be to factor the messages out into a separate package (or hierarchy) which simply contained a list of constant string declarations. [Does GNAT already do this? I shall be downloading the GNAT sources soon, in fact.] |(indeed I |would think anyone knowing the RM that well would not in |any case need RM references :-) Still studying like crazy ;-) |Robert Dewar |Ada Core Technologis Nick ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-14 0:00 ` Nick Roberts @ 1999-02-15 0:00 ` Jerry van Dijk 1999-02-16 0:00 ` dennison 1999-02-18 0:00 ` Alexy V Khrabrov 1999-02-15 0:00 ` dewar 1 sibling, 2 replies; 35+ messages in thread From: Jerry van Dijk @ 1999-02-15 0:00 UTC (permalink / raw) Nick Roberts (Nick.Roberts@dial.pipex.com) wrote: : This might argue for the inclusion of a compiler flag (do as GNAT now does : by default, but a flag ('-smartass'?) causes references to be added). But, : I'll admit, this might be considered just a tad overkill! Hmmmm, how about overloading the standard gcc '-pedantic' flag... :-) -- -- Jerry van Dijk | Leiden, Holland -- Team Ada | jdijk@acm.org -- see http://stad.dsl.nl/~jvandyk ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-15 0:00 ` Jerry van Dijk @ 1999-02-16 0:00 ` dennison 1999-02-18 0:00 ` Alexy V Khrabrov 1 sibling, 0 replies; 35+ messages in thread From: dennison @ 1999-02-16 0:00 UTC (permalink / raw) In article <F766FJ.8n@jvdsys.stuyts.nl>, jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote: > Nick Roberts (Nick.Roberts@dial.pipex.com) wrote: > > : This might argue for the inclusion of a compiler flag (do as GNAT now does > : by default, but a flag ('-smartass'?) causes references to be added). But, > : I'll admit, this might be considered just a tad overkill! > > Hmmmm, how about overloading the standard gcc '-pedantic' flag... > > :-) I can just see my coworkers' reactions when they see me compiling with "gcc -c -g -pedantic -smartass" :-) T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-15 0:00 ` Jerry van Dijk 1999-02-16 0:00 ` dennison @ 1999-02-18 0:00 ` Alexy V Khrabrov 1 sibling, 0 replies; 35+ messages in thread From: Alexy V Khrabrov @ 1999-02-18 0:00 UTC (permalink / raw) Jerry van Dijk wrote in message ... >Hmmmm, how about overloading the standard gcc '-pedantic' flag... How about making that flag switch the compilation from C++ to Ada? That's what real pedantic is! >-- Jerry van Dijk | Leiden, Holland >-- Team Ada | jdijk@acm.org >-- see http://stad.dsl.nl/~jvandyk Cheers, Alexy ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` Jerry van Dijk @ 1999-02-15 0:00 ` dewar 1999-02-15 0:00 ` Ehud Lamm 1 sibling, 1 reply; 35+ messages in thread From: dewar @ 1999-02-15 0:00 UTC (permalink / raw) In article <7a7aat$mse$1@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote: > Well I (personally) have to admit to being stumped by > this one, for the simple reason that I am not a GNAT user > (yet)[I may become a GNAT user in the future, depending > on various things]. I can only report that I myself have > always appreciated those compilers which gave out > references to the approriate sections in their respective > manuals. However, I have to admit that this is not > entirely a fair comparison, since the RM95 is not any > compiler's manual (or at least shouldn't be) It sure is fascinating for you to argue energetically that adding RM references to messages you have never seen must be a good idea because adding completely different kinds of references to messages from a completely different compiler was helpful to you :-) Actually I nearly always find that people arguing that RM references should be added are arguing from a general sense of what makes common sense to them, rather than actual difficulty in interpreting RM references. The one case I have seen of people arguing for an RM references is experts who are sure they know the language better than GNAT :-) They want an RM reference not to explain the error, but to convince themselves that GNAT is right! So let me state once again the philosophy of GNAT. It is to provide RM references if and only if they seem useful to typical users of the compiler. It is hard to believe that anyone could disagree with this general principle. I can imagine that people might disagree with the judgment in a particular instance, which is why I encourage people to send us examples (to report@gnat.com) where they think an error message is not clear, and to suggest improvements -- people do that all the time, although I must say, no one ever suggested adding a specific RM reference! So Nick, wait till you have some experience with the subject under discussion. Remember that GNAT has put a HUGE amount of effort into generating clear error messages, and handles many error situations far better than other compilers (e.g. proper dealing with the confusion of IS and semicolon in subprogram specs and bodies). You need to use GNAT before you are in a position to make comments on what might or might not make its error messages clearer I think! Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-15 0:00 ` dewar @ 1999-02-15 0:00 ` Ehud Lamm 1999-02-16 0:00 ` steve quinlan 0 siblings, 1 reply; 35+ messages in thread From: Ehud Lamm @ 1999-02-15 0:00 UTC (permalink / raw) On Mon, 15 Feb 1999 dewar@gnat.com wrote: > So let me state once again the philosophy of GNAT. It is > to provide RM references if and only if they seem useful > to typical users of the compiler. > This must be the right approach, and GNAT is a very good compiler - and so are the error messages. However, there's one thing I think important to think about. GNAT is used heaviliy for education. I think a part of really learning Ada, is being able to at list follow the general description of the RM, even if not grasp all the details. In this, I think, the compiler can help - by point the programmer to the RM. It is true that this was much nicer in Ada83, but I still think that in many cases the RM is readable - esp. when you have hypertext referecnes to definitions. I don't think it is a must, and I don't think this is really high priority. However since the discussion got the point where "typical users" were concerned, I'd thought I'd mention this viewpoint. Ehud Lamm mslamm@pluto.mscc.huji.ac.il ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-15 0:00 ` Ehud Lamm @ 1999-02-16 0:00 ` steve quinlan 1999-02-17 0:00 ` Jean-Pierre Rosen ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: steve quinlan @ 1999-02-16 0:00 UTC (permalink / raw) You will never change Robert's mind on this. To my mind the flaw is in thinking that a bunch of Ada experts can determine whether in any given case users (which users?) would find RM references useful. I don't think they can reliably. 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. (;-) Yes, their "hey, dummy, didn't you really mean to .." messages are great. I guess I would even bend on insisting that every error message would need an RM reference. But, at at least the ones where there is no "hey, dummy" message -- if the compiler can't tell me how to fix the error, then it ought to tell me which rule I violated. I think I do remember him agreeing that the error messages should use relevant RM terminology. If they do, then at least a text search of the RM could potentially get you to relevant sections. But, not everyone may have a searchable version. The HTML isn't easily searchable. There is a plain text version which can be searched I guess. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-16 0:00 ` steve quinlan @ 1999-02-17 0:00 ` Jean-Pierre Rosen 1999-02-18 0:00 ` robert_dewar 1999-02-17 0:00 ` Pascal Obry ` (2 subsequent siblings) 3 siblings, 1 reply; 35+ messages in thread From: Jean-Pierre Rosen @ 1999-02-17 0:00 UTC (permalink / raw) steve quinlan a �crit dans le message <36C9C0BC.EA9C114E@lmco.com>... >I think I do remember him agreeing that the error messages should use relevant >RM terminology. THIS is a real issue. For example, my experience is that the term "subtype mark" is very confusing to beginners. I always have to explain that it means "the name of something that is a (sub)type". --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-17 0:00 ` Jean-Pierre Rosen @ 1999-02-18 0:00 ` robert_dewar 1999-02-18 0:00 ` Keith Thompson 0 siblings, 1 reply; 35+ messages in thread From: robert_dewar @ 1999-02-18 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2475 bytes --] In article <7af1kj$pm7$1@platane.wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > steve quinlan a �crit dans le message <36C9C0BC.EA9C114E@lmco.com>... > >I think I do remember him agreeing that the error > >messages should use relevant RM terminology. > THIS is a real issue. For example, my experience is that > the term "subtype mark" is very confusing to beginners. I > always have to explain that it means "the name of > something that is a (sub)type". I actually agree with JPR here, despite Steve's memory of my agreeing to the contrary :-) RM terminology, especially in RM 95, can often be quite confusing, for example the value of a variable does not include the tag, but an error message that depended on the reader knowing the the use of the word "value" excluded the tag, where this was critical to understanding, would likely be confusing. Similarly, a message that depended on the user knowing that the term package excludes generic package could also be confusing. Almost everyone thinks of a package as having a spec and a body, and insisting dogmatically on using package declaration and subprogram declaration in all messages might well be confusing. Another example of terminology that could be confusing is nominal subtype. Actually what is really needed in some of the error situations is not just a magic RM reference, or some magic RM terminology to make things clear, but a long and extended tutorial on a delicate point in the language. I often write these tutorials, both here on CLA, and for our customers! Elaboration issues for example are a particularly tricky area. Our vision for error messages is a tool for which we have a nice name GNOME (GNat Online Message Explanation). The idea is that you click on a message, and you get all kinds of extra stuff, extra explanations, multiple RM references with an explanation of how they apply (RM references without this explanation are typically of limited value), references to the Rationale, the AARM, and even to Ada text books. Unfortunately, the only thing that exists about this tool right now is the name :-) Actually in our experience, relatively few error messages cause significant confusion at this stage (some of them are ones for which we already have RM references, but they still cause confusion!) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-18 0:00 ` robert_dewar @ 1999-02-18 0:00 ` Keith Thompson 1999-02-18 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Keith Thompson @ 1999-02-18 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com writes: > Our vision for error messages is a tool for which we have > a nice name GNOME (GNat Online Message Explanation). The > idea is that you click on a message, and you get all kinds > of extra stuff, extra explanations, multiple RM references > with an explanation of how they apply (RM references > without this explanation are typically of limited value), > references to the Rationale, the AARM, and even to Ada text > books. > > Unfortunately, the only thing that exists about this tool > right now is the name :-) Unfortunately, you don't even have that, unless you really want to confuse people. The name GNOME is already being used for the GNU GUI desktop project. (It's bad enough that the GNU bug tracking system is called GNATS.) -- Keith Thompson (The_Other_Keith) kst@cts.com <*> San Diego, California, USA <http://www.ghoti.net/~kst> Will write code for food. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-18 0:00 ` Keith Thompson @ 1999-02-18 0:00 ` dennison 1999-02-23 0:00 ` Chris Morgan 1999-02-18 0:00 ` David Brown 1999-02-18 0:00 ` robert_dewar 2 siblings, 1 reply; 35+ messages in thread From: dennison @ 1999-02-18 0:00 UTC (permalink / raw) In article <yec1zjny0ri.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > robert_dewar@my-dejanews.com writes: > > Our vision for error messages is a tool for which we have > > a nice name GNOME (GNat Online Message Explanation). The > > idea is that you click on a message, and you get all kinds > > of extra stuff, extra explanations, multiple RM references > > with an explanation of how they apply (RM references > > without this explanation are typically of limited value), > > references to the Rationale, the AARM, and even to Ada text > > books. > > > > Unfortunately, the only thing that exists about this tool > > right now is the name :-) > > Unfortunately, you don't even have that, unless you really want to > confuse people. The name GNOME is already being used for the GNU GUI > desktop project. (It's bad enough that the GNU bug tracking system is > called GNATS.) How about "Integrated GNat Online Blooper Listing Enviroment" (IGNOBLE)? T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-18 0:00 ` dennison @ 1999-02-23 0:00 ` Chris Morgan 0 siblings, 0 replies; 35+ messages in thread From: Chris Morgan @ 1999-02-23 0:00 UTC (permalink / raw) dennison@telepath.com writes: > How about "Integrated GNat Online Blooper Listing Enviroment" (IGNOBLE)? In that case the tool which only gave you RM references would be the Integrated GNat Official RANT. -- Chris Morgan <mihalis at ix.netcom.com http://mihalis.net ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-18 0:00 ` Keith Thompson 1999-02-18 0:00 ` dennison @ 1999-02-18 0:00 ` David Brown 1999-02-18 0:00 ` robert_dewar 2 siblings, 0 replies; 35+ messages in thread From: David Brown @ 1999-02-18 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > robert_dewar@my-dejanews.com writes: > > a nice name GNOME (GNat Online Message Explanation). The > > > > Unfortunately, the only thing that exists about this tool > > right now is the name :-) > > Unfortunately, you don't even have that, unless you really want to > confuse people. The name GNOME is already being used for the GNU GUI > desktop project. (It's bad enough that the GNU bug tracking system is > called GNATS.) There's also GLADE and GLADE. There's the GNAT Library for Ada Distributed Execution. GLADE is also a GUI builder program being developed for Gtk+. What makes it even more exciting is that the GUI GLADE is getting support for Ada as well. So I want GNOME running under GNOME developed with GLADE and using GLADE to get the information. Whew. Dave Brown dlbrown@acm.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-18 0:00 ` Keith Thompson 1999-02-18 0:00 ` dennison 1999-02-18 0:00 ` David Brown @ 1999-02-18 0:00 ` robert_dewar 2 siblings, 0 replies; 35+ messages in thread From: robert_dewar @ 1999-02-18 0:00 UTC (permalink / raw) In article <yec1zjny0ri.fsf@king.cts.com>, > Unfortunately, you don't even have that, unless you > really want to confuse people. The name GNOME is already > being used for the GNU GUI desktop project. (It's bad > enough that the GNU bug tracking system is called GNATS.) Ada folks can handle a bit of overloading :-) Note that we have had zero trouble in practice from the GNAT/GNATS clash (we were there first on that name, but no big deal!) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-16 0:00 ` steve quinlan 1999-02-17 0:00 ` Jean-Pierre Rosen @ 1999-02-17 0:00 ` Pascal Obry 1999-02-17 0:00 ` Steve Whalen 1999-02-17 0:00 ` dewar 3 siblings, 0 replies; 35+ messages in thread From: Pascal Obry @ 1999-02-17 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 752 bytes --] steve quinlan a �crit dans le message <36C9C0BC.EA9C114E@lmco.com>... >You will never change Robert's mind on this. To my mind the flaw is in >thinking that a bunch of Ada experts can determine whether in any given case >users (which users?) would find RM references useful. I don't think they can >reliably. > >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. (;-) > The good news is that you can download GNAT sources and add this feature yourself :-) Pascal. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-16 0:00 ` steve quinlan 1999-02-17 0:00 ` Jean-Pierre Rosen 1999-02-17 0:00 ` Pascal Obry @ 1999-02-17 0:00 ` Steve Whalen 1999-02-17 0:00 ` dewar 3 siblings, 0 replies; 35+ messages in thread From: Steve Whalen @ 1999-02-17 0:00 UTC (permalink / raw) steve quinlan <steven.quinlan@lmco.com> wrote: : You will never change Robert's mind on this. To my mind the flaw is in : thinking that a bunch of Ada experts can determine whether in any given case : users (which users?) would find RM references useful. I don't think they can : reliably. [snip] : 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. (;-) [snip] The "fact" that "... overwhelmingly users want this ..."? Speak for yourself. One major reason I would NOT want RM references or other annotations on every error message, is that 80%+ of the time, I just need a brief reminder of what it was that I did that was stupid, or inattentive. Extra verbage would just distract me and slow me down. When I _do_ need help understanding where I did something more seriously wrong, I'd want more than an RM reference. What I'd _wish_ for, is to have the compiler display a carefully researched reference to the _best_ place to learn more about whatever I've gotten wrong. So if the best description of how to do "whatever I'm confused about" is in Prof. Feldman's Ada95 book in chapter XX, I'd _like_ to see a pointer to that book and chapter, or to the Ada83 RM, or a web page, etc. Since what I want does NOT exist, I'm not going to complain about it until I'm willing to do (or fund) the work myself. Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===} ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-16 0:00 ` steve quinlan ` (2 preceding siblings ...) 1999-02-17 0:00 ` Steve Whalen @ 1999-02-17 0:00 ` dewar 1999-02-17 0:00 ` steve quinlan 1999-02-19 0:00 ` Simon Wright 3 siblings, 2 replies; 35+ messages in thread From: dewar @ 1999-02-17 0:00 UTC (permalink / raw) In article <36C9C0BC.EA9C114E@lmco.com>, steve quinlan <steven.quinlan@lmco.com> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-17 0:00 ` dewar @ 1999-02-17 0:00 ` steve quinlan 1999-02-18 0:00 ` robert_dewar 1999-02-19 0:00 ` Simon Wright 1 sibling, 1 reply; 35+ messages in thread From: steve quinlan @ 1999-02-17 0:00 UTC (permalink / raw) Actually, the "statically matching" error message you gave was the one in GNAT at the time I was doing the trade study. My questions to you on that point led to your changing that message, I believe, as well as to the exchange we had at the time about RM references in error messages. Do you recall this? Is your new message better? Yes. I don't maintain that ONLY RM sections should be given in error messages. Take your best shot at giving the user a way to fix the problem. Then, in parens, you could give the RM reference for non-trivial errors. The problem with adding such references onesy-twosy as you find them to be useful is that no one is using the FUTURE version of the compiler, where that reference will be added after you've decided it would be useful to add it. It's always today's version, where that reference is not there, which is in use. Where I miss such references most is not when I've made some stupid syntax error, or a trivial semantic error, but when I've violated some limitation of Ada, as in the "statically matching" example. Certainly I like to be told what to do to fix my error, but I also would like to understand why I can't do what I thought I could. Maybe there are related issues to that particular error that a reading of the RM on that topic will raise. The rule about statically matching subtypes is such an arcane rule. It's so bizare, that besides upgrading your text error message, I would have argued for putting in an RM reference as well on that one. As long as you were in there changing the message, what could it have hurt to put "RM 3.10.2(27)" in parentheses? I was taken to task by several for claiming that the overwhelming number of users would want full, or nearly full, RM references. Of course, I have no survey to go on. I would love to take one. Anyone who wants to send me their opinion can do so. The question would be : "would you like to see RM section references in compiler error messages (in addition to the BEST, MOST INSTRUCTIVE text message) for non-trivial errors? Trivial would be syntax errors and semantic errors that are almost of the same class as dumb syntax mistakes -- trying to assign a string variable to an integer, stuff like that. I will tablulate and post the results. Of course, it would be an unscientific, self-selecting sample so it will have only an entertainment value, right Robert? (;-) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-17 0:00 ` steve quinlan @ 1999-02-18 0:00 ` robert_dewar 0 siblings, 0 replies; 35+ messages in thread From: robert_dewar @ 1999-02-18 0:00 UTC (permalink / raw) In article <36CAE459.EFE2A7E7@lmco.com>, steve quinlan <steven.quinlan@lmco.com> wrote: > Actually, the "statically matching" error message you > gave was the one in GNAT at the time I was doing the > trade study. My questions to you on that point led to > your changing that message, I believe, as well as to the > exchange we had at the time about RM references in error > messages. Do you recall this? Is your new message > better? Yes. I don't maintain that ONLY RM sections > should be given in error messages. Take your best shot at > giving the user a way to fix the problem. Then, in > parens, you could give the RM reference for non-trivial > errors. But that's the point Steve! I can't figure out a useful RM reference for this particular message, can you? If so please let me know and make the suggestion. We certainly don't want to start putting random RM unhelpful RM references in to make people feel better! So take this particular example as a challenge, find a relevant useful RM reference for this message. > > The problem with adding such references onesy-twosy as > you find them to be useful is that no one is using the > FUTURE version of the compiler, where that reference will > be added after you've decided it would be useful to add > it. No, we add the RM references as we go along (all the current RM references in GNAT are ones that *we* decided are useful -- as I mentioned no one has ever made a suggestion to us to add a specific RM reference). We add an RM reference whenever we think it is useful. If you are asking us to do more than that, you are asking us to add RM references that in our judgment are misleading and unhelpful. That doesn't seem a good idea! > Where I miss such references most is not when I've made > some stupid syntax error, or a trivial semantic error, > but when I've violated some limitation of Ada, as in the > "statically matching" example. Great, so please reveal the RM reference that you missed in this particular case. My feeling here is that the rule about static matching is quite obvious, and referring to the RM reference that says static matching is required would not help you find your error here. The problem is the rather obscure set of rules that together lead to the unexpected fact that this is indeed a surprising case of lack of static matching. > The rule about statically matching subtypes is such an > arcane rule. Actually it is not, it is a perfectly straightforward rule. It is not the requirement for static matching that puzzles people here, since that is an obvious implementation requirement, it is the fact that the two declarations: A : aliased string (1 .. 3) := "abc"; B : aliased string := "abc"; are so radically different in effect. > What could it have hurt to put "RM 3.10.2(27)" > in parentheses? It would hurt because it would not help. I cannot imagine anyone who could not understand the original error message and would be enlightened by this particular reference, since it has nothing at all to do with the real error, which has to do with the difference between the above two error messages. So what you do here for virtually all users is to give them a message they do not understand, and then send them off to the RM to read a paragraph that is not in the least bit useful, but which you have claimed is useful. This is not just annoying but misleading. The error message would be saying, think about the rule in 3.10.2(27), but that will *decrease* the likelihood of finding the error, not increase it I am afraid, since it misdirects the user to the wrong consideration. THe warnings we output are likely to be FAR more useful for a user to understand what is going on. Even for these warnings, it is not at all easy to give a useful RM reference. > It would be an unscientific, self-selecting sample so it > will have only an entertainment value, right Robert? (;-) Well as we have seen there are people who strongly support this even though they are unfamiliar with GNAT and unfamiliar with the RM, so yes, it certainly cannot have more than entertainment value. What is most remarkable in this thread is that not ONE person has made a specific suggestion of a specific RM reference they would like to see added to a message. I find this suprising. Surely if this is such a problem, you must have a case where you have thought, gee! if only GNAT had pointed me to section ???? of the RM, everything would have been clearer. I am really disappointed that this conversation remains at the general level, and has not resulted in even ONE useful constructive suggestion for adding a useful RM reference. Surely there must be some examples. Please send them along to report@gnat.com (and by all means post them here for our instruction :-) P.S. I do not count you sending back to me the suggestion of 3.10.2(27), since this was an example I specifically gave of an RM reference that is obviously NOT helpful. So, how about it, anyone have even ONE example. If you are using Object Ada, surely there is ONE case in which you liked the OA message better because it gave you a useful RM reference. Indeed if it is really true that universal RM references are helpful, any user of these two compilers should have hundreds of such examples at hand! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-17 0:00 ` dewar 1999-02-17 0:00 ` steve quinlan @ 1999-02-19 0:00 ` Simon Wright 1 sibling, 0 replies; 35+ messages in thread From: Simon Wright @ 1999-02-19 0:00 UTC (permalink / raw) dewar@gnat.com writes: > 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. It still takes me more than a few looks at this to determine that you want me to write m : aliased string := "CAT"; because the original has what looks very like explicit initialization! (or is 'explicit' a technical term here?) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-12 0:00 ` Tucker Taft 1999-02-13 0:00 ` Nick Roberts @ 1999-02-14 0:00 ` robert_dewar 1 sibling, 0 replies; 35+ messages in thread From: robert_dewar @ 1999-02-14 0:00 UTC (permalink / raw) In article <36C47579.3D0CAFCB@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Personally, I wish we had > the best of both ;-), and I suspect all compilers are in > fact converging on better error messages, and judicious > use of RM references. Just to be absolutely clear, the GNAT philosophy is to add RM references wherever they are helpful. However, we have not found very many such cases! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-10 0:00 ` David Peterson 1999-02-10 0:00 ` Larry Kilgallen @ 1999-02-10 0:00 ` dewar 1 sibling, 0 replies; 35+ messages in thread From: dewar @ 1999-02-10 0:00 UTC (permalink / raw) In article <F6xCoB.Cny@syd.csa.com.au>, davidp!nospam!@!nospam!syd.csa.com.au wrote: > Also, I think that the majority of people developing > software in Ada *do* have the intellectual capability and > educational background to read the reference manual, > which might not be the case in other languages such as C > C++ (a more diverse > user base). I wonder how intimately familiar you are with the Ada 95 RM. It is a VERY difficult document to read in many places, as I believe is pretty much inevitable if you aim for a very high level of near-formal precision. Try for example to understand the accessibility rules from the RM. Very few people can easily read this material. I speak as someone who *is* very familiar with the Ada 95 RM. Note that for me, the situation is totally different between the Ada 83 and Ada 95 manuals. I often find that people who want RM references are working from Ada 83 experience, and thinking in terms of the Ada 83 reference manual. The kind of people who can successfully read the RM are generally exactly the kind of people for whom the GNAT messages should be immediately sufficient. Yes, there are a few cases of surprising rules and we do use RM references there. As I pointed out in my example, gratuitous RM references, where you take a simple thing like an undefined variable, and add a completely unhelpful RM reference to some of the most complex sections of the RM (the ones on visibility), are simply annoying. Once again in this example: "QXR" is undefined If anyone cannot understand this message, then there is no way that an RM reference is going to enlightent them. The useful constructive thing here is to note *specific* cases of unclear error messages, where additional explanation or additional warnings are required. Let me take an example: procedure z is type r is access integer; a : aliased integer; b : r := a'access; begin null; end; This program is obviously incorrect, and indeed I would expect anyone who is at the level of reading the RM to be able to immediately figure out the error on line 4, even if the compiler just said "ERROR" and nothing more. For the less initiated user, this can be a confusing situation. We used to simply say: 4. b : r := a'access; | >>> result must be general access type But we found many people were confused. For one thing, the terminology "general access type", completely familiar of course to anyone who knows the RM, is likely to be confusing to neophyte users. Now how to fix things? Add an RM reference? I cannot imagine that sending someone who does not understand the above message to the RM could possibly help, and on the contrary, it would tend to just increase the confusion level. The RM is NOT the place to learn Ada! So what did we do in this case, we added an extra message: 4. b : r := a'access; | >>> result must be general access type >>> add "all" to type "r" defined at line 2 and since then, we have got no further confusion queries on this particular message. In some other cases, we do find an RM reference helpful, here is an example: 1. with System; use System; 2. procedure z is 3. g : Address; 4. 5. type x is record 6. m : Integer := 3; 7. end record; 8. 9. y : x; 10. for y'address use g; | >>> invalid address clause for initialized object "y" >>> reference to variable "g" not allowed (RM 13.1(22)) 11. begin 12. null; 13. end; The RM reference here is useful to point out a change from Ada 83 to Ada 95, and a rather obscure rule limiting what address clauses must be accepted. I am certainly not saying that all the error messages in GNAT are perfect, far from it, and we are always putting in a lot of effort to improve them. But the above should illustrate the philosophy behind their formulation. What is useful is not a general recommendation to put in RM references, most of which would indeed be gratuitous, but rather comments (preferably sent to report@gnat.com) about specific messages where you have suggestions for improvements. If you think an RM reference would be helpful, then suggest the specific RM reference that you think would be helpful). Robert Dewar Ada Core Technologies P.S. The point above that people should suggest specific RM references that they think would be helpful is one I have made in this and other forum's often before. It is interesting to note that although we have received hundreds of suggestions for improving error messages, only *one* of these suggestions included a specific RM reference (and indeed it was a helpful suggestion which we followed). -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-09 0:00 ` robert_dewar 1999-02-10 0:00 ` David Peterson @ 1999-02-10 0:00 ` Tom Moran 1999-04-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 35+ messages in thread From: Tom Moran @ 1999-02-10 0:00 UTC (permalink / raw) > the Ada 95 RM, in a (successful) attempt to be >more precise is definitely much less accessible than the >Ada 83 RM to a novice reader. How about references to the Ada 83 RM, then. Or better, a new doc which is stylistically as helpful as the 83 RM, but covers the 95 changes. One problem with any message is that what's crystal clear to the author is not necessarily so to all readers. It's useful in anything to have alternate sources of explanation, not because one is necessarily clearer in all cases, but just because having the same thing described in two different ways decreases the probability that any given reader will still not understand. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-02-10 0:00 ` Tom Moran @ 1999-04-20 0:00 ` Robert Dewar 1999-04-20 0:00 ` Ehud Lamm 0 siblings, 1 reply; 35+ messages in thread From: Robert Dewar @ 1999-04-20 0:00 UTC (permalink / raw) In article <36c1c82d.1234350@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > > the Ada 95 RM, in a (successful) attempt to be > >more precise is definitely much less accessible than the > >Ada 83 RM to a novice reader. > How about references to the Ada 83 RM, then. Or > better, a new doc > which is stylistically as helpful as the 83 RM, but > > covers the 95 changes. Once again, I will say that what is useful is *specific* examples of error messages that illustrate the point you are trying to make, along with suggestions for improvements. It is surprising (and disappointing) that the long thread on this subject a few months ago did not result in even ONE suggestion of a message where an RM reference would be helpful. Indeed several people who contributed to the thread saying they would like RM references had not even seen error messages from GNAT, and in one case they had not even read the Ada 95 RM :-) We do get suggestions on error messages from our users, particularly from students of Martin Carlisle and Michael Feldman (thank you very much for these contributions), and we constantly try to improve error messages in GNAT. If you find an error message you think could be clearer, send along a note to report@gnat.com. Even if you think you are being unreasonable in asking GNAT to do a better job in some particular situation, don't hesitate to suggest, sometimes things that look really hard turn out to have a possible solution, and giving good error messages is something we put a lot of effort into! Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-04-20 0:00 ` Robert Dewar @ 1999-04-20 0:00 ` Ehud Lamm 1999-04-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 35+ messages in thread From: Ehud Lamm @ 1999-04-20 0:00 UTC (permalink / raw) One comment. Robert is aiming Ada students, that try to prodcue code and need the error messages to help thm with errors, and do not need obscure RM references which in many cases do not help. What about students of the RM trying to undersatnd what and where each rule comes from? In these cases an RM or better yet an AARM ref. will be great, don't you think? Let me give you a small example, which I am sure will make me a laughing stock: type help is (a,b); type Var(T:help) is record case T is when a => data:integer; when b => data:float; -- Same name can not appear twice! end case; end record; This will not compile, giving the message: "data" conflicts with declaration in line .. This seesms obvious enough. However now suppose I want to find out where is this rule in the RM. So I start reading 3.8.1 Variant Parts and Discrete Choices, which is quite dense reading... A paragraph, AARM ref. and any other info is always good - if it does NOT obscure the helpful message whcih the compiler should give, and which GNAT most often does give. I think Robert, that you say you have a dream of such a system, so I am not sure how far our views on this are. Ehud Lamm mslamm@pluto.mscc.huji.ac.il ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting GNAT to issue ARM error messages 1999-04-20 0:00 ` Ehud Lamm @ 1999-04-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 35+ messages in thread From: Robert Dewar @ 1999-04-20 0:00 UTC (permalink / raw) > A paragraph, AARM ref. and any other info is always good > - if it does NOT > obscure the helpful message whcih the compiler should > give, and which GNAT most often does give. This is the "do no harm" approach, but for me the criterion is "do good". In other words, your idea that extra information is always useful if it does not obscure things is not good enough for me, I would add the criterion that it must be helpful for a significant number of people. Yes, I see some utility in using the compiler to try to teach people to read the RM, but that is certainly not the intention of the error messages from GNAT. The intention is to point out the error in a clear way that allows you to correct it as easily as possible. The example you chose seems a case where the GNAT error message is indeed completely clear from this point of view. Now if you want to ask the question of where this rule is in the RM, I agree that a tool of some kind that would lead to rules can *sometimes* be useful -- I say sometimes because often the source of the rule is not helpful (of course in this case 3.8.1 is a complete red herring as I assume you meant to make clear by your example). The trouble with putting an RM reference where it is not needed is that it tends to waste people's time by sending them off to look at the RM just to check they understand things. Let's take this case. The proper reference is of course 3.8(9), and the trouble with this reference is that it is too course, only the last sentence is interesting: "The identifiers of all components of a record type shall be distinct" Which provides little or no illumination beyond the original error message. Yes, the reference to the last sentence of 3.8(9) is of value if your specific purpose is to know where a particular rule came from, but the number of people who are interested in this is small. Most people just want to fix their program so it works. Most certainly I would NOT encourage beginning students of Ada to spend time reading chapter three of the RM, and most experts would find the 3.8(9) reference gratuitous in any case. I do think it would be nice to have a tool that gave all sorts of references on error messages to text books, the RM, the AARM, relevant AI's (perhaps the most important source of all in practice), etc. And one day maybe there will be such a tool, but meanwhile, I see little point in adding RM references in the case of simple rules, where the error message clearly implies the rule, and the RM does no more than confirm that the rule exists. The time that RM references are useful, and the time that GNAT includes them, is when the rule involved is obscure. For example: 1. with Text_IO; use Text_IO; 2. procedure z is 3. type a is record b : integer := 2; end record; 4. 5. x : integer; 6. 7. v : a; 8. for v'address use x'address; | >>> warning: implicit initialization of "v" may modify "x", use pragma Import for "v" to suppress initialization (RM B(24)) 10. begin 11. Put_Line ("Hello"); 12. end; Now here is a case of a rule which is a surprise to many expert Ada programmers (especially because it is a new rule in Ada 95, the above program is of course erroneous in Ada 83). It seems quite useful to refer to the RM to explain *why* we suggest adding the pragma Import. The RM paragraph says: 24 The declaration of an imported object shall not include an explicit initialization expression. Default initializations are not performed. Hopefully these two examples make the viewpoint clear. It is incidentally often the case that when people have suggested an RM reference, they choose the wrong place in the RM. They try, as in the message to which this is answering, to suggest some helpful general section in the RM that unfortunately has nothing to do with the case. Let's take another example. Suppose we write: for J in 1 .. 10 loop ... J := J - 1; end loop; The GNAT message is: 4. J := J - 1; | >>> assignment to loop parameter not allowed That's pretty clear. Now let's try to give an RM reference. Well we could reference the note in 5.5(10), but notes are not part of the standard, and so this is a bit dubious (by the way, that note is there in the RM because Robert Dewar complained that otherwise the source of this rule is hard to find!) The real rule is from 3.3(13): 13 An object is either a constant object or a variable object. The value of a constant object cannot be changed between its initialization and its finalization, whereas the value of a variable object can be changed. Similarly, a view of an object is either a constant or a variable. All views of a constant object are constant. A constant view of a variable objectcannot be used to modify the value of the variable. The terms constant and variable by themselves refer to constant and variable views of objects. Here again, we have an overkill problem with a simple paragraph reference, since it is really only the second sentence here that is relevant. Note that if we had pointed to the note, the situation would be even worse, since the note leads to the *whole* of 3.3, even more overkill. Of course we also need 3.3(2,6): 2 All of the following are objects: 6 a loop parameter; And of course 3.3(15,19) 15 Whether a view of an object is constant or variable is determined by the definition of the view. The following (and no others) represent constants: 19 a loop parameter, choice parameter, or entry index; So we could perhaps give as the error message: >>> assignment to loop parameter not allowed (RM 3.3 (2,6,15,19) + 3.3 (13, 2nd sentence) Now this message would indeed be helpful to the small minority (probably a larger minority on CLA) of people who specifically want to answer the question of where this rule comes from in the RM, but to 99% of the users of the compiler, the RM references here add nothing at all since the error message states the rule in a complete and much more accessible form. Indeed the mumbling about views in the above references will confuse all but the most experienced Ada programmers. This seems the most common case. Indeed a simple RM reference is almost never sufficient if your question is "why is this illegal, what exactly is the RM argument that makes this illegal". Instead you need an analysis similar to the above. Basically a theorem must be proved, and the axioms and reasoning for proving the theorem will involve several RM references. As I have said before, I see a definite utility in such a tool for the small number of people who like to nose around the RM (*), but for most people using the compiler this tool would not be helpful, and the priority in GNAT is in working on crafting the error messages so that neither students nor experts have to run away to the RM to understand how to fix their programs :-) Robert Dewar Ada Core Technologies (*) if you are an RM explorer, I strongly suggest carefully reading the AI's that are publicly available. First you will learn interesting things, second reading these is very good training in learning how to become a language lawyer certified as a competent RM reader :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~1999-04-20 0:00 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-08 0:00 Getting GNAT to issue ARM error messages David Peterson 1999-02-09 0:00 ` robert_dewar 1999-02-10 0:00 ` David Peterson 1999-02-10 0:00 ` Larry Kilgallen 1999-02-12 0:00 ` dewar 1999-02-12 0:00 ` Tucker Taft 1999-02-13 0:00 ` Nick Roberts 1999-02-13 0:00 ` bill 1999-02-14 0:00 ` robert_dewar 1999-02-14 0:00 ` Nick Roberts 1999-02-15 0:00 ` Jerry van Dijk 1999-02-16 0:00 ` dennison 1999-02-18 0:00 ` Alexy V Khrabrov 1999-02-15 0:00 ` dewar 1999-02-15 0:00 ` Ehud Lamm 1999-02-16 0:00 ` steve quinlan 1999-02-17 0:00 ` Jean-Pierre Rosen 1999-02-18 0:00 ` robert_dewar 1999-02-18 0:00 ` Keith Thompson 1999-02-18 0:00 ` dennison 1999-02-23 0:00 ` Chris Morgan 1999-02-18 0:00 ` David Brown 1999-02-18 0:00 ` robert_dewar 1999-02-17 0:00 ` Pascal Obry 1999-02-17 0:00 ` Steve Whalen 1999-02-17 0:00 ` dewar 1999-02-17 0:00 ` steve quinlan 1999-02-18 0:00 ` robert_dewar 1999-02-19 0:00 ` Simon Wright 1999-02-14 0:00 ` robert_dewar 1999-02-10 0:00 ` dewar 1999-02-10 0:00 ` Tom Moran 1999-04-20 0:00 ` Robert Dewar 1999-04-20 0:00 ` Ehud Lamm 1999-04-20 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox