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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,772ae8afc5db35f2 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Abstract Subprograms of Untagged Types Date: 1999/03/05 Message-ID: <7bp8bk$flc$1@plug.news.pipex.net>#1/1 X-Deja-AN: 451645188 References: <7bk6gh$6d9$2@plug.news.pipex.net> <7bmgfd$2d3$3@plug.news.pipex.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada Date: 1999-03-05T00:00:00+00:00 List-Id: Robert A Duff wrote in message ... |"Nick Roberts" writes: [...] |> function Solo_T return Access_Class_T_Type is abstract; [...] |> However, the next question is: _why_ is it perfectly legal Ada? It's (very |> nearly) gibberish. [...] |The language isn't usually in the business of forbidding useless things. |Error-prone things, yes. | |I think AARM-3.9.3(3.d) addresses the above. First, to quote the AARM section Bob referred to: - 3.d Reason: We considered disallowing untagged types from having - abstract primitive subprograms. However, we rejected that plan, - because it introduced some silly anomalies, and because such - subprograms are harmless (if not terribly useful). For example: -3.e package P is - type Field_Size is range 0..100; - type T is abstract tagged null record; - procedure Print(X : in T; F : in Field_Size := 0) is abstract; - . . . - package Q is - type My_Field_Size is new Field_Size; - -- implicit declaration of Print(X : T; F : My_Field_Size := 0) \ -is abstract; - end Q; - 3.f It seemed silly to make the derivative of My_Field_Size - illegal, just because there was an implicitly declared abstract - subprogram that was not primitive on some tagged type. Other rules - could be formulated to solve this problem, but the current ones seem - like the simplest. Well, just to be crystal clear, I was not seriously criticising this decision, in my previous post. I well appreciate the difficulty of making these kinds of design decisions. However, while the above 'addresses' the issue, it really resolve it. I think the example above can be solved at a stroke by making the rule that an abstract subprogram is never a primitive operation of an untagged type (it's legal, but never inherited by derivatives of untagged types). I think there needs to be a corollary rule that every abstract subprogram must have at least one parameter or return type which is a tagged type. No doubt some further special rules would be needed. I've also no doubt that the designers thought of introducing these rules (alluded to in 3.f), but judged them to add too much complexity to be worthwhile. This was a judgement, and fair enough. However, I disagree with it, and I would like to see the restrictions introduced in the next revision of Ada. I think the reason why can be found in my previous post (in this thread): users can mistakenly declare abstract subprograms which could actually serve no useful purpose, but which are quietly accepted by the compiler. Compilers could be expected to give a warning, but this is at the mercy of compiler makers (GNAT 3.11p apparently doesn't give any warning, but perhaps rightly so given the absence of an RM95 implementation recommendation to that effect). But, surely it would be better still to force all compilers to reject such a confusing construct? Of course compilers cannot be expected to stop programmers from doing silly things, but they should give a warning (or error) when they can tell the programmer has (almost certainly) done something silly. ------------------------------------- Nick Roberts -------------------------------------