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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-02 17:47:16 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: 02 Jan 2004 20:47:16 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com> <20619edc.0312221020.3fd1b4ee@posting.google.com> <20619edc.0312222106.3b369547@posting.google.com> <3fe9f0d7.104475725@News.CIS.DFN.DE> <5802069.JsgInS3tXa@linux1.krischik.com> <1072464162.325936@master.nyc.kbcfp.com> <1563361.SfB03k3vvC@linux1.krischik.com> <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE> <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE> <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE> <3ff21255.637418757@News.CIS.DFN.DE> <3OCdnR1Hv5k2dG-iRVn-sw@comcast.com> <1072912432.529286@master.nyc.kbcfp.com> <776Jb.30088$tY5.5319@nwrdny01.gnilink.net> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1073094436 4399 192.74.137.185 (3 Jan 2004 01:47:16 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 3 Jan 2004 01:47:16 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4056 Date: 2004-01-02T20:47:16-05:00 List-Id: Hyman Rosen writes: > Robert A Duff wrote: > > I don't much like that "useful fiction". Seems more like a "strange > > confusion", to me. > > That fiction combines with the ability to overload on return type such > that you can have the same name (or literal) used as an enumerator for > multiple types, and the compiler figures out which one is meant from > context in most cases. It means that the ARM doesn't have to create a > separate rule allowing and explaining this. I very much like the ability to overload on return type (as in the enum lits we're talking about). This is superior to the overloading in C++, and many other languages, IMHO, which is always bottom up. But the reasoning seems to be: 1. Overloading is for subprogram names. 2. But we want to overload enum lits, too. 3. So we better pretend that enum lits are functions. A better line of thinking is: 1. Overloading is for subprogram names. 2. But we want to overload enum lits, too. 3. OOPS. Number 1 is wrong. We can let enum lits be overloaded, but there's no reason to pretend they're functions. They're just plain old literals. 4. Might as well let constants be overloaded, too, with rules similar to enum lits. By the way, there's no need for a "separate rule" to allow overloading. If the concept exists in the language, and you don't want to allow overloading of everything, then you need rules in the other direction -- for example, the rules in Ada about no two homographs in the same declarative region. I would prefer to allow *everything* to be overloaded, but put the restrictions in the resolution rules. > But you already know that, right? I know it only too well. ;-) - Bob