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,46b760ffb623378c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 08 Jul 2009 12:25:23 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Hiding the value of Constants References: <30696d63-16e8-44e2-a4a5-db5095d7cfec@m3g2000pri.googlegroups.com> <4a531837$0$30227$9b4e6d93@newsspool1.arcor-online.net> <5b49f256-f779-4030-a50d-5f31fd08ddff@26g2000yqk.googlegroups.com> <0549aae1-d200-4c81-aa92-8d18df6cf0d4@b25g2000prb.googlegroups.com> <1dv621wlnwthy$.34p5zibbgti0.dlg@40tude.net> <1qye1tloa3y6i$.1x63ituluw0g4$.dlg@40tude.net> <1q139ij9zy8ap.1vnc5u4ncqdxb.dlg@40tude.net> In-Reply-To: <1q139ij9zy8ap.1vnc5u4ncqdxb.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4a547413$0$31878$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 08 Jul 2009 12:25:23 CEST NNTP-Posting-Host: 9dc9f4e9.newsspool3.arcor-online.net X-Trace: DXC=oUA2CgE`g]b]BlmkiiU@BiMcF=Q^Z^V3h4Fo<]lROoRa^YC2XCjHcbil@HmXNX?_Gd;9OJDO8_SKfNSZ1n^B98ijj4PSiLIc@Vh X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6898 Date: 2009-07-08T12:25:23+02:00 List-Id: Dmitry A. Kazakov schrieb: > On Tue, 7 Jul 2009 13:28:01 -0700 (PDT), Adam Beneschan wrote: > >> On Jul 7, 12:53 pm, "Dmitry A. Kazakov" >> wrote: >>> On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote: >>>> On Jul 7, 11:48 am, "Dmitry A. Kazakov" >>>> wrote: >>>>> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote: >>>>>> I believe the reason enumeration literals are actually functions is so >>>>>> that you can use the same enumeration literal in more than one >>>>>> enumeration type and not have to worry about name conflicts. >>>>> It is a strange explanation to me. There is no obvious reason why rules >>>>> about overloading named objects should be different for functions. The >>>>> effect is same, so the syntactic form should be same. >>>>>> The >>>>>> overloading rules will allow the compiler to figure out which one is >>>>>> meant. There are additional bonuses, such as being able to use an >>>>>> enumeration literal as the actual for a generic instantiation that >>>>>> expects a function. How useful that is in practice, I don't know. >>>>> It is indeed useful, because sometimes it is impossible to declare a ting >>>>> as an initialized constant. In such cases making it a function gives the >>>>> desired effect. >>>>> [...] >>>>>> If you mean that you'd like >>>>>> constants to be treated like static functions, so that you can >>>>>> overload them: >>>>>> Max : constant Integer := 15; >>>>>> Max : constant Float := 15.0; >>>>>> that's an intriguing idea. >>>>> I think the idea is rather straightforward. But also >>>>> X : Integer; >>>>> X : Float; >>>> I'm just guessing here, but I think a big potential problem would be [...] > I believe, nobody is satisfied how the rules handle subprograms > and primitive operations. It is too easy to design a package specification > which would make it unusable because of ambiguities introduced by > "use"-ing. Yes prefix notation makes life easier, but it does not > exterminate need in "use". Something quite radical has to be done about it > anyway. One spends virtually hours trying to find a reason why the compiler > rejects an interpretation the programmer sees as "obvious". The programmer seeing something as "obvious" is a hint to what the problem with overloading actually is, and what the (radical) solution looks like. (Really radical, in a gardening sense, sort of. :-) Here, again, is the Max example: Max : constant Integer := 15; Max : constant Float := 15.0; What seems obvious to me is that the programmer intends to express the Max of two somethings that share some common property: they both have a Max. But he/she wishes to do so *without* explicitly programming the underlying common structure! Perhaps it seemed obvious when writing the code, or being lazy and not explicitly programming the common property seemed justifiable at the time of writing. IMHO this is an example of the presumption of "being obvious" making things unecessarily complicated: the compiler would have to resolve the overload that was introduced by the programmer who *knew* how to resolve both the commonality and the difference. (There are means in Ada to express the same algorithm for two data structures, but anyway ...) The radical solution is to finally get rid of overloading! Just use one name for one thing in one region. See SPARK for an example. In Ada, not using generics, but using overridden Max, Bounded_Structure: Finite_Order'class := ...; begin if Item < Bounded_Structure.Max then ...