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 Path: g2news2.google.com!postnews.google.com!24g2000yqm.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Learning Ada (Was: unsigned type) Date: Sun, 5 Jul 2009 17:05:20 -0700 (PDT) Organization: http://groups.google.com Message-ID: <134d9099-7384-4a76-a81b-4d8a2c6517c6@24g2000yqm.googlegroups.com> References: <59O1m.404661$4m1.69194@bgtnsc05-news.ops.worldnet.att.net> <62792744-daca-437b-bdee-4b8a21f7ce27@j32g2000yqh.googlegroups.com> <82oq45tj2uu26u6ecsgq70bsjskr9dvghr@4ax.com> <878wj61bpo.fsf_-_@nbi.dk> <4a4f6cce$0$31869$9b4e6d93@newsspool3.arcor-online.net> <4Aa4m.421894$4m1.207252@bgtnsc05-news.ops.worldnet.att.net> NNTP-Posting-Host: 88.170.86.208 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1246838721 14718 127.0.0.1 (6 Jul 2009 00:05:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 6 Jul 2009 00:05:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 24g2000yqm.googlegroups.com; posting-host=88.170.86.208; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009061208 Iceweasel/3.0.9 (Debian-3.0.9-1),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6846 Date: 2009-07-05T17:05:20-07:00 List-Id: anon top-posted on comp.lang.ada: > Wrong! > =A0 =A0 =A0 =A0 I was not talking about the Ada Statements "Type" or "Sub= type" but > true Standards that go beyond Ada. Please define a "true standard" (as opposed to a "standard") and what it means for a "true standard" to "go beyond" Ada. "go beyond" is a non-standard phrase, it does not appear anywhere in the ARM. [use the language-defined Integer and Float] > =A0 =A0 =A0 =A0 But some people like "Ludovic Brenta, state that most Ada= programmers > would prefer to create their own types. I did not state that; I don't know what "most Ada programmers" do or where they are, and I don't use the "lemming argument" because I honestly don't care what "most people" do in general. If I wanted to do what "most people" do, I would not program in Ada. What I said is that it is generally *better* to use application-defined types than language-defined types; this is the proper and intended way to use Ada. > In some case, that goes against the RM > because it can create a non-standardize form of an Ada programs, that vio= late > other RM rules. If a program violates other RM rules and the compiler properly enforces the rules, then the program won't compile. What was your point? > Plus, the RM states that a number of numeric types are > predefined, such as "Integer", and it subtypes "Natural" and "Positive" a= s > well the type "Float" and its subtypes. Redefining those predefines types= are > legal in Ada, by simply re-defining the type. Like for example, using 24 = bit > integer: > > =A0 =A0 type Integer is range -2 ** 24 .. +2 ** ( 24 - 1 ) ; Wrong; your declaration is legal but it does not "redefine" Standard.Integer; it defines a new type with the same name. > To use this new definition of "Integer", globally it needs to be define i= n the > standard package, but for a single package or routine it better to create= a new > type or subtype and for the routine or package. No; it is better to define an application-specific type instead. By declaring a type Integer in your own package, you create a new problem (global visibility of your new type) without solving any existing problem, so this is not only useless but harmful. I've seen it done in several places before and the reasons given to me for doing that were always wrong. At least they avoided using the name Integer but used Integer_Type or something similarly stupid instead. By the same token, changing the definition of Standard.Integer achieves nothing useful and is a lot of trouble, so don't do that. > But in most programming this > is not necessary. That is, since Ada creation and the DOD dropping it ful= l > support of Ada, the usage for redefining the numeric data types is almost= nil, > not the norm any more. =A0Plus, the DOD require full documentation on all= new > define types. And no matter what type is defined the compiler will fall b= ack to the > basic standards of the universal-integer and universal-real aka CPU integ= er > and FPU float and their operations. If you study most of the implementati= ons of > Ada, one can see that the types "Integer" and "Float" that are defined in= the > "Standard" package are basically equivalent to the Ada's universal-intege= r and > universal-real. So what? If you don't want compile-time type checks and only care about the hardware-defined types, then go program in assembly language. > =A0 =A0 =A0 =A0 Now, "Rob Solomon" stated that he think "it would be bene= ficial, if > the types Float and Integer were removed from the language". No, that was Jacob Sparre Andersen. > =A0 =A0 =A0 =A0 First, if this could happen the RM would need a MAJOR ove= rhaul. > It would be easier to create a new language. Because both types are used > throughout the RM defined packages. > > =A0 =A0 =A0 =A0 Second, the predefined types allow for the program to be = more portable, > because a users type might not be accepted on the new system. I'm sure Jacob is well aware of that. For your second objection, it is a *Good* *Thing* if the compiler says up-front, at compile time, whether it supports the application-defined types or not. It is a *Bad* *Thing* if the compiler is silent and the application later misbehaves because the hardware doesn't support the application constraints. [...] > =A0 =A0 =A0 =A0 Then third, is without standards types like "Integer" and= "Float" how > would the system work. =A0Using Ada, define a "=3D" or "*" without using = the > universal-integer and universal-real types or there operations. =A0You ca= n not! You seem to be confusing the unioversal_integer and universal_real types (which are anonymous) with Standard.Integer and Standard.Float, respectively. They are *not* the same things. Even if Standard.Integer and Standard.Float disappeared, unioversal_integer and universal_real would still exist and allow the arithmetic operations you describe. [...] > =A0 =A0 =A0 =A0 Fourth, is to interface with other languages. which also = use standards. > Some Ada programmer prefer pure Ada code. =A0Like using the "Interface" > package to only define the standard unsigned types and to use the low-lev= el > shift and rotate routines for those unsigned types. But there are times w= hen > interfacing is required. For interfacing to C, you use Interfaces.C.int, not Standard.Integer, and Interfaces.C.C_float, not Standard.Float. For COBOL you use Interfaces.COBOL.Binary and Interfaces.COBOL.Floating. For Fortran, you use Interfaces.Fortran.Fortran_Integer and Interfaces.Fortran.Real. If "some Ada programmers" prefer Standard.Integer and Standard.Float against the ARM, then they are wrong. Nowhere does the ARM state what Standard.Integer or Standard.Float correspond to in C, COBOL or Fortran. -- Ludovic Brenta.