Ada and Ada 2012 – Overview and rationale

Ada and Ada 2012 – Overview and rationale
Quentin Ochem
Technical Account Manager

Copyright © 2012 AdaCore Slide: 1

Why Programming
Languages Matter?


Presentation Scope

• In High-Reliable Software, the choice is usually
being made between
– C
– C++
– Java
– Ada

• What are the criteria for this choice?

• What are the implications of this choice?


Human Resources Criteria

• There are more people that know C++ than Ada

• There are more people that know C than C++

• There are more people trained in Java than C or
C++

• So from a HR point of view, the choice is
obviously…


Human Resources Criteria

Visual Basic


Is Programmers‟ Language Skill an Issue?

• Main software paradigms are key
– Object orientation
– Pointers
– Stack
– Exceptions
– …

• Applying these skills to any programming
language should be easy for any developer


Show-Stopper Criteria

• Is the language supported by the industry?

• Does the language have perspectives for long term development?

• Is the language properly supported by tools?

• Does the language generate efficient code?

• Is the language supported on the target architectures?

• Can the language support generic programming paradigms?

All four languages, C, C++, Java and Ada fulfill these requirements


Other Criteria of Interest

• What direction does the evolution of the language take?

• What are the primary markets using this language?

• Is the language defined by a public or private entity?

• Can the language support the full development cycle
(specification/code/verification)?

• Can the language help in the writing more reliable code?

• Can the language help in the writing more maintainable code?


Goal: Reducing Costs (Finding Errors and Inconsistencies Earlier)

Problem Found
Fix Cost


Goal: Finding Errors and Inconsistencies Earlier

Problem Found
Fix Cost


Easing the Reaching Higher Levels of Reliability

Reliability
Achieved

Developer
Responsibility

Tool
Responsibility

Language
Responsibility

C/C++ Java Ada


How do we get there?


The One-Line-Of-Code Hell

• Is “tab” null? Can’t tell.

• Is “tab” an array? Can’t tell.

• Is i within the boundaries of “tab”? Can’t tell.

tab [i] = tab [i] / 10;

• Has “tab” been initialized? Can’t tell.

• Is “tab” expecting floats or integers? Can’t tell.

• If it‟s float, is this a float or a integer division? Can’t tell.


The One-Line-Of-Code Hell

• Is “tab” null? No, tab is an array.

• Is “tab” an array? Yes, otherwise can’t access the indices.

• Is i within the boundaries of “tab”? Checked at run-time.

tab (i) := tab (i) / 10;

• Has “tab” been initialized? Can’t tell.

• Is “tab” expecting floats or integers? If float, compiler runtime.

• If it‟s float, is this a float or a integer division? If needed, explicit conversion.


Driving Design Principles

• Be explicit as much as possible
– Put as much (formal) information as possible in the code
– Put as much (formal) information as possible in the specification
– Avoid pointers as much as possible
– Avoid shortcuts
– Avoid ambiguous constructs as much as possible
– Make dubious constructs possible but visible

int * i = malloc (sizeof (int));

i++;

type I_Acc is access all Integer;
I : I_Acc := new Integer;
function Acc_To_Int is new Ada.Unchecked_Conversion (I_Acc, Integer);
function Int_To_Acc is new Ada.Unchecked_Conversion (Integer, I_Acc);

I := Int_To_Acc (Acc_To_Int (I) + I_Acc’Size);


Driving Rationale

• Ada eases manual and automatic analysis at various levels:
– Developer review
– Peer review
– Compiler errors and warnings
– Static analysis tools
– Proof tools
– Maintenance

• Simplify code and readability when dealing with high-level programming
concepts
int [] a = new int [10];

a [0] = 1; a [1] = 1;
for (int i = 2; i < 10; i++) a [i] = 0;

A : Integer_Array (0 .. 10) := (0 => 1, 1 => 1, others => 0)


Strong Typing

• A type is a semantic entity, independent from its implementation

• Strong typing forbids implicit conversions

type Kilometers is new Float;
type Miles is new Float;

Length_1 : Miles := 5.0;
Length_2 : Kilometers := 10.0;
D : Kilometers := Length_1 + Length_2;

• Values are checked at run-time (can be deactivated)

type Ratio is new Float range 0.0 .. 100.0;
Qty : Integer := 10;
Total : Integer := 1000;

R : Ratio := Ratio (Total / Qty) * 100.0;

Strong typing (continued)

• Enumerations have a dedicated semantic

type Color is enum Color
(Red, Blue, White, Green, Black, Yellow); {Red, Blue, White, Green, Black, Yellow};
type Direction is (North, South, East, West); enum Direction {North, South, East, West);
type Light is (Green, Yellow, Red);
Color C = Red;
C : Color := Red; C = West; // Ok, but what does it mean?
-- This is the red from Color C = 666; // Ok, but what does it mean?
L : Light := Red;
-- This is the red from Light

C := L; -- This is not permitted
C := North; -- This is not permitted


Arrays

• Arrays can be indexed by any discrete types
(integers, enumeration)
• First and Last index can be specified at declaration time
• Buffer overflows are checked at run-time
• There is an array literal (aggregate)

