Re: Negative float problem

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

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

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

Right.  It should be "Mumble: P1.T;".  Sorry about that.

>... then it is P1.Q which should be called. It is the *type* of
> the parameter that guides the lookup, just as elsewhere.

OK.

> 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

Right.  Or "P1::T Mumble;".

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

Me, too.

> > Similar things are
> > illegal in C++ (I think -- am I right?).
> 
> Similar things do not exist in C++ because enums are not strongly typed

Well, change the enums to parameterless functions, then.  That
illustrates the point, and as I said in another post, I'm sorry
for confusing the issue with enums, which are quite different in the
two languages.

> (there is a proposal for strongly typed enums, however) and because
> functions do not overload on their return type.

Right.  That was my point: functions do not overload on their return
type in C++.

It's the same reason why you have to put an annoying "L" at the end of a
"long int" literal in C++.  That's a kludge, and it wouldn't work at all
in Ada, which has many integer types.  Have I got that right?

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

Yeah.

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

For operators, I agree.  For identifiers, I'm not so sure.

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

But if "+" and "Add" are really the same, conceptually, then we should
be willing to write "X := Add(X, 1);", or perhaps "Setq(X, Add(X, 1));".
Which is pretty close to a Lisp-like "(setq x (add x 1))".

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

Ahah! again.

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

Yes, it seems one has a choice between Beaujolais effects and
incompatibility.

- Bob