Re: Hiding the value of Constants

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

On Wed, 08 Jul 2009 12:25:23 +0200, Georg Bauhaus wrote:

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

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

I don't see how an underlying structure would help. Consider both Integer
and Float descendants of some Numeric type. Does that change anything? (see
also below)

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

I think that the idea is to express a commonality rather than resolve it.
As an example take Integer'Last and Float'Last. Why they are allowed to be
visible in the same context? How (semantically) they differ from Max?

> The radical solution is to finally get rid of overloading!

Yes, it is a very attractive idea. But the problem is, how to live with "+"
defined both on Integer and Float? As I said earlier, the problem is not
with variables. I think the language will continue reducing the number of
declared variables down to virtually none. The problem is thousands of
operations and types. Where would you get different names for all of them?
How are you going to remember that mess? Consider a typical design of a
library based on generics. It forces you to have identical names for
everything declared in a generic package. The difference happens in the
instances of. The names of the instances is a traditional torture to
invent. As a result they are absolutely meaningless and impossible to
remember. The compiler too has no idea how to help you in finding an
instance of "indexing" a "generic map" with the element "T".

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

You forgot that a polymorphic operation (Max) is a set of overloaded
specific bodies. You have to allow specific bodies being named. In Ada
these names overload. So the only way not to do it, is to go the path of
C++ by providing unique names mangled by the type signatures, e.g.
Max<Integer>. Interestingly, this is how Ada 83 started. It still has
disgusting attributes taking the form Type'Name. I hope you would agree
that this is a road to hell?

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