Re: more to ada paper critic

["Grein, Christoph" <christoph.grein@eurocopter.com>]

> >       -- Define the number of cards in a standard deck.
> >    subtype Deck_Index is integer range 1..52;
> 
> AFAIK this means a Deck_Index IS A integer, right? So maybe I would prefer
> "type Deck_Index is new integer range 1..52;", because an index is not
> normaly an integer. What do you say?

or even better:
    type Deck_Index is range 1..52;

> 
> > Note that this package specification defines the types Card and Deck
> > as private types. This allows another compilation unit to know that
> > there are types called Card and Deck, but not to know their
> > structure. The Ada package provides encapsulation and namespace.
> 
> Hm, but the other programmers still SEE the current structure.

No, they don't see it. Visibility is a technical term defined in the RM, and to 
be able to see something (i.e. something being visible) does not mean that you 
(as a human) can read the declaration in the Ada specification. It comes after 
the keyword private, so its invisible.

> IMHO if the
> structure should be hidden, it would be better to only declare the names of
> the types so that even other _coders_ does not know the structure.
> Like C/C++ 's header-declaration approach (if you do it right in C).

If you want to do this, you have to use access types.

> > The definitions are placed in a separate
> > file called the package body.
> 
> HAS they to be in a seperate file? I think not so. (But it is good, that
> they CAN ;-)

Depends on you compiler. E.g. Gnat wants them in separate files, Aonix doesn't.

> Are there any swap - template (or "generic" ;-) in the standard-library?

No, it's so simple.

> The difference between procedure and function seem to be, that procedure has
> in/out modifiers while function has a return-value, right? What is the
> default for functions? Are the parameter all "in" or "in out" ?

Default mod (if omitted) is in. Function can only have in.

> > Variable initialization is performed during an elaboration step
> > which is performed before normal program execution begins. This
> > ensures that the All_Decks variable is properly initialized with
> > no race conditions.
> 
> Oh come. Arent there race conditions when initializing more than these
> "before the main"s. This solution seems quite similar to C++'s problem of
> initializing global statics. Example: (forgive any syntax-errors I havent
> got GNAT to run until now ;-)
> 
> 
> function Prob1 return integer is
> begin
>   return Var2;
> end Prob1;
> 
> function Prob2 return integer is
> begin
>   return Var1;
> end Prob2;
> 
> Var1 : constant integer := Prob1;  -- Var2 unitialized, will return
                                     -- unspecified value
> Var2 : constant integer := Prob2;  -- ditto

Elaboration is done sequentially, no race condition.

> >       Cards.Deal(The_Card => This_Card, From => My_Deck);
> 
> looks funny :)

Admittedly in this case, named notation is not very useful. If you get used to 
Ada, you'll find places where it helps:

Drive (My_Car, True);

does not say you what it True. If you used named notation:

Drive (My_Car, Restricted_Use => True);

> What happens if you do not catch the exception? Will then some kind of
> terminate() be called (similar to C++?) or just reported and step on (like
> Java)?
> 
> Can I declare exceptions, so that user of my functions MUST catch the
> exception?

You need not handle the exception. If you don't your program (more exactly, the 
actual task) will die.

> > You can also see another feature of Ada syntax in this example. That is
> > the ability to pass parameters to functions and procedures by name. You
> > also see instances where they are passed by position.
> 
> Yes. But this is really only sugar and does not improve calling security.
> The most important thing about order of Parameters is, when a library
> supporter has to decide to swap Parameters of functions. Since he cannot
> decide this safely (because there might be callings without naming) it is
> almost useless to know, that user of libraries MIGHT call with secure
> naming...
> 
> The only advantage comes from more readible code.

This is more than sugar, think of arctan (y, x) versus arctan (x => y, y => x)

Confused?
 
> Or are there possibilities to force the parameter-naming? This would be
> great!

No