Re: Learning Ada (Was: unsigned type)

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

anon top-posted on comp.lang.ada:
> Wrong!
>         I was not talking about the Ada Statements "Type" or "Subtype" 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]
>         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 violate
> 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" 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 ) ;

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 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.

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 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.

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.

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

No, that was Jacob Sparre Andersen.

>         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.

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.

[...]
>         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 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.

[...]
>         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.

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.