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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.15.167 with SMTP id f27mr2964003yhf.37.1407454553330; Thu, 07 Aug 2014 16:35:53 -0700 (PDT) X-Received: by 10.50.2.6 with SMTP id 6mr4649igq.10.1407454553066; Thu, 07 Aug 2014 16:35:53 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!j15no5387708qaq.0!news-out.google.com!px9ni588igc.0!nntp.google.com!h18no15872241igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 7 Aug 2014 16:35:52 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <85a97spo1c.fsf@stephe-leake.org> <92dd7d22-a7da-44d7-9c40-b3aa62881683@googlegroups.com> <4f431041-5292-434d-988e-46d69f4800f8@googlegroups.com> <472a5732-3dc9-4c08-8bda-00720375a2a9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Problem with generic linked list package From: Adam Beneschan Injection-Date: Thu, 07 Aug 2014 23:35:53 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21526 Date: 2014-08-07T16:35:52-07:00 List-Id: On Thursday, August 7, 2014 3:20:00 PM UTC-7, Laurent wrote: > I thought that if the package was instantiated with an integer for elemen= t_type, "<" defined for element_type would "see" that oh yes I know how to = compare 2 integers and use the "<" defined in the standart package for inte= gers. Same for char, float whatever. This is how generics are in Ada. The compiler needs to know when it's comp= iling the generic, *before* the generic is instantiated, whether it can com= pare the types. Since you said type Element_Type is private; this means Element_Type can be any type (almost), and the compiler therefor= e won't know whether the type's values can be compared. If you had said type Element_Type is range <>; then Element_Type could only be instantiated with an integer type, and ther= efore the compiler would know that the values *can* be compared. But this = isn't the case with a "private" generic type. Since the compiler can't con= firm, when the body is compiled, whether there will be a "<" for the type, = the compiler won't let you use "<". That's what Shark8's solution does: it= guarantees that there will be "<" and "=3D" functions for your type. When= you instantiate the generic, you have the choice of supplying some functio= ns to be used for "<" or "=3D" (which can be a different name), or if you d= on't, it will look to see if "<" and "=3D" are defined. And if they're not= (if you pass it a record type that you haven't defined "<" for), the insta= ntiation will be illegal. > Didn't think that "<" element_type could be chasing his own tail. When you write function "<" (Left, Right : Element_Type) return Boolean is begin if Left < Right then ... Even if there were a "<" defined outside, this would still be infinite recu= rsion, because of Ada's rules about visibility. It's the same as if you wr= ote=20 procedure Some_Procedure (X : Integer) is begin Some_Procedure (X); ... Even if there were some other Some_Procedure somewhere else that could be c= alled, inside the body of Some_Procedure, the name Some_Procedure means its= elf. Same for "<". Inside the body of "<", the < symbol means that functi= on itself (when it's called on the same types of arguments). There are way= s around this, though, for example: procedure Some_Procedure (X : Integer) is begin Some_Other_Package.Some_Procedure (X); ... >=20 >=20 > Perhaps I am just to naive to believe that the compiler knows what I wan= t to do. Compilers are not allowed to read minds. That would be very bad, because i= t's important to have well-defined rules about what your code means. If I = put something into a Google search, sometimes Google makes some assumptions= about what it thinks I *really* want, but it's OK because if it's wrong, I= can just try again. But it would be bad if compilers were allowed to do t= hat--you could distribute a program but have no idea what it really does, s= ince there wouldn't be any clear rules about how the compiler interprets yo= ur code. -- Adam