Re: Learning Ada (Was: unsigned type)

[anon@anon.org (anon)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5868 bytes --]

Wrong!
        I was not talking about the Ada Statements "Type" or "Subtype" but 
true Standards that go beyond Ada.

An example that is listed in the Ada RM, is the standard character sets:
  ISO 10646 Universal Multiple-Octet Coded Character Set
  ISO 8859-1 (Latin-1)

        But Ada also, use standards for it types, "Integer", and "Float', with 
their associate subtypes.  One reason but not the only reason for the range of 
these built-in types are the hardware.  If the hardware uses 32-bits integers 
then the Ada "Integer" is based on 32-bit. And in todays systems the Ada 
"Float" is normally based on the FPU (hardware) range.  And the numeric 
ranges for the FPU is based on standard that are defined and adopted by the 
agencies like IEEE and ISO. 

        But some people like "Ludovic Brenta, state that most Ada programmers 
would prefer to create their own types. In some case, that goes against the RM 
because it can create a non-standardize form of an Ada programs, that violate 
other RM rules. Plus, the RM states that a number of numeric types are 
predefined, such as "Integer", and it subtypes "Natural" and "Positive" as 
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:

    type Integer is range -2 ** 24 .. +2 ** ( 24 - 1 ) ;

To use this new definition of "Integer", globally it needs to be define in 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. But in most programming this 
is not necessary. That is, since Ada creation and the DOD dropping it full 
support of Ada, the usage for redefining the numeric data types is almost nil, 
not the norm any more.  Plus, the DOD require full documentation on all new 
define types. And no matter what type is defined the compiler will fall back to the 
basic standards of the universal-integer and universal-real aka CPU integer 
and FPU float and their operations. If you study most of the implementations 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-integer and 
universal-real.

        Now, "Rob Solomon" stated that he think "it would be beneficial, if 
the types Float and Integer were removed from the language". 

        First, if this could happen the RM would need a MAJOR overhaul. 
It would be easier to create a new language. Because both types are used 
throughout the RM defined packages. 

        Second, the predefined types allow for the program to be more portable, 
because a users type might not be accepted on the new system. But using the 
standards or creating a subtype from the standards is better. An example is:

    type Integer is range -2 ** 256 .. +2 ** ( 256 - 1 ) ;

which is a valid Ada statement but in a 32-bit and most 64-bit system this 
type is not allowed. You would need to use a special array or record type that 
is based on the universal-integer or CPU and define the operations in a math 
package or packages. There are a few special scientific projects that could 
use that type of maybe even a larger type like 1024-bit, but there's not 
enough applications for most to spend their time in creating such a package.  
Normally, its the scientist that ask for help that developes such packages for 
his project and only for his project and then sets the big price tag for others 
that package.

        Then third, is without standards types like "Integer" and "Float" how 
would the system work.  Using Ada, define a "=" or "*" without using the 
universal-integer and universal-real types or there operations.  You can not! 
You must have some basic standard types and operations to define other 
operations. Ada calls these types universal-integer and universal-real and uses 
their operations to build the predefine types and their operations.

        Fourth, is to interface with other languages. which also use standards. 
Some Ada programmer prefer pure Ada code.  Like using the "Interface" 
package to only define the standard unsigned types and to use the low-level 
shift and rotate routines for those unsigned types. But there are times when 
interfacing is required.


In <4a4f6cce$0$31869$9b4e6d93@newsspool3.arcor-online.net>, Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
>anon wrote:
>> Standards are the way to go.  
>
>Yes, standards are the way to go.
>
>And this *is* standard Ada:
>
>   type T is range 1_000_000 .. 9_999_999;
>
>The type T has the exact same set of operations as Standard.Integer.
>It is just as efficient as implementation defined Standard.Integer.
>The types Integer or Boolean you mentioned are not needed in
>order to define T.  Universal_integer is the type of integer
>literals like 1_000_000; it is *not*  declared in package Standard, it
>does not even have a name, it is just a predefined anonymous
>type.
>
>> Also, Its kind of funny.  Other than me not one person here tried to answer the 
>> original person question from "unsigned type".
>
>The first answer by Florian Weimer answered the original
>question, implying, I guess, that CARDINAL is not a mod
>type and so cannot be replaced with a mod type like Unsigned_N
>as you seem to suggest: For Modula-2's CARDINAL, there
>is overflow check control... So CARDINAL is not the same
>as a modular type in Ada.
>
>The second answer, by Albrecht K�fer, in addition
>points to modular types and to how they
>differ from Modula-2's CARDINAL.
>
>Maybe it is part of Ada culture to explain how
>a problem is solved in Ada, not how you can
>write Ada in the language you know, even when
>that might make some Ada teachers more popular
>among those students who do not have the, uhm, time
>to really learn Ada.