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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Language Design Mistakes (was "not intended...") Date: 1997/05/13 Message-ID: #1/1 X-Deja-AN: 241354233 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <33776792.2E44@this.message> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Wes said > ><array to a subprogram or entry, or assigning to or from the array >or a slice of it, then it will always be the only array of its type, >so a superfluous type declaration is merely clutter _hindering_ >source readability. (Some say the type name can be chosen for >documentation value, but I don't see why that can't all go into >the object name.)>> This is true, but if the language is going to allow this for arrays and tasks, it should allow it for all types. That would make the language simpler, by making it more uniform. It might even be useful, once in a while: Recursion_Count: range 0..100 := 0; -- "range 0..100" declares an -- anonymous integer type. -- This isn't Ada. function F(...) return ... is begin Recursion_Count := Recursion_Count + 1; -- Blow up if runaway recursion ... F(...) ... Recursion_Count := Recursion_Count - 1; end F; This is better than having a named type, for the reasons stated by Wes, above. And it's better than using an existing type, such as Integer, because it clearly expresses the fact that Recursion_Count isn't being freely mixed with any other integer variables, which is a useful fact when understanding the program. Note that protected types (originally called protected *records*) can be anonymous, making them uniform with tasks, but not with records. >OK, but just make sure you know the rules. If you think this way, it is >all too easy to expect this to extend to a protected object that protects >an array, this is a very common syntactic error. Or that it extends to >a single field of a record that appears only once. There was some push for Ada 9X to allow anonymous arrays for record components and the like, for uniformity, but it adds complexity, and so we decided it wasn't worth it. Where does that anon array type get implicitly declared? Certainly not just before the component_decl (which would be analogous to the object_decl case), because that would result in nested types, which cause semantic trouble. Certainly not just before the record type decl, because then you couldn't make the bounds depend on discriminants, which would be an unexpected non-uniformity. Maybe the array type gets implicitly declared before the record, and its first subtype before the component? - Bob