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: 1735 bytes --]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccvde9audf.fsf@shell01.TheWorld.com...
> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:
>
>> If it's not good for constants, so why should it be good for
>> functions ?
>
> You're right -- it would make sense to allow overloading for constants.
> In fact, it would make sense to allow overloading for everything.
> But you'd want to make the resolution rules weak, so that anything
> that is likely to be confusing to programmers would be ambiguous and
> therefore illegal.
>
> Ada's resolution rules are too strong as it is.  For example:
>
>    F(...).all := X;
>
> I find it odd that the type of X is used to resolve which
> F you're calling.
>
> Another point: implicit hiding is evil.  It causes Beaujolais-like
> effects.  Ada 95 makes it worse, because of child packages -- the
> hiding can cross library unit boundaries.  Subunits already had
> similar problems in Ada 83, but subunits are less useful, and
> therefore rarer, than child packages.

I agree with Bob here.

Hibou57 (Yannick Duch�ne) <yannick_duchene@yahoo.fr> writes:
> I not aware enough of some rationale, but I feel the Constant keyword
> should be part of Constant renaming.

And I agree with you here. In both cases if we were starting from scratch.

But we're not starting from scratch. There are millions on lines of existing 
Ada code. Fixing these things would be very incompatible. We've been trying 
to find ways to compatibly fix issues with subprogram renames for years, but 
it isn't easy and is dubious if it really is helpful.

The net effect is that most likely, there will be little or no change in 
these areas.

                            Randy.