Differences between Ada 83 and other revisions

Differences between Ada 83 and other revisions

[yoursurrogategod]

Hello.  I'm new to Ada, but I would like to get a slightly better understanding of the language.  I like how the Ada compiler is so careful, something I rarely see in other languages.

From what I've read and heard, Ada 83 compiler was very strict about what type of code could be compiled and as a result made code that ran as programmed most of the time.  However, later revisions have weakened some of these rules for Ada 95 and onward.  Is this true?

I have found some information about the different versions of Ada, but nothing terribly descriptive.  If you know of something that I do not, please let me know!

Re: Differences between Ada 83 and other revisions

[adambeneschan]

On Thursday, February 13, 2014 7:59:32 AM UTC-8, yoursurr...@gmail.com wrote:
> Hello.  I'm new to Ada, but I would like to get a slightly better understanding of the language.  I like how the Ada compiler is so careful, something I rarely see in other languages.
> 
> From what I've read and heard, Ada 83 compiler was very strict about what type of code could be compiled and as a result made code that ran as programmed most of the time.  However, later revisions have weakened some of these rules for Ada 95 and onward.  Is this true?

No.

There were some specific rules that were weakened in Ada 95; the one that comes to mind is that it's more lenient about array bound "sliding".  Ada 95 is less strict about the order in which declarations appear.

As for the implication that in Ada 83 "code ran as programmed most of the time", while the changes in Ada 95 made this no longer true: that's simply nonsense.  If you've read something like this somewhere, I'd like to see a quote or a reference.  It's possible you misunderstood what they were saying, and it's also possible that somebody wrote something ridiculous because they were upset about something.

                                  -- Adam

Re: Differences between Ada 83 and other revisions

[yoursurrogategod]

The statement was a quote from a colleague.  I don't know of what exactly she meant.

Re: Differences between Ada 83 and other revisions

[AdaMagica]

You generally can hear a lot of utter nonsense about Ada. See here at the page end for documents describing (among others) the differences between Ada 83 and Ada 95.

Re: Differences between Ada 83 and other revisions

[Niklas Holsti]

On 14-02-13 17:59 , yoursurrogategod@gmail.com wrote:
> Hello.  I'm new to Ada, but I would like to get a slightly better
> understanding of the language.

Welcome...

> I like how the Ada compiler is so
> careful, something I rarely see in other languages.

Me too.

> From what I've read and heard, Ada 83 compiler was very strict about
> what type of code could be compiled and as a result made code that
> ran as programmed most of the time.

I have personal experience of this effect, with all versions of Ada. The
language and compiler are strict, which has two consequences: firstly,
it encourages you to design and code more carefully and thoughtfully,
else your code will not pass the compiler; secondly, the compiler will
really discover some kinds of logical errors at compile time. Both make
it more likely that the program will actually work as intended, once it
compiles correctly.

> However, later revisions have weakened some of these rules for
> Ada 95 and onward.  Is this true?

As other posters have noted, Ada 95 relaxed some Ada 83 rules which were
more "stylistic" than logically necessary. So Ada 95 and later standards
give more room for different coding styles, while still giving the same
semantic rigour. I don't believe that this makes Ada programs more
likely to fail at run time.

However, Ada 95 and later Ada standards extend the language beyond Ada
83 in many ways. Some extensions include new kinds of run-time checks
for new kinds of run-time errors, which cannot be detected at compile
time. Ada 83 had a smaller set of run-time checks and errors, so it can
be argued that programs using the Ada 95 and later extensions have an
increased risk of failing at run-time even if their compilation succeeds.

I don't know if this argument is valid; I don't see an increased risk of
run-time failure in my own programming. But I use the new features
rather conservatively and sparingly. Moreover, some of the new features
make it easier to avoid some Ada 83 -level run-time errors -- for
example, controlled types help to avoid errors in memory allocation and
deallocation.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Differences between Ada 83 and other revisions

[yoursurrogategod]

