Re: Hiding the value of Constants

[Adam Beneschan <adam@irvine.com>]

On Jul 7, 12:53 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:
> > 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.
>
> 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. How
> 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