Re: Beginners question: Compound types, how-to?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 03.11.10 13:59, Georg Bauhaus wrote:

> Can a name placed before ':' be a type at all?
> That's a good thing because it remove one decision.
> 
> Every "if" requiring context makes the number of
> possible interpretations grow exponentially.
> Reading effort is higher, which might be not so good.

This was as clearly stated as the sky is, today.
Let me try again.

A name appearing before a ':' is not a type name.
Suppose a name appearing there is a homograph of a
type name.  In this case the reader will be
asking herself: "What kind of entity is this name
designating, a parameter, a type, something else?"
If such-and-such, it is a type name, if so-and-so,
it is a parameter name.  Or maybe even ...

So there are a number of ifs to be answered when you
want to decide what kind of entity is before you.

Ada grammar helps reducing the number of ifs
to be answered, but only to some extent.

For example,

procedure Increment (Integer : in out Integer) is
begin
   Integer := Integer'Succ(Integer);
end Increment;

This is decipherable both by compilers and by humans,
even when it is wrong (you couldn't otherwise say
that it is wrong.)

If you think that any of the following alternative
definitions look better, can you say why in each case?
And in which programming situations?

I don't think that the examples hinge only on programmers'
familiarity with type(!) name "Integer" (fixed in our
minds to be a type's name).  Trying another pair of names
shouldn't make a big difference.

1) Like Dmitry mentioned

procedure Increment (An_Integer : in out Integer) is
begin
   An_Integer := Integer'Succ(An_Integer);
end Increment;


2) IIRC, Bill Findlay uses this one (though not the name
"Integer" used for parameter names, I should think).
Apologies for dropping the name if not:

procedure Increment (Integer : in out An_Integer) is
begin
   Integer := An_Integer'Succ(Integer);
end Increment;


3) Stephen Leake's private rule:

procedure Increment (Integer : in out Standard.Integer) is
begin
   Integer := Standard.Integer'Succ(Integer);
end Increment;


4) The preference for _Type

procedure Increment (Integer : in out Integer_Type) is
begin
   Integer := Integer_Type'Succ(Integer);
end Increment;



5)  Combine (1) and (4) to get

procedure Increment (An_Integer : in out Integer_Type) is
begin
   An_Integer := Integer_Type'Succ(An_Integer);
end Increment;

But of course no one will be mixing styles. Never, right?

And the only confusion can ever arise from my weird
use of the name "Integer"?  OK, then, for example,

procedure Increment (T : in out T_Type) is
begin
   T := T_Type'Succ(T);
end Increment;

Try the other examples with different names, too.

Do you think that T always denotes a type?
Or only if used in this or that position?

All examples seem worthless;  the names are meaningful
only when program text is written to allude to language
defined things.  Such examples as use P for
packages, R for records, F for fields, and so on.

I expect that real programs leave much less difficulty
in choosing names that to *not* allude to Ada issues.
They will denote things from the problem domain, even
when the domain is a fairly abstract one.