type Some_Array is array (Integer range <>) of Integer;
type Color_Array is array (Color range <>) of Integer;

Arr1 : Some_Array (10 .. 11) := (666, 777);
Arr2 : Color_Array (Red .. Green) := (Red => 0, others => 1);

Arr1 (9) := 0; -- Exception raised, Index out of range


Array Copy, Slicing and Sliding

• Arrays provide a high-level copy sematic

type Integer_Array is array (Integer range <>) of Integer;
V1 : Integer_Array (1 .. 10) := (others => 0);
begin
V1 := V2;

• Arrays provide a high level slicing/sliding sematic

type Integer_Array is array (Integer range <>) of Integer;
begin
V1 (1 .. 2) := V2 (11 .. 12);


Parameter Modes

• Three parameter modes : in (input), out (output) and in-out
(input/output)
• The correct parameter usage is done at compile-time

procedure Do_Something
(P1 : in Integer; -- P1 can’t be changed
P2 : out Integer; -- No initial value on P2
P3 : in out Integer) -- P3 can be changed

• The compiler decides if it has to be passed by reference or copy

• This is a case of explicit pointer avoidance

procedure Do_Something
(P1 : in Huge_Structure) –- Passed by reference if too big


Pre, Post Conditions and Invariants

• Generalized contracts are available through pre- and post-
conditions

procedure P (V : in out Integer)
with Pre => V >= 10,
Post => V’Old /= V;

• New type invariants will ensure properties of an object

type T is private
with Type_Invariant => Check (T);

• Subtype predicates

type Even is range 1 .. 10
with Dynamic_Predicate => Even mod 2 = 0;


Package Architecture

• All entities are subject to encapsulation
– Not only OOP constructions

• Specification and Implementation details are separated from the package,
addresses any kind of semantic entity

package Stack is

procedure Push (V : Integer);

...
package body Stack is
end Stack;
procedure Push (V : Integer) is
begin

...

end Stack;


Privacy

• A package contains well identified public and private parts
• The user can concentrate on only one part of the file

package Stack is

procedure Pop (V : out Integer);

private

type Stack_Array is array (1 .. 1000) of Integer;
Current_Pos : Integer := 0;

end Stack;


Private Types

• A private type can be implemented by any data structure

package Stack is

procedure Pop (V : out Integer);

private

type Stack_Array is array (1 .. 1000) of Integer;
Current_Pos : Integer := 0;

end Stack;

• User code does not rely on the actual representation


Data Representation

• Allows to optimize memory usage
• Allows to precisely map data

type Size_T is range 0 .. 1023;

type Header is record
Size : Size_T;
Has_Next : Boolean;
end record;

for Header use
record
Size at 0 range 0 .. 10;
Has_Next at 1 range 6 .. 6;
end record;


Genericity

• Instanciation has to be explicit

generic template <class T>
type T is private; class P {
package P is public
V : T; static T V;
end P; };

package I1 is new P (Integer); P <int>::V = 5;
package I2 is new P (Integer); P <int>::V = 6;

I1.V := 5;
I2.V := 6;


Object Orientation

• Ada implements full OOP principles
– Encapsulation
– Inheritance
– Dispatching

• Safe OOP paradigm is implemented
– A unique concrete inheritance tree
– Multiple interface inheritance
– “Overriding” methods can be checked

• OOP can be comfortably used without (explicit) pointers


Object Orientation Example

type Root is tagged record
F1 : Integer;
end record;

not overriding
function Get (Self : Root) return Integer;

type Child is new Root with record
F2 : Integer;
end record;

overriding
function Get (Self : Child) return Integer;

List : Root_List; Total := 0;

L.Add (Root’(F1 => 0)); for Item of List loop
L.Add (Root’(F1 => 1)); Total := Total + Item.Get;
L.Add (Child’(F1 => 2, F2 => 0)); end loop;


If pointers are needed…

• Pointers are typed, associated with accessibility checks
• Objects that can be pointed are explicitly identified
• In the absence of de-allocation, pointers are guaranteed to never dangle
• Pointers‟ constraints can be specified
– Is null value expected?
– Is the pointer constant?
– Is the object pointed by the pointer constant?

type My_Pointer is access all Integer;

Global_Int : aliased Integer;

function Get_Pointer (Local : Boolean) return My_Pointer is
Local_Int : aliased Integer;
Tmp : My_Pointer;
begin
if Local then
Tmp := Local_Int’Access; Tmp := Local_Int‟Unchecked_Access;
else
Tmp := Global_Int’Access;
end if;

return Tmp;
end Get_Pointer;


Concurrent Programing

• Threads and semaphore are first class citizens

task Some_Task is
begin
loop
-- Do something
select
accept Some_Event do
-- Do something
end Some_Event;
or
accept Some_Other_Event do
-- Do something
end Some_Other_Event;
end select;
end loop;
end;

...

Some_Task.Some_Event;


Why is all of this of any use?

