Re: Hiding the value of Constants

[Adam Beneschan <adam@irvine.com>]

On Jul 7, 11:48 am, "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.  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
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 := 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