Re: Negative float problem

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <no.spam@no.spam.com> writes:

> [...stuff about ADL]

I'm not sure precisely what you mean by ADL in the Ada context.
Can you state the exact rules?  My gut feel is that ADL does
not make sense for Ada, because Ada has with_clauses, unlike C++.

Example:

    package P1 is
        type T is ...;
        procedure Q(X: T);
    end P1;

    package P2 is
        Mumble: T;
        procedure Q(X: T);
    end P2;

Q(P2.Mumble);

Now which Q are you advocating should be visible here?  Or both?

> Dmitry A. Kazakov wrote:
> 
> >>>Further, parameterless function call is
> >>>indistinguishable from name.
> >>
> >> So? ADL is about *arguments* and does not apply to parameterless
> >> functions at all.
> > But in A.B.C (argument) you do not know whether B is a package,
> > function
> > name or variable.
> 
> ADL applies only to unqualified names.
> The above example does not explain why Ada does not have ADL, because it
> is not more complicated than what is there in C++ anyway - in
> particular, with overloaded function call operators and overloaded
> dereference operators the expression A.B->C(argument) may have many
> meanings as well and I don't see in what way Ada represents a more
> general case here.
> The important thing is that ADL is *not* used in such cases.

I think Dmitry's point is that overload resolution in Ada is both
bottom-up and top-down.  It's simpler in C++ -- just bottom-up.

    type Color is (Red, Blue);
    type Traffic_Light is (Green, Amber, Red);
    procedure P(Param: Color);

    P(Red);

This is legal in Ada.  The compiler knows which Red is meant
based on the expected type for Param.  Similar things are
illegal in C++ (I think -- am I right?).

So if you add ADL to Ada, what would this mean:

    package P1 is
        type T is
            record
                Comp: Integer;
            end record;
        function F(X: Integer) return T;
    end P1;

    package P2 is
        type T is
            record
                Comp: Boolean;
            end record;
        function F(X: Boolean) return T;
        Mumble: Boolean;
    end P2;

    X: Boolean := F(P2.Mumble).Comp;
?

> Let's consider again the original problem stated in this thread. The
> operator name is unqualified and finding it in the namespace (package)
> associated with its argument is not a rocket science. It is what the
> programmer expects.

I agree that a reasonable programmer might expect operators to be
visible in that example.  But we could achieve that very simply:
just make operators visible wherever their type is in scope.
That is, make the "use type" semantics be the default.
No need for the complexity of ADL.

On the other hand, if you want subprograms named by identifiers, as
opposed to operators, to be visible in this manner, then I think I don't
agree that "It is what the programmer expects."  I think there's some
advantage in requiring either dot notation or a use_clause.

I understand that having different rules for operators than for
identifiers adds complexity to the language.  But I think it's
worth it.  Operators really are different, conceptually.
(If that weren't true, we'd use Lisp syntax!)
Anyway, it would not add as much complexity as adding the "use type"
clause, which is, IMHO, an ugly kludge.

> > Some legal code might become illegal, because some invisible before
> > operations would contribute to overloading.
> 
> Could you please give an example of such code?
> 
> Remember that we're considering unqualified names. Note also that ADL is
> performed *only* when the normal lookup fails (it's an extension
> mechanism).

Ahah!  I didn't understand that.  In this case, it would cause
Beaujolais effects, which completely rules it out, for me.

>... This means that by adding ADL to the language you cannot
> break existing code - but you can make some code working that was not
> working before. For example the code from the beginning of this thread.

- Bob