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 Path: g2news2.google.com!postnews.google.com!b25g2000prb.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Hiding the value of Constants Date: Tue, 7 Jul 2009 13:28:01 -0700 (PDT) Organization: http://groups.google.com Message-ID: 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> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1246998482 10784 127.0.0.1 (7 Jul 2009 20:28:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Jul 2009 20:28:02 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b25g2000prb.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6890 Date: 2009-07-07T13:28:01-07:00 List-Id: On Jul 7, 12:53=A0pm, "Dmitry A. Kazakov" wrote: > On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote: > > On Jul 7, 11:48=A0am, "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 s= o > >>> 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 rule= s > >> 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. =A0There are additional bonuses, such as being able to use an > >>> enumeration literal as the actual for a generic instantiation that > >>> expects a function. =A0How useful that is in practice, I don't know. > > >> It is indeed useful, because sometimes it is impossible to declare a t= ing > >> as an initialized constant. In such cases making it a function gives t= he > >> desired effect. > > >> [...] > > >>> If you mean that you'd like > >>> constants to be treated like static functions, so that you can > >>> overload them: > > >>> =A0 =A0 Max : constant Integer :=3D 15; > >>> =A0 =A0 Max : constant Float :=3D 15.0; > > >>> that's an intriguing idea. > > >> I think the idea is rather straightforward. But also > > >> =A0 =A0X : Integer; > >> =A0 =A0X : Float; > > > I'm just guessing here, but I think a big potential problem would be > > if objects of the same name were declared in different scopes. =A0If a > > nested subroutine has a local variable > > > =A0 =A0 X : Integer; > > > and the body says > > > =A0 =A0 X :=3D False; > > > the compiler will complain. =A0But if the outer subroutine has its own > > local variable X of type Boolean, the compiler wouldn't catch this. > > > I realize that subprogram overloading can sometimes lead to the same > > kinds of situations where the compiler doesn't catch an error because > > you used the wrong parameter type, for example; and since subprograms > > can be declared implicitly, when a type is derived e.g., it might be > > hard to track down problems like that. =A0I suppose that the question > > is, what's the risk/benefit ratio in each case. =A0It could be that the > > benefits of having overloaded subprograms available outweighs the > > problems (confusion and failure to catch some errors at compile time) > > of making subprograms in an outer scope visible, while in the case of > > variables the problems outweigh the potential benefits (especially if > > nobody would really *want* to declare two variables with the same name > > and have them both visible). =A0Yes, that makes things inconsistent, > > which I know isn't going to please people who like to look at the > > world through theoretical eyes. =A0Oh, well. > > Yes, but. I remember how it was programmed in FORTRAN - very few > subprograms, a lot of variables declared in. The programming style has > dramatically changed since then. Ada 2005 is a very different language. H= ow > many variables are visible in a scope of a normal Ada program? 3-5, maybe > 10 counting formal parameters. How many subprograms? Hundreds? Thousands? > > Is the issue of hiding variables really actual? The rules about overloading and visibility go back to Ada 83. In Ada 83, there were more restrictions on the order of things in a declarative part. If procedure Proc1 had a nested procedure Proc2, Proc2's body could not appear before any of Proc1's local variables. Thus, whatever work or temporary variables, etc., that Proc1 needed, would necessarily be visible to Proc2. (You could work around this by making Proc2's body a *block* and declaring the locals there. But doubtless not everybody did that.) Under those rules, then yes, a lot of variables could be visible to a nested subprogram. The same issues apply to subprograms in a package body; the Ada 83 rules stated that the subprogram bodies had to appear after any variable declarations in the package body. The order restrictions are gone in Ada 95 and Ada 2005, but there's still plenty of Ada 83 code out there that the language designers have to concern themselves with. Programmers still have to maintain Ada 83 code, and we don't want to tell them that they have to rearrange all their code in order to avoid possible errors. Anyway, although we could have a discussion about this point, I doubt that anything will change. It would require a lot of work for compiler maintainers (like me) to implement this change, and it's for a feature that as far as I know nobody really is itching for. And I don't think a language change that dumps a lot of work on compiler maintainers with almost no practical benefit to any users is likely to happen, even if it would make the language more consistent and thus more pleasing to theoreticians. -- Adam