On Thursday, February 13, 2014 2:44:47 PM UTC-5, Niklas Holsti wrote:
> On 14-02-13 17:59 , yours.....gmail.com wrote:
> 
> > Hello.  I'm new to Ada, but I would like to get a slightly better
> 
> > understanding of the language.
> 
> 
> 
> Welcome...
> 
> 
> 
> > I like how the Ada compiler is so
> 
> > careful, something I rarely see in other languages.
> 
> 
> 
> Me too.
> 
> 
> 
> > From what I've read and heard, Ada 83 compiler was very strict about
> 
> > what type of code could be compiled and as a result made code that
> 
> > ran as programmed most of the time.
> 
> 
> 
> I have personal experience of this effect, with all versions of Ada. The
> 
> language and compiler are strict, which has two consequences: firstly,
> 
> it encourages you to design and code more carefully and thoughtfully,
> 
> else your code will not pass the compiler; secondly, the compiler will
> 
> really discover some kinds of logical errors at compile time. Both make
> 
> it more likely that the program will actually work as intended, once it
> 
> compiles correctly.
> 
> 
> 
> > However, later revisions have weakened some of these rules for
> 
> > Ada 95 and onward.  Is this true?
> 
> 
> 
> As other posters have noted, Ada 95 relaxed some Ada 83 rules which were
> 
> more "stylistic" than logically necessary. So Ada 95 and later standards
> 
> give more room for different coding styles, while still giving the same
> 
> semantic rigour. I don't believe that this makes Ada programs more
> 
> likely to fail at run time.
> 
> 
> 
> However, Ada 95 and later Ada standards extend the language beyond Ada
> 
> 83 in many ways. Some extensions include new kinds of run-time checks
> 
> for new kinds of run-time errors, which cannot be detected at compile
> 
> time. Ada 83 had a smaller set of run-time checks and errors, so it can
> 
> be argued that programs using the Ada 95 and later extensions have an
> 
> increased risk of failing at run-time even if their compilation succeeds.
> 
> 
> 
> I don't know if this argument is valid; I don't see an increased risk of
> 
> run-time failure in my own programming. But I use the new features
> 
> rather conservatively and sparingly. Moreover, some of the new features
> 
> make it easier to avoid some Ada 83 -level run-time errors -- for
> 
> example, controlled types help to avoid errors in memory allocation and
> 
> deallocation.
> 
> 
> 
> -- 
> 
> Niklas Holsti
> 
> Tidorum Ltd
> 
> niklas holsti tidorum fi
> 
>       .      @       .

