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-Thread: a07f3367d7,dbbbb21ed7f581b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!weretis.net!feeder2.news.weretis.net!news.musoftware.de!wum.musoftware.de!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Operation can be dispatching in only one type Date: Thu, 3 Dec 2009 17:08:01 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <0f177771-381e-493b-92bb-28419dfbe4e6@k19g2000yqc.googlegroups.com> <1nbcfi99y0fkg.1h5ox2lj73okx$.dlg@40tude.net> <59acf311-3a4a-4eda-95a3-22272842305e@m16g2000yqc.googlegroups.com> <4b150869$0$6732$9b4e6d93@newsspool2.arcor-online.net> <18vlg095bomhd.8bp1o9yysctg$.dlg@40tude.net> <4b152ffe$0$7615$9b4e6d93@newsspool1.arcor-online.net> <19nhib6rmun1x$.13vgcbhlh0og9$.dlg@40tude.net> <4b1557d0$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4b15bf2b$0$7623$9b4e6d93@newsspool1.arcor-online.net> <1jcbtmi5rztyp$.norvlhez9i9$.dlg@40tude.net> <4b179ffb$0$6591$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1259881683 25360 69.95.181.76 (3 Dec 2009 23:08:03 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 3 Dec 2009 23:08:03 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news1.google.com comp.lang.ada:8303 Date: 2009-12-03T17:08:01-06:00 List-Id: "Georg Bauhaus" wrote in message news:4b179ffb$0$6591$9b4e6d93@newsspool3.arcor-online.net... > Randy Brukardt schrieb: >> [...] >> This is not at all a simple topic, and the sort of simple rule used >> by Java does little other than give a false sense of security (and a lot >> of >> annoying errors in code that has no problems). > > After reading your recent hints to compatibility and single > pass compilation preventing flow analysis for legality decisions, > I noticed the possibility of a restrictions pragma, too. > > Is it really annoying when programmers are forced to state, > explicitly, what they seem to be knowing? That is, for example, > "I know that no ELSE is missing in the following code, > therefore I have omitted a no-op else branch" > > X : Some_Type; > begin > if I_Know_What_This_Does (P) then > X := Assign_It; > end if; > > Use_It := Involve (X); > > When I try to change a program, I find it annoying to > *not* see an ELSE branch that does then become a missing ELSE > branch. The desired change turns a one-way flow into a blind alley... Compatibility again would cause problems for a general rule; a restriction could be stronger. It should be noted that our local coding standard would consider the above incorrect; there always must be an else branch or at least a comment explaining why there is no else branch: if I_Know_What_This_Does (P) then X := Assign_It; -- else can't happen as P must be valid - previously checked. end if; Although I generally prefer: if I_Know_What_This_Does (P) then X := Assign_It; else raise Program_Error; -- Can't happen as P must be valid - previously checked. end if; Or in our compiler: if I_Know_What_This_Does (P) then X := Assign_It; else J2Trace.Internal_Error ("P must be valid"); -- Often including P in the message. end if; ... > The incompleteness of information here can be avoided, > to some extent I think, and that's the reason I find > the Java rule to be helpful, or the Ada warning, or the > pragma which you have suggested. > Not really annoying. I can no longer like seeing only half > of the cases of Boolean covered in an IF, explicitly. Ada has generally left this to coding standards. I'm sure Jean-Pierre will be happy to tell us that Ada-Control has options for enforcing the existence of ELSE branches. One could imagine providing such possibilities within the language, but it is fairly rare that we've done that. That's partially because Restrictions (almost always) apply to the entire partition, including the runtime libraries. But independently developed subsystems (like the runtime system or Claw or GTKAda or AWS) are likely to have used different coding standards. And rewriting them to *your* coding standard is busy work at best, and a great way to introduce bugs at worst. Randy.