Re: Hiding the value of Constants

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Dmitry A. Kazakov schrieb:
> 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

[...]

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

The programmer seeing something as "obvious" is a hint to
what the problem with overloading actually is, and what the
(radical) solution looks like.  (Really radical, in a gardening
sense, sort of. :-)   Here, again, is the Max example:

   Max : constant Integer := 15;
   Max : constant Float := 15.0;

What seems obvious to me is that the programmer intends to
express the Max of two somethings that share some common
property: they both have a Max.  But he/she wishes to do so
*without* explicitly programming the underlying common
structure!  Perhaps it seemed obvious when writing the code,
or being lazy and not explicitly programming the common
property seemed justifiable at the time of writing.
IMHO this is an example of the presumption of "being obvious"
making things unecessarily complicated: the compiler would
have to resolve the overload that was introduced by the
programmer who *knew* how to resolve both the commonality
and the difference. (There are means in Ada to express
the same algorithm for two data structures, but anyway ...)

The radical solution is to finally get rid of overloading!
Just use one name for one thing in one region.  See SPARK
for an example.

In Ada, not using generics, but using overridden Max,

   Bounded_Structure: Finite_Order'class := ...;
begin
   if Item < Bounded_Structure.Max then
      ...