• For readability
– Specification contains formally expressed properties on the code
• For testability
– Constraints on subprograms & code can lead to dynamic checks
enabled during testing
• For static analysis
– The compiler checks the consistency of the properties
– Static analysis tools (CodePeer) uses these properties as part of its
analysis
• For formal proof
– Formal proof technologies can formally prove certain properties of
the code (High-Lite project)


Yes But…

• It is possible to reach similar levels of safety with other
technologies (MISRA-C, RT-Java)

• … but safety features have to be re-invented
– Requires additional guidelines
– Requires additional tools
– Limited by the original language features

• Examples of “circle fits in a square” features
– Types management in MISRA-C
– Stack emulation in RT-Java

• When long term reliability is a goal, using the correct paradigm to start with
will reach higher levels at lower cost


Key Messages


Ada Evolution

Ada 2012
• Pre / Post /
Ada 2005 Invariants
• Interfaces • Iterators
• Containers • New
Ada 95 • Better expressions
• Object Limited • Process
Orientation Types Affinities
• Better Access • Ravenscar
Ada 83 Types
• Protected
Types
• Child
Packages

In out parameters for functions

• Ada 83 to 2005 forbids the use of in out for function
• Since Ada 95, it‟s possible to workaround that with the
access mode (but requires the explicit use of an access)
• Ada 2012 allows „in out‟ parameters for functions

function Increment (V : in out Integer) return Integer is
begin
V := V + 1;
return V;
end F;


Aliasing detection

• Ada 2012 detects “obvious” aliasing problems

function Change (X, Y : in out Integer) return Integer is
begin
X := X * 2;
Y := Y * 4;

return X + Y;
end;

One, Two : Integer := 1;

begin

Two := Change (One, One);
-- warning: writable actual for "X" overlaps with actual for "Y“

Two := Change (One, Two) + Change (One, Two);
-- warning: result may differ if evaluated after other actual in expression


Pre, Post conditions and Invariants

• The Ada 2012 standard normalizes pre-conditions, post-
conditions

procedure P (V : in out Integer)
with Pre => V >= 10,
Post => V’Old /= V;

• New type invariants will ensure properties of an object

type T is private
with Type_Invariant => Check (T);

• Subtype predicates

type Even is range 1 .. 10
with Dynamic_Predicate => Even mod 2 = 0;


Conditional expressions

• It will be possible to write expressions with a result
depending on a condition

procedure P (V : Integer) is
X : Integer := (if V = 10 then 15 else 0);
Y : Integer := (case V is when 1 .. 10 => 0, when others => 10);
begin
null;
end;


Iterators

• Given a container, it will be possible to write a simple loop
iterating over the elements
• Custom iterators will be possible

Ada 2005 Ada 2012
for X in C.Iterate loop
X : Container.Iterator := First (C); -- work on X
Y : Element_Type; Y := Container.Element (X);
declare -- work on Y
while X /= Container.No_Element loop end loop;
-- work on X
Y := Container.Element (X);
-- work on Y
X := Next (X); for Y of C loop
end loop; -- work on Y
end loop;


Quantifier expressions

• Checks that a property is true on all components of a
collection (container, array…)

type A is array (Integer range <>) of Integer;

V : A := (10, 20, 30);
B1 : Boolean := (for all J in V’Range => V (J) >= 10); -- True
B2 : Boolean := (for some J in V’Range => V (J) >= 20); -- True


Generalized memberships tests

• Memberships operations are now available for all kind of
Boolean expressions

Ada 2005 Ada 2012

if C = ‘a’
or else C = ‘e’
or else C = ‘i’
or else C = ‘o’ if C in ‘a’ | ‘e’ | ‘i’
or else C = ‘u’ | ‘o’ | ‘u’ | ‘y’ then
or else C = ‘y’
then

case C is
when ‘a’ | ‘e’ | ‘i’
| ‘o’ | ‘u’ | ‘y’ =>


Expression functions

• Function implementation can be directly given at
specification time if it represents only an “expression”

function Even (V : Integer) return Boolean
is (V mod 2 = 0);


Containers

• Ada 2005 containers are unsuitable for HIE application
– Rely a lot of the runtime
– Not bounded

• Ada 2012 introduces a new form of container, “bounded”
used for
– HIE product
– Statically memory managed
– Static analysis and proof


Processor affinities

• Task can be assigned to specific processors
• Enhances control over program behavior
• Enables Ravenscar on multi-core

task body T1 is
pragma CPU (1);
begin
[…]
end T1;

task body T2 is
pragma CPU (2);
begin
[…]
end T2;


Ada 2012 safety improvements

• Improve readability
– Specification contains formally expressed properties on the code
• Improve testability
– Constraints on subprograms & code can lead to dynamic checks
enabled during testing
• Allow more static analysis
– The compiler checks the consistency of the properties
– Static analysis tools (CodePeer) uses these properties as part of its
analysis
• Allow more formal proof
– Formal proof technologies can prove formally certain properties of
the code (High-Lite project)


Ada and Ada 2012 – Overview and rationale

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Ada and Ada 2012 – Overview and rationale

Ähnlich wie Ada and Ada 2012 – Overview and rationale (20)

Mehr von AdaCore

Mehr von AdaCore (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Ada and Ada 2012 – Overview and rationale