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: 103376,67ca96c42837a9ca X-Google-Attributes: gid103376,public From: steve quinlan Subject: Re: Getting GNAT to issue ARM error messages Date: 1999/02/17 Message-ID: <36CAE459.EFE2A7E7@lmco.com>#1/1 X-Deja-AN: 445353252 Content-Transfer-Encoding: 7bit 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> <7ad77n$s4v$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Lockheed-Martin Air Traffic Management Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-02-17T00:00:00+00:00 List-Id: 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? (;-)