Re: Constant as anonymous functions : the outer space beast is back

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccy6jkz46l.fsf@shell01.TheWorld.com...
> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:
>
>> I'm back with the topic  constant as anonymous functions  ( I've
>> opened last year, about 10 months ago if my mind is right ) ...
> ...
>> Who want to talk about this subject ?
>
> Umm...  Maybe you should tell us all what you mean by
> "constant as anonymous functions", or quote your 10-month-old
> ideas, just in case some of us have forgotten, or missed it
> the first time around.

I think he's talking about making constants overloadable, so that they 
resolve like functions. This sounds suspiciously similar to something that 
one of your esteamed colleagues (me) suggested in the last couple of weeks. 
The idea didn't get much traction, however.

Specifically, I was proposing that use clauses treat objects as 
overloadable, rather than causing cancelation semantics. This would reduce 
the maintenance hazard of use clauses (caused when the addition of unrelated 
declarations causes existing code to fail to compile). The subject came up 
within the context of "integrated packages", which have the effect of 
forcing the problems of use clauses on clients whether they like it or not. 
I was trying to mitigate that danger.

Anyway, I wasn't trying to suggest that we go any further than that, as 
(arguably) there is a significant readability decrease if you apply 
overloading to all object references everywhere. The issue is that local 
objects would no longer hide distant ones, meaning that determining the 
actual item denoted by a name would be much harder. I'm not sure if this is 
really an important issue or not, but I would expect it to be used to derail 
any attempt at an overall change.

Specifically, consider something like the following if overloading was 
allowed for objects:

package P is
    Count : constant Float := 10;
end P;

with P; use P;
with Ada.Float_Text_IO;
procedure Do_It is
    Result : Float := 0.0;
begin
     for Count in 1 .. 10 loop
          Result := Result + Count;
     end loop;
     Ada.Float_Text_IO.Put(Result);
end Do_It;

This program would print 100.0 if objects (or just constants for that 
matter) had full overloading; it is illegal in Ada today (because of the 
type error). Probably the programmer expects a result of 55.0, and would be 
quite surprised that they didn't get it. It would take a long time to 
realize that Count does not denote the object directly declared on the 
previous line! (Even if you were aware of this possibility, you'd probably 
think many other things were wrong before checking to see if the problem is 
in the interpretation of Count.)

                                             Randy.