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

[Adam Beneschan <adam@irvine.com>]

On Jan 29, 6:42 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote in messagenews:wccy6jkz46l.fsf@shell01.TheWorld.com...
>
> > "Hibou57 (Yannick Duchêne)" <yannick_duch...@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.)

Some problems like that could be mitigated by defining overloading
only for constants declared with an <object-declaration> that contains
the word "constant".  I.e. *not* for loop variables, IN parameters,
exception occurrence variables in handlers, ..............  Actually,
I suspect that that's the kind of constant the OP was thinking of, not
everything that the language defines as having a constant view.

                                 -- Adam