From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9ce095aba33fe8d0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Negative float problem Date: 01 Nov 2005 19:28:34 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1130351574.313991.229420@g14g2000cwa.googlegroups.com> <10mspnley7gzu$.1swtj67sv0ldr$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1130891315 1132 192.74.137.71 (2 Nov 2005 00:28:35 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 2 Nov 2005 00:28:35 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6100 Date: 2005-11-01T19:28:34-05:00 List-Id: Maciej Sobczak 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