Re: Learning Ada (Was: unsigned type)

[anon@anon.org (anon)]

Who said remove the "the universal types aka the "universal_integer" and 
"universal_real"? Well,

    From: Jacob Sparre Andersen <sparre@nbi.dk>
    Subject: Learning Ada (Was: unsigned type)
    Date: 03 Jul 2009 09:12:51 +0200

    "It might be to push things a bit too far, but I think it would be
     beneficial, if the types Float and Integer were removed from the
     language."

That suggests to anyone that read the statement that he thinks Ada would be 
better off if the "Integer" and "Float" types were remove. And like I said 
it would cause a MAJOR overhaul of the RM to the point that it would be 
easier to create a new language.

A simple reason is that the "Integer" and "Float" are defined in the Standards 
package RM A.1 ( 11 .. 12 ) and  RM A.1 ( 20 .. 21 ). And the comments declare 
the "Integer" basically as the "universal type is universal_integer" and the
"Float" basically as the "universal type is universal_real".  So, when 
"Jacob Sparre Andersen" suggested removing these types he is in a sense 
suggesting pulling the "universal types" aka removing the universal_integer" 
and "universal_real" from Ada. 


As for Portability!

Portability is easy if you use the built-in standards. Like going from a 
CRAY, VAX, IBM and a LLNL super computer (CPU was unknown for the 
project) using, a mixer of programs written in Ada 83 and Ada 95 
specification, with no modification within the used specification. That is,
using either Ada 83 or 95 a program was written for one vendor and 
then compiled for the other 4 system without any Ada statements modifications.
The only allowable change was to programs and its packages file names based 
on system to be compiled.  The result of project was its all in the way 
a person programs with Ada and if they limit the usage of external (non-RM) 
packages. But portability can be extended to non-RM packages if Ada 
programmer use other standards like, in today programs using openGL 
or SDL for a graphic package instead of direct control of the OS window's 
environment.

Now, A integer may change it range when switching from a 16-bit system to a 
64-bit system, but the 16-bit code will work because the range of a 16-bit 
integer is a subrange of a 64-bit integer. Else, throw the CPU and the 
programmer out the window. Yes, a programmer can make a misstate that 
causes error, but that not Ada fault. it time to replace that bad programmer.


A little food for Randy Brukardt report and something he said a few week 
back.

Except for the "gigi" code (a-trans.c) which requires the GCC tree 
structures, the complete GNAT system can be compile on Randy Brukardt's 
janus Ada.  And I mean even the GNAT GPL 2009 can be compiled, that 
portability that a programmer can be proud of. And the reason one can do 
this is Adacore wrote GNAT initial using Ada 83 specs and later they 
might have added a few Ada 95 type statements. It would be true portability 
if the GNAT's "gigi" routine was written in Ada and included a few Ada 
packages for the tree structures to replace the GCC's C version.  Now, 
where's that Ada 95/2005 only version of the "c2ada" program, "simon.j.wright"? 

So, true portability is up to the programmer. Write the code with portability 
in mind. and the programmer can do it! But will he or will he write trashy C 
like code. The decision might be away to help keep there job. 




In <4a51d78d$0$30227$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>anon schrieb:
>> Wrong!
>>         I was not talking about the Ada Statements "Type" or "Subtype" but 
>> true Standards that go beyond Ada.
>
>"Beyond Ada" sounds like wavy escape rhetorics:
>Since the inception of what is now Ada, it was
>pronouncedly clear that Ada is adressing real
>computer systems and their hardware properties and
>Ada was and is expressly connected to other standards.
>
>Both, real computer systems and other standards
>do *not* *at* *all* suggest the use of predefined
>named types from package Standard for all your integer
>needs, since Ada is smarter than that---unless teachers
>prohibit the use of its extraordinary base type system!
>
>See http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>for the huge value attributable to a decent base type system:
>
>"It was the accurate modeling of scalar quantities that
> contributed the most to Ada's success in this course.
> This is consistent with studies done on the nature of
> wicked bugs in software [5] where nearly 80 percent
> of programming errors in the C/C++ programs studied were
> a result of problems with scalars.
>
>"[5] Eisenstadt, M. (1997). My Hairiest Bug War Stories.
> Communications of the ACM, 40, 30-37."
>
>where "modeling of scalar quantities" is
>
>"Modeling of scalar objects.
>-- Strong typing.
>-- Range constraints.
>-- Enumeration types."
>
>Aou suggest we should instead use implementation defined
>types of unknown sizes?
>
>
>>         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.
>
>Each user defined integer type, including operations
>and objects, is translated giving proper attention to hardware,
>
>
>
>>         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.
>
>As has been said, use types from the Standard package
>if and only if using the standard library.
>Use package Interfaces.* if and only if interfacing
>to language external facilities.
>
>
>>         Second, the predefined types allow for the program to be more portable, 
>> because a users type might not be accepted on the new system.
>
>Portability through *avoiding* type definitions seems a
>simplicissimus' argument, pardon me.  Worse, it's a lure,
>see Randy Brukardt's report.  The statement
>
>  S : String (Positive'First .. Positive'Last / 2);
>
>is largely unpredictable as regards portability from one
>machine/RTS to another. So where is your portability?
>If Positive happens to be a type for adressing 2**15 - 1
>components, your program might run fine in one environment.
>Once you port it to GNAT, say, you might be experiencing
>all kinds of trouble!
>
>If you really want programmers to
>
>(a) use machine properties, or
>(b) express maximally extensive types, for example,
>
>then make them say so! Ada has the necessary bounds defined
>for this kind of type definitions:
>
>   type My_Portability_Type is
>     range 0 .. Integer'Min(System.Max_Int, System.Memory_Size);
>
>    -- use whatever range is possible
>
>This *cannot* be achieved by relying on Standard.Integer.
>
> 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.
>
>No one *ever* said something about removing the predefined
>anonymous types universal_integer and universal_real
>*needed* for defining integer types!
>This and other claims have been adressed; have the postings
>slipped your attention by any chance?
>