Re: Hiding the value of Constants

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 7 Jul 2009 13:28:01 -0700 (PDT), Adam Beneschan wrote:

> 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.

Yes, that is my point. FORTRAN-style programs were actual then.

> 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.

Wow, I don't remember that (if I ever knew (:-))

> 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.

I agree that it is a feature nobody would care to push for. But still the
rules need to be rethought in the light of new reality. Because on the
other side, 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". It gets worse
and worse, despite all support a good compiler like GNAT could give.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de