Re: Functions vs constants

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:cso9nzjs6q5q$.16o96j9yv70q1$.dlg@40tude.net...
> On Mon, 21 Jul 2014 18:23:05 -0500, Randy Brukardt wrote:
>
>> Otherwise, I think all objects (including exceptions) should allow
>> overloading.
>
> What would be of exception renaming then? Would it create a new, possibly,
> overloaded with itself object? That would be fun!

??? I don't see a problem. Resolution works as it does now for subprograms, 
and either there is a unique resolution or not. No one says "what would be 
of function renaming if overloading is allowed" -- it just is and everything 
is fine.

The primary reason for allowing overloading of exceptions (as with objects) 
is so that they don't get hidden by something unrelated. (Especially a 
problem for use clauses.) If you have something like (assume these 
declarations have real names and the packages contain dozens of declarations 
each):

   package P is
       Error : Boolean;
   end P;
   package Q is
       Error : exception;
   end Q;

   with P, Q; use P, Q;
   procedure R is
   begin
       if Error then -- (1)
          raise Error; -- (2)
      end if;
   end R;

both (1) and (2) are illegal today. But there's no good reason for that; the 
profiles (imagining an extended idea of profile to include objects and 
exceptions) are different and there can be no more confusion between them 
than between overloaded enumeration literals.

If you've got entities with the same names and profiles in different 
packages, that's a problem that should be detected. But so long as the 
profiles are different (and that's almost always the case), then there 
shouldn't be a problem (which is not the case today).

A thought just popped into my head, perhaps you are worrying about:
    Name_Error : exception renames IO_Exceptions.Name_Error;
This is thought by many to be a long time bug in Ada. If you have "use 
Text_IO, IO_Exceptions;" then "raise Name_Error;" is illegal -- but that's 
silly because both possibilities are the same entity.

That could be fixed by adopting a rule such that if the only reason that a 
name is ambiguious is because it resolved to several different views of the 
same entity, that it would be treated as properly resolved to the entity. 
The only thing the compiler (or reader, for that matter) need care about is 
underlying entity, not exactly which view is involved. That would be 
additional complication in the language rules, but an Ada programmer would 
almost never care about it.

In any case, this isn't necessary to support object and exception 
overloading; it would help some, but more importantly it's probably a good 
idea on its own.

                                    Randy.