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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fa18fb47ddd229a7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-10 15:00:34 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Proposed change to BC iterator parameters Date: 10 Dec 2003 18:00:31 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1071097231 10655 192.74.137.185 (10 Dec 2003 23:00:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 10 Dec 2003 23:00:31 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:3342 Date: 2003-12-10T18:00:31-05:00 List-Id: Jeffrey Carter writes: > amado.alves wrote: > > > Strictly you don't need the limited formal for (unlimited) tagged or > > class actuals. You need the limited formal for limited actuals, > > whatever their class. Limitedness is completely orthogonal to > > definiteness. I do like indefinite formals, but I pass well without > > limited ones. Most limited formals I've seen in libraries are > > accompanied by a formal assignment operation or some such, which > > prety much defeats the purpose of their (formal) limitedness, i.e. > > their logic is in clash with their definition. > > The problem is that a generic formal part is a specification; it > specifies what the generic needs, and the client must provide, for the > generic to do its work. "Limited" implies 2 unrelated concepts: absence > of assignment, and absence of predefined equality. I agree with you here, but I can't get too excited about this particular case, because similar problems exist for many Ada types. Whenever you declare a type, you get some predefined operations. You can't say (for an integer type), "I want predefined + but not predefined -". It would be nice to be able to express that, and as you point out, it would be nice to be able to express "I want := but not predefined =". You can use private types, and define + but not -, but then you can't say "I want case_statements, integer literals, and +, but not - * / etc". Anyway, the key point of "limited" is that you can't copy things. The "=" issue is a more minor one, I think. A much bigger problem with "limited" is that you can't have aggregates and constructor functions, and you can't initialize objects. As Robert Eachus pointed out in some other thread, the ARG is actively working on this. > A non-limited formal type specifies that the generic needs to perform > equality comparisons on values of the type, which is an error in > specification. I know this seems a minor issue to many people, but > precise specifications are essential to ensuring the correct usage of > reusable components by their clients. I agree, but I also want to be able to declare an integer type that can only be incremented and not decremented or multiplied. (And still allow literals and case statements.) It's a similar issue. > This connection between assignment and equality may have made sense in > Ada 83, where equality could only be defined for limited types, but > seems an unnecessary restriction in Ada 95. The Goodenough trick actually allowed declaring "=" on limited types in Ada 83. > In hindsight, it would have been better to eliminate the "limited" > reserved word completely, and use instead > > type T is private; > -- Same as Ada's "limited private" > > type T is private with ":="; > -- Assignment defined; "=" not; no Ada equivalent > > with the capability of defining "=" for either type. Maybe. How would you extend this to the integer-type issues I mentioned above? "Case statement" is not an operator... Anyway, even if we restricted it to operators, it could get rather verbose. Saying "type T is range 1..10" is a concise way of defining a bunch of operations, and if you don't want all of them, well, is that good or bad? Here, I think you're talking about regular private types in packages (as opposed to generic formals). One idea is to say: type T is private; function "="(X, Y: T) return Boolean is abstract; Then clients can't call predefined "=". (But predefined "=" reemerges in generics! And records.) I've also done things like this (in the visible part): type T is private; function Predefined_Equal(X, Y: T) return Boolean renames "="; -- For use only in the package body! function "="(X, Y: T) return Boolean is abstract; Unfortunately, the Ada compiler does not understand the comment, "-- For use only in the package body!". You say above, ``with the capability of defining "=" for either type.'' But it's not trivial to make that "=" be the predefined one. - Bob