Re: Negative float problem

[Maciej Sobczak <no.spam@no.spam.com>]

Robert A Duff wrote:

> 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?

Above, if only you make T visible for P2 (otherwise P2 should not even 
compile), then it is P1.Q which should be called. It is the *type* of 
the parameter that guides the lookup, just as elsewhere.

The same example can be restated in C++ as follows:

namespace P1
{
      struct T {};
      void Q(T X);
}

namespace P2
{
      using namespace P1; // you missed the equivalent of this line

      T Mumble;
      void Q(T X);
}

int main()
{
      Q(P2::Mumble);
}


> 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.

And I like it.

> Similar things are
> illegal in C++ (I think -- am I right?).

Similar things do not exist in C++ because enums are not strongly typed 
(there is a proposal for strongly typed enums, however) and because 
functions do not overload on their return type. This behaviour can be 
implemented by user in terms of overloading cast operator for the given 
set of types, but this is rarely used, if ever.
It's considered to be obscure and error prone. :)

> 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;
> ?

I'd expect this code to fail to compile, because:
- F is not directly visible at the call site, because there is no "use" 
clause that would bring it from either P1 or P2, *AND*
- P2.Mumble is of type Boolean and there is no F in the package where 
Boolean is defined.

As stated previously, ADL is guided by types, not by objects.


>>Let's consider again the original problem stated in this thread.
> 
> 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.

Only operators?

> 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 agree, otherwise there would be no advantage of having packages (or 
namespaces) at all. But with ADL you *have* to name at least one entity 
in the whole expression (or in a declaration or whatever is the context) 
in a way that makes it clear what package (or namespace) it belongs to. 
In the context of the original problem, it was the name of the type: 
file1.My_Float. Why qualifying the operator in addition to that?

> 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!)

If you ask me, then no, syntax has nothing to do with conceptual 
differences. :)


>>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.

Sorry, I've just checked more carefully and I messed things up before.

The set of declarations which are taken into account is the *union* of 
those from "ordinary" lookup and those from ADL, which means that the 
additional set of names is considered anyway.
This means that indeed, it cannot be added to the language without 
possibly breaking some existing code. ADL has to be there from the 
beginning.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/