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,UTF8 Path: g2news1.google.com!news3.google.com!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 04 Nov 2010 13:56:30 +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> <4cd19583$0$6977$9b4e6d93@newsspool4.arcor-online.net> <4cd1e5b0$0$6974$9b4e6d93@newsspool4.arcor-online.net> <4cd28aed$0$7658$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: <4cd2ad7d$0$7668$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 04 Nov 2010 13:56:29 CET NNTP-Posting-Host: 008201ad.newsspool1.arcor-online.net X-Trace: DXC=>Sj0LgfbY1L6PJ?[X6JIXEic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgBUjnT\:2f@^Mnc\616M64>JLh>_cHTX3jM4ABeYnR]PoF X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15214 Date: 2010-11-04T13:56:29+01:00 List-Id: On 04.11.10 12:06, Yannick Duchêne (Hibou57) wrote: >> Another argument about formal things. Ada's type declarations >> make me think that _Type was never intended: >> >> type Foo_Type is range 1 .. 10; >> ^^^^ ^^^^ > This is not about type declaration/definition, this is about usage/reference. > > Somewhere else in this thread, you talked about “Meaning, not function” : > function is part of the meaning hold. A word, a symbol, is a Signifier, the > Signifier tell us about a Signified, and the function is part of that Signified. I think that a Signified's function is not normally part of the definition of a Signified thing that is to become a type. Example: We never know *how* a Knife is going to be used when defining the type Knife. I.e., What its function is going to be. That's abstraction. The objects using the knife have a role in this. We do provide *operations* such as Cut. But what the cuts will do is beyond the reach of the definition in the following sense: The knife can serve as a weapon in cutting someone's throat It can serve as a tool for cutting fish. But this is *not* part of the definition of the type Knife. Function is part of the way the program's uses objects of type Knife, "cooperating" with objects of other types, such as "Vegetable". Knife_Type instead of just Knife does not change the definition, so Knife_Type does not predict the function either. The grammar should tell whether a word names a type or an object. Ada's does. If it didn't, Ada was ambiguous. One possible exception where _Type make a lot of sense is actual generic units that have formal type parameter. In this case a _Type suffix is meaningful: The formal parameter signifies no type yet. But is says that the actual type needs to have certain characteristics. That is, the actual type "is a" type. generic type Float_Type is digits <>; function ... Float_Type signals that Float_Type is not a type in the unit. But is stands for a real type in instances. > Know it is redundant, but the reason of this redundancy has been explained > (dedicated name-space). Counterarguments and alternative ways have been presented: Redundancy is not an excuse for lack of proper names, IHMO. > If this was not Ada, Eiffel instead, will you bother ? Would you have noticed > this “problem” ? I have noticed this problem in Eiffel, as have others. In fact, separate name spaces in Eiffel are not everyone's favorite feature. One convention that some use is to write string_ : STRING That's a little underscore in addition to the legal declaration string : STRING or even STRING : STRING A terrible choice in the presence of real-world programming where a programmer's work requires at least reading more than one language (Also, imagine rewriting the above declaration in another language; this can be solved, but again, needs mechanical, arbitrary, non-grammatical conventions.). I remember having difficulty compiling classes defined using either convention with one Eiffel dialect compiler. In Ada, the problem is aggravated by attributes, and separate name spaces won't solve it. They can be applied to both types and objects. So when a reader sees T'Something she will not be getting additional cues from separate name spaces. In fact, separate namespaces have no visible counterpart in source text. On the contrary, they add a possibility of mistaking a name in namespace-for-types for one in namespace-for-objects when they are homographs usable in the same inner region.