So it would be safe to say that the newer versions of Ada have not enabled the creation of less reliable code.  And that the newer versions are overall qualitatively better (hence them being used in things such as Thaly's Bullet and more than a few aerospace projects.

Yes?

Re: Differences between Ada 83 and other revisions

[yoursurrogategod]

If so, what would be a good book for Ada 2012?

Re: Differences between Ada 83 and other revisions

[Niklas Holsti]

On 14-02-13 23:25 , yoursurrogategod@gmail.com wrote:
> On Thursday, February 13, 2014 2:44:47 PM UTC-5, Niklas Holsti wrote:

>> However, Ada 95 and later Ada standards extend the language beyond Ada
>> 83 in many ways. Some extensions include new kinds of run-time checks
>> for new kinds of run-time errors, which cannot be detected at compile
>> time. Ada 83 had a smaller set of run-time checks and errors, so it can
>> be argued that programs using the Ada 95 and later extensions have an
>> increased risk of failing at run-time even if their compilation succeeds.
>>
>> I don't know if this argument is valid; I don't see an increased risk of
>> run-time failure in my own programming. But I use the new features
>> rather conservatively and sparingly. Moreover, some of the new features
>> make it easier to avoid some Ada 83 -level run-time errors -- for
>> example, controlled types help to avoid errors in memory allocation and
>> deallocation.
>>
> 
> So it would be safe to say that the newer versions of Ada have not
> enabled the creation of less reliable code.

I would say so. You may find other people who disapprove of certain
language details (such as allowing "out" and "in out" parameters for
functions), due to reliability concerns.

> And that the newer versions are overall qualitatively better (hence
> them being used in things such as Thaly's Bullet and more than a
> few aerospace projects.

"Better" is application-specific and perhaps subjective. Certainly the
newer Ada standards are more powerful, but you may not be able to, or
want to, use all the new powerful features in certain applications. For
example, I am currently working in Ada 95, and without the Ada
run-time-system, because this is what the customer has defined as the
HW/SW platform for the application (satellite SW).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Differences between Ada 83 and other revisions

[adambeneschan]

On Thursday, February 13, 2014 2:00:00 PM UTC-8, Niklas Holsti wrote:

> > So it would be safe to say that the newer versions of Ada have not
> > enabled the creation of less reliable code.
> 
> I would say so. You may find other people who disapprove of certain
> language details (such as allowing "out" and "in out" parameters for
> functions), due to reliability concerns.

The one new feature that I think *could* be used to create less reliable code, if abused, is 'Unchecked_Access.

                             -- Adam

Re: Differences between Ada 83 and other revisions

[Randy Brukardt]

<yoursurrogategod@gmail.com> wrote in message 
news:538b7cd3-94c6-44d7-8340-8d411b032e22@googlegroups.com...
> If so, what would be a good book for Ada 2012?

Best place to find Ada books is
  http://www.adaic.org/learn/materials/

Unfortunately, if you go to that page, you won't see any Ada 2012 books 
listed. And that's because we're not aware of any Ada 2012 books that are 
available yet.

John Barnes is working on a a revision of his Programming in Ada for Ada 
2012, but he was delayed by needing to find a new publisher (his old 
publisher having gotten out of the technical book business). He has found a 
publisher, but I don't know when the book will be available.

Several other authors are planning to write Ada 2012 books, but none of 
those are committed yet.

So for now, I recommend using an Ada 2005 book and then reading material 
about the differences (in particular, the Ada 2012 Rationale and Reference 
Manual - http://www.adaic.org/ada-resources/standards/ada12/). The 
differences in existing features between Ada 2005 and Ada 2012 are not 
major, so for the most part you can program the same for both. (Of course, 
you might want to use new features like Preconditions, and for that you'll 
have to look at Ada 2012 materials.) I believe AdaCore also has some useful 
materials on their website.

Good luck learning Ada!

                     Randy Brukardt, AdaIC webmaster (and many other hats).



 

Re: Differences between Ada 83 and other revisions

[yoursurrogategod]

Noted.

One more question.  Can you custom specify floats with a specific number of decimal spaces?  For example, if you want ada to handle decimals that your comp hardware cannot handle.

Also, are the free and open source versions of the ada compiler used often?

Thanks for your help thus far everyone!

Re: Differences between Ada 83 and other revisions

[AdaMagica]

floating_point_definition ::= 
  digits static_expression [real_range_specification]

decimal_fixed_point_definition ::= 
   delta static_expression digits static_expression [real_range_specification]

Re: Differences between Ada 83 and other revisions

[Jacob Sparre Andersen]

yoursurrogategod@gmail.com writes:

> Can you custom specify floats with a specific number of decimal
> spaces?

That sounds like a contradiction.

You can declare floating point types with specific ranges and numbers of
significant digits.  (There are limits to what the compiler is required
to support.)

> Also, are the free and open source versions of the ada compiler used
> often?

Yes.  And also for big, commercial projects.

Greetings,

Jacob
-- 
"You've got to build bypasses!"

Re: Differences between Ada 83 and other revisions

[Robert A Duff]

adambeneschan@gmail.com writes:

> The one new feature that I think *could* be used to create less
> reliable code, if abused, is 'Unchecked_Access.

Well, I think you have to look at the alternatives, rather than
looking at a feature like 'Unchecked_Access in isolation.

Suppose you have an Ada 2012 (or 2005 or 95) program that uses
'Unchecked_Access.  There is a risk of dangling pointers.

But how would you write that code in Ada 83?  Probably you'd
allocate an object on the heap.  And Ada 83 didn't have finalization,
so you have to manage deallocation by hand.  So in Ada 83 you would
have a similar risk of dangling pointers, plus additional risks:
storage leaks, heap fragmentation, etc.

Or perhaps (still talking about Ada 83), you'd use 'Address and
Unchecked_Conversion.  Again, additional risks, such as nonportability
(given that the semantics of 'Address are rather ill defined).
Plus there's no "aliased" there warning you about aliasing.

So although 'Unchecked_Access is indeed an unsafe feature, the
existence of 'Unchecked_Access makes the language safer overall.

I think the same can be said of other supposedly-unsafe features
added to Ada since Ada 83, such as storage pools.

Or consider the assertion facilities ("contracts"): pre/postconditions,
predicates, invariants.  There is a risk that those will raise
an exception and crash the program.  Yet programming using contracts
is clearly safer than the Ada 83 alternatives.

- Bob

Re: Differences between Ada 83 and other revisions

[adambeneschan]

On Friday, February 14, 2014 5:18:22 AM UTC-8, yoursurr...@gmail.com wrote:
> 
> One more question.  Can you custom specify floats with a specific number of decimal spaces?  For example, if you want ada to handle decimals that your comp hardware cannot handle.

I'm not sure just what you're looking for.  Although you can define a floating-point type using a "digits" clause that could, in theory, give you greater precision than your floating-point hardware can handle, in practice I don't think this is possible.  That is, if your machine supports 32-bit and 64-bit IEEE floats, then any floating-point type you define will map to one of those two floats, or will produce an error message at compile time.  A compiler vendor *could* provide additional floating-point types that have to be emulated in software, but the language does not require them to do so, and I don't know of any compiler that does.  [On machines with no floating-point, there is often a C library to emulate it, provided either by the manufacturer or by some other third party; here again, though, Ada compiler vendors are not required to go beyond that.]

When you refer to "decimals", some people have assumed you were talking about "decimal fixed-point".  This is a different kind of numeric type, generally with a fixed number of digits after the decimal point.  For example, this example from the RM defines a type that could be used for currency:

    type Money is delta 0.01 digits 15;

"delta 0.01" means that every numeric value of the type is a multiple of 0.01; thus, this type defines numbers with two digits after the decimal point.  "digits 15" means that the type can handle numbers of up to 15 digits, counting the digits after the decimal point; thus, the type can hold numbers from about -(10**13-1) to 10**13-1.  Those numbers are generally represented as integers, but the compiler keeps track of the scale factor.  So the number 2.35 would be represented internally as the integer 235.  If you multiply two such numbers, the program will multiply the integers and then automatically do any scaling and rounding for you.  [By the way, it's legal to declare a "delta 10.0" or "delta 100.0" type, etc., so that the scale factor is 10**N instead of 10**(-N).]

Here again, though, compilers aren't required to support decimal fixed types that would involve an integer too big for it to handle.  (If the Information Systems Annex is supported, then the compiler has to handle decimal fixed types that require 64-bit integers, but nothing larger.)  There's no language-defined equivalent of Java's BigInteger or BigDecimal, for example, with unlimited numbers of digits; on the other hand, compiler implementations could provide them if the vendor chooses.  Also, it would be incorrect to refer to types like this as "floats", since they're treated basically like integers and don't fit into the traditional definition of "floating-point".

So in any case, I think the answer to your question about numbers that the hardware can't handle is: no, Ada compilers are not required to support such numbers.  However, they're not prevented from doing so.  (And if hardware has no floating-point at all, I think Ada may require the compiler to provide *some* kind of software-emulated floating-point, although I'm not certain.)

                                 -- Adam

Re: Differences between Ada 83 and other revisions

[Martin]

On Thursday, February 13, 2014 10:18:54 PM UTC, adambe...@gmail.com wrote:
> On Thursday, February 13, 2014 2:00:00 PM UTC-8, Niklas Holsti wrote:
> 
> 
> 
> > > So it would be safe to say that the newer versions of Ada have not
> 
> > > enabled the creation of less reliable code.
> 
> > 
> 
> > I would say so. You may find other people who disapprove of certain
> 
> > language details (such as allowing "out" and "in out" parameters for
> 
> > functions), due to reliability concerns.
> 
> 
> 
> The one new feature that I think *could* be used to create less reliable code, if abused, is 'Unchecked_Access.
> 
> 
> 
>                              -- Adam


But at least it spells out that it is potentially dangerous by being called 'Unchecked", like all the other 'Unchecked" parts of the language ...very easy to find!

-- Martin

Re: Differences between Ada 83 and other revisions

[Robert A Duff]

Martin <martin@thedowies.com> writes:

> But at least it spells out that it is potentially dangerous by being
> called 'Unchecked", like all the other 'Unchecked" parts of the
> language ...very easy to find!

If only that were true.  I don't see any "unchecked" here:

    for X'Address use ...;

    X := ...;

It would be great if you could find all unsafe (i.e. potentially
erroneous) code by searching for something like "unchecked".
But alas.

On the bright side, Ada doesn't have very many unsafe features,
and mostly allows them to be avoided and/or encapsulated.
Compare with C, where every array indexing operation is unsafe.

- Bob

Re: Differences between Ada 83 and other revisions

[J-P. Rosen]

Le 16/02/2014 15:13, Robert A Duff a écrit :
>> But at least it spells out that it is potentially dangerous by being
>> > called 'Unchecked", like all the other 'Unchecked" parts of the
>> > language ...very easy to find!
> If only that were true.  I don't see any "unchecked" here:
> 
>     for X'Address use ...;
> 
>     X := ...;
> 
> It would be great if you could find all unsafe (i.e. potentially
> erroneous) code by searching for something like "unchecked".
> But alas.
But AdaControl can find every use of (instantiations of) Unchecked_*,
and all usages of 'Address, or only address clauses that refer to the
address of another object.

There needs to be a boundary between what is checked by the compiler and
what is best handled by external tools; you may not agree to where the
line has been drawn, but tools that can find unsafe features do exist!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Differences between Ada 83 and other revisions

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 16/02/2014 15:13, Robert A Duff a écrit :
>>> But at least it spells out that it is potentially dangerous by being
>>> > called 'Unchecked", like all the other 'Unchecked" parts of the
>>> > language ...very easy to find!
>> If only that were true.  I don't see any "unchecked" here:
>> 
>>     for X'Address use ...;
>> 
>>     X := ...;
>> 
>> It would be great if you could find all unsafe (i.e. potentially
>> erroneous) code by searching for something like "unchecked".
>> But alas.
> But AdaControl can find every use of (instantiations of) Unchecked_*,
> and all usages of 'Address, or only address clauses that refer to the
> address of another object.

That's useful.  Can it find all unsafe features?  There are some
that are quite difficult to detect, such as passing a component
of a variant record to a procedure that causes that component
to vanish.

> There needs to be a boundary between what is checked by the compiler and
> what is best handled by external tools; you may not agree to where the
> line has been drawn, but tools that can find unsafe features do exist!

I didn't mention any compiler checking up there.  I said "search".
I'm asking for a language-design principle that says "you cannot use
any unsafe feature without with-ing a package called Unsafe, or a descendant
thereof".  Then a simple search for "unsafe" finds them all, without
any need for sophisticated tools.

Can you name all the unsafe features of Ada off the top of your head,
and tell what strings to search for to find them?  I can't.  You can
find them by looking up "erroneous" in the Index.

(C is far worse in that regard!)

- Bob

Re: Differences between Ada 83 and other revisions

[J-P. Rosen]

Le 19/02/2014 23:09, Robert A Duff a écrit :
>> But AdaControl can find every use of (instantiations of) Unchecked_*,
>> and all usages of 'Address, or only address clauses that refer to the
>> address of another object.
> 
> That's useful.  Can it find all unsafe features?  There are some
> that are quite difficult to detect, such as passing a component
> of a variant record to a procedure that causes that component
> to vanish.
Not this one, currently. But if you are willing to fund the development
of this check, I'll be very happy to add it!

>> There needs to be a boundary between what is checked by the compiler and
>> what is best handled by external tools; you may not agree to where the
>> line has been drawn, but tools that can find unsafe features do exist!
> 
> I didn't mention any compiler checking up there.  I said "search".
> I'm asking for a language-design principle that says "you cannot use
> any unsafe feature without with-ing a package called Unsafe, or a descendant
> thereof".  Then a simple search for "unsafe" finds them all, without
> any need for sophisticated tools.
> 
> Can you name all the unsafe features of Ada off the top of your head,
> and tell what strings to search for to find them?  I can't.  You can
> find them by looking up "erroneous" in the Index.
> 
Right, but be careful not to throw the baby with the bathwater. You can
find many of the unsafe features, and that's much better than any other
language!
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Differences between Ada 83 and other revisions

[adambeneschan]

On Wednesday, February 19, 2014 2:09:31 PM UTC-8, Robert A Duff wrote:

> (C is far worse in that regard!)

It's actually very easy to list all the unsafe features of C.

1)  C

                   -- Adam

Re: Differences between Ada 83 and other revisions

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Right, but be careful not to throw the baby with the bathwater. You can
> find many of the unsafe features, and that's much better than any other
> language!

It's certainly much better than C in that regard.  But given that Java
doesn't have any unsafe features (if you don't count interfacing to C),
...

- Bob

Re: Differences between Ada 83 and other revisions

[Robert A Duff]

adambeneschan@gmail.com writes:

> On Wednesday, February 19, 2014 2:09:31 PM UTC-8, Robert A Duff wrote:
>
>> (C is far worse in that regard!)
>
> It's actually very easy to list all the unsafe features of C.
>
> 1)  C

;-)

Yeah, I guess that's one way to look at it.  In C, array indexing,
addition, multiplication, and many other commonly-used features
are all unsafe.  In the original K&R C, even function calls were
unsafe, but fortunately they (mostly) fixed that.

To be fair, pointer dereferencing is unsafe in both Ada and C,
so the feature I was asking for ("find all usage of unsafe features")
wouldn't work very well even in Ada -- too many false alarms.
Pointer dereferencing could be made safe.

- Bob

Re: Differences between Ada 83 and other revisions

[john]

On Thursday, 13 February 2014 23:31:14 UTC, Randy Brukardt  wrote:

<..snip..>

> Unfortunately, if you go to that page, you won't see any Ada 2012 books 
> listed. And that's because we're not aware of any Ada 2012 books that are 
> available yet.
> 
> John Barnes is working on a a revision of his Programming in Ada for Ada 
> 2012, but he was delayed by needing to find a new publisher (his old 
> publisher having gotten out of the technical book business). He has found a 
> publisher, but I don't know when the book will be available.

Interesting. Given the level of demand I'd expect to see for that (probably fairly small :-() I'd have thought using Lulu (http://www.lulu.com) or some other "publish yourself" organisation would be a good choice.

Re: Differences between Ada 83 and other revisions

[Jacob Sparre Andersen]

Robert A Duff wrote:

> It's certainly much better than C in that regard.  But given that Java
> doesn't have any unsafe features (if you don't count interfacing to
> C), ...

What about the facilities in Java making it easier to leak
non-primitive, private attributes than not to do so?

(It is of course not an error in the sense that the programmer may
actually want to shoot himself in the foot.)

Greetings,

Jacob
-- 
"Facts are stubborn, but statistics are more pliable." -- Mark Twain