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,e55245590c829bef X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!83.128.0.11.MISMATCH!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 03 Nov 2010 16:28:21 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Beginners question: Compound types, how-to? References: <86wroy58ff.fsf@gareth.avalon.lan> <86pqup5xfy.fsf@gareth.avalon.lan> <86y69d3rec.fsf@gareth.avalon.lan> <82lj5c5ecm.fsf@stephe-leake.org> <79ed13b7-4c55-40c4-9f66-e30ed94e5591@e14g2000yqe.googlegroups.com> <4cd0b0ed$0$6775$9b4e6d93@newsspool3.arcor-online.net> <4cd15ca6$0$7666$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: <4cd15ca6$0$7666$9b4e6d93@newsspool1.arcor-online.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID: <4cd17f95$0$6987$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 03 Nov 2010 16:28:21 CET NNTP-Posting-Host: 1af92053.newsspool4.arcor-online.net X-Trace: DXC=_hHm[YTUS;H0YVY]kmLTlD4IUKJLh>_cHTX3jM;Q`UH_8kKgM X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:16139 Date: 2010-11-03T16:28:21+01:00 List-Id: On 03.11.10 13:59, Georg Bauhaus wrote: > Can a name placed before ':' be a type at all? > That's a good thing because it remove one decision. > > Every "if" requiring context makes the number of > possible interpretations grow exponentially. > Reading effort is higher, which might be not so good. This was as clearly stated as the sky is, today. Let me try again. A name appearing before a ':' is not a type name. Suppose a name appearing there is a homograph of a type name. In this case the reader will be asking herself: "What kind of entity is this name designating, a parameter, a type, something else?" If such-and-such, it is a type name, if so-and-so, it is a parameter name. Or maybe even ... So there are a number of ifs to be answered when you want to decide what kind of entity is before you. Ada grammar helps reducing the number of ifs to be answered, but only to some extent. For example, procedure Increment (Integer : in out Integer) is begin Integer := Integer'Succ(Integer); end Increment; This is decipherable both by compilers and by humans, even when it is wrong (you couldn't otherwise say that it is wrong.) If you think that any of the following alternative definitions look better, can you say why in each case? And in which programming situations? I don't think that the examples hinge only on programmers' familiarity with type(!) name "Integer" (fixed in our minds to be a type's name). Trying another pair of names shouldn't make a big difference. 1) Like Dmitry mentioned procedure Increment (An_Integer : in out Integer) is begin An_Integer := Integer'Succ(An_Integer); end Increment; 2) IIRC, Bill Findlay uses this one (though not the name "Integer" used for parameter names, I should think). Apologies for dropping the name if not: procedure Increment (Integer : in out An_Integer) is begin Integer := An_Integer'Succ(Integer); end Increment; 3) Stephen Leake's private rule: procedure Increment (Integer : in out Standard.Integer) is begin Integer := Standard.Integer'Succ(Integer); end Increment; 4) The preference for _Type procedure Increment (Integer : in out Integer_Type) is begin Integer := Integer_Type'Succ(Integer); end Increment; 5) Combine (1) and (4) to get procedure Increment (An_Integer : in out Integer_Type) is begin An_Integer := Integer_Type'Succ(An_Integer); end Increment; But of course no one will be mixing styles. Never, right? And the only confusion can ever arise from my weird use of the name "Integer"? OK, then, for example, procedure Increment (T : in out T_Type) is begin T := T_Type'Succ(T); end Increment; Try the other examples with different names, too. Do you think that T always denotes a type? Or only if used in this or that position? All examples seem worthless; the names are meaningful only when program text is written to allude to language defined things. Such examples as use P for packages, R for records, F for fields, and so on. I expect that real programs leave much less difficulty in choosing names that to *not* allude to Ada issues. They will denote things from the problem domain, even when the domain is a fairly abstract one.