Re: Functions vs constants

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

On Tue, 22 Jul 2014 17:07:55 -0500, Randy Brukardt wrote:

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

I thought about overloading exceptions with exceptions. Presently
exceptions are perceived as a kind of literals rather than objects. It is
untrue, but that is the desired semantics of [OK, some wanted C++ alike
semantics but that is another story]. Renaming conflicts with this.
Overloading may further erode the model.

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

Yes. It does not make sense.

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

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

Right. But also that renaming were not allowed to create any objects. That
would break a lot of exiting code, but this code is already broken, IMO.

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