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!m7g2000prd.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Hiding the value of Constants
Date: Tue, 7 Jul 2009 12:05:40 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <de5c089b-f113-4404-8c6a-fee5bca8291c@m7g2000prd.googlegroups.com>
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>
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 1246993540 27082 127.0.0.1 (7 Jul 2009 19:05:40
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 7 Jul 2009 19:05:40 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: m7g2000prd.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:6886
Date: 2009-07-07T12:05:40-07:00
List-Id: <comp.lang.ada>

On Jul 7, 11:48=A0am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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. =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 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:
>
> > =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.  If a
nested subroutine has a local variable

    X : Integer;

and the body says

    X :=3D False;

the compiler will complain.  But 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.  I suppose that the question
is, what's the risk/benefit ratio in each case.  It 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).  Yes, that makes things inconsistent,
which I know isn't going to please people who like to look at the
world through theoretical eyes.  Oh, well.

                                             -- Adam