Re: Functions vs constants

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 24/07/14 00:12, Randy Brukardt wrote:
> "G.B." <bauhaus@futureapps.invalid> wrote in message
> news:lqoab0$bnm$1@dont-email.me...
>> On 23.07.14 00:07, Randy Brukardt wrote:
>>>      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.
>>
>> Well, this text gives the reader a lucid hint at what the homonyms
>> might mean! Sounds like more context dependency as we have some
>> already, don't we. Good grief.
>
> I think you miss the point. This isn't something that one intentionally
> writes (and "Error" is a terrible name just used for an example). But if one
> intends to reuse code, the client has no control over the naming of the
> entities in the reused code. Moreover (and more important), the client
> shouldn't break due to unrelated maintenance on some third-party code.

I disagree, because the client should perhaps be diagnosed broken, for
reasons of maintainability of references. The latter word is meant
in the generals sense: if it takes a name resolution program to know
the named objects (again in the general sense of the word), then the
program's project management could be steering in a direction of more
helpful naming rather than in that of more complex compiler technology.

That is, if it's broken, fix it. If it needs overloading, take care.
Do not rely on ever more capable, ever more sophisticated overload
resolution technology in this case. IOW, find it suspicious if your
compiler vendor praises a somewhat complicated techno feature that
makes your bundle of homonyms still work!  ;-) ;-) ;-)


> Especially if that third-party code decides to add something with the same
> name as something that you are already using. How could they know to avoid
> it?

Neither can I. (Example below.)

> One could imagine a rule "no use clauses of any kind, anywhere", but that's
> not really practical (especially as it means no infix operator usage). In
> the absence of that, you're going to be at risk for problems. Moreover, even
> if "prefixes are good", they also make code unreadable (particularly if you
> have lots of child packages).

I agree that some kind of abbreviation mechanism is necessary. But not
through overloading, if possible. I'd rather have more errors appearing
(sic), since they can be fixed, rather than having them swept under the
rug, which is what extensive overloading will do. (Hence the example of
Javascript obfuscation; while technically correct, the result is
not maintainable.) That's on the premiss, of course, that a reader of
an ideal Ada program will know the object that some given name denotes
without doing too much resolution himself.

> Ada has many rules that are intended to prevent Beaujolais and Ripple
> effects.

Yes, and I'd like to adduce the rules that make an inner P
hide an outer P, with no "use" in sight. The client might have
to manipulate visibility of names in this case, too.

package P is
    Q : array (Natural range 8 .. 15) of Boolean;
end P;

with P;  -- added, "incompetent programmer" wonders about effect
procedure Client
is
    package P is  --  suppose "competent reviewer" had skipped
                  --  this nested inner P on first reading ...
       function Q (N : Natural) return Boolean;
    end P;

    package body P is separate;

begin
    if P.Q (12) then   --  ... and now both assume things.
       null;
    end if;
end Client;

Writing "with P;" on top of Client doesn't change this program
a bit, provided that P's elaboration has no effects. But it does
change all sorts of assumptions.  Adding more overloading could
not possibly remove the effects of more assumptions?

The same argument applies to with-ing packages from two or more
different libraries, I think. While it might seem tempting to have
a "smart" compiler resolve all naming issues through some kind
of "smart" overloading, I'm reluctant to call that a solution.

It might help getting a particular job done, but since I'm constantly
in a position of having to deal with the results in the long run,
I cannot like it that much.

> To avoid overloading ("homonyms"),
> then you have to avoid "+" and Put and Read and Image and lots of other
> things.

I think that homonyms like "+" and "Put" could be put on the "overriding"
side of "overriding vs overloading", couldn't they? (If we are allowed
to think in terms of a suitably changed language, one that reinterprets
Ada text without changing the effect of code generated for a + b.)

>> This over-overloading, rightfully frowned upon by SPARK ...
>
> SPARK avoids overloading because the original authors of the tools didn't
> have enough knowledge of how to implement it. (...)

[I have turned this political argument---about what is not---around, in the
paragraph about compiler writers who like to sell more overloading. 8-) ]