From: J-P. Rosen on
Georg Bauhaus a �crit :
> Is the required name somehow related to why the Ada.Container generics
> do not re-export the formal types?
>
Not sure what you meant by this, but outside the instantiation, you are
supposed to know how it was instantiated, therefore you have access to
the actuals. Why would you need to reexport the formals?

--
---------------------------------------------------------
J-P. Rosen (rosen(a)adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
From: Gautier write-only on
Perhaps empty ranges have played a role for designers not going too
far into defining what you would like (some "subtype S_range is
S'Range", or "type S_range is new S'Range" ?) ?

procedure String_range is
subtype Index_empty is Positive range 1..0;
I1: Index_empty:= Index_empty'First;
--
S: constant String:= "";
I2 : Positive range S'Range:= S'First;
begin
null;
end;

There, GNAT produces a Constraint_Error for any of I1 or I2, on the :=
lines.

G.
From: Peter C. Chapin on
Niklas Holsti wrote:

> I don't think such large language changes would be necessary. The
> expression S'Range gives the compiler all the information about the type
> and its constraints, so I see no reason why Ada could not be extended
> simply to allow S'Range in a variable declaration, as in the above
> quoted "I : S'Range". The declared variable "I" would have the same
> (sub)type as the loop counter in "for I in S'Range loop ...".

This seems weird to me. S'Range is a range, not a type. I agree that it
includes type information, but then so does an object.

X : Integer;
Y : X; -- Let Y have the same type as X. Weird.

Type inference is a big subject and while it can be very nice in languages
that support it comprehensively, type inference doesn't really seem like
the "Ada way" to me. In any case, once you start supporting type inference in
any form you have to wonder just how far down that road you want to go. Right
now Ada only infers types in one very limited case (right?)... that is in
support of implicitly declared loop index variables.

Peter

From: Robert A Duff on
"J-P. Rosen" <rosen(a)adalog.fr> writes:

> Dmitry A. Kazakov a �crit :
>>> I would like to declare I as a free variable instead and I would
>>> expect some symmetry in the language by doing this:
>>>
>>> I : S'Range := S'First;
>>
>> subtype Index_Span is Integer range S'Range;
>> I : Index_Span := S'First;
> Or simply:
> I : Positive range S'Range;

Right. And as others have noted, beware null ranges.

>>> 1. What is the standard justification for this assymetry?
> This is a simplification of loops, to avoid some typing to the user.
> Think of it the other way round: since a for loop involves the
> declaration of an object, the type should always be explicitely declared
> (a coding rule that I apply - of course checkable by AdaControl):
>
> for I in positive range 1..10 loop ...
> for I in positive range S'Range loop ...

I see those two lines as very different.

I agree with you on the first line. In "for I in 1..10",
Ada takes a "wild guess", and says the type is Integer.
That's a language design mistake, and I always like
to make the type explicit, as shown above. Well,
almost always -- I might leave it implicit if I is never
mentioned, as in:

-- Print "Hello" ten times:
for I in 1..10 loop
Put_Line ("Hello");
end loop;

But in the second example, I'm perfectly happy with leaving
the type implicit:

for I in S'Range loop
... S(I) ...

because this code really doesn't care what the index type is.
We're saying "the type of I is whatever the index type of S
is, and we don't need to name it here".

Can AdaControl check my style rule -- complain if I depend
on the default-to-integer rule, but not complain if the
type of the loop index is properly deducible from the
stuff between "in" and "loop"?

Note that Ada 2012 will (probably) eliminate the need for
I altogether, which is a good thing, since I is just an
extraneous thing -- we really want to talk about the
components of S here, not their index values.

> So it is really symetrical, except that in the case of a loop, you are
> allowed to "simplify" by omitting the "<type> range" part - forcing the
> compiler to deduce the type from the range, which is not a good idea IMHO.

Why is that a bad idea (in the second case)?

- Bob
From: J-P. Rosen on
Robert A Duff a �crit :
>> for I in positive range 1..10 loop ...
>> for I in positive range S'Range loop ...
> [...]
>
> But in the second example, I'm perfectly happy with leaving
> the type implicit:
>
> for I in S'Range loop
> ... S(I) ...
>
> because this code really doesn't care what the index type is.
Yes, but OTOH it is nice to say that werever an object is declared, its
type appears on the same line. And if you want to make a rule, it is
always simpler to say "do that" than "do that, except when..."

> Can AdaControl check my style rule -- complain if I depend
> on the default-to-integer rule, but not complain if the
> type of the loop index is properly deducible from the
> stuff between "in" and "loop"?
Not yet, although it would be a very simple addition. The hardest part
would be to find an acceptable name for the rule. The current one is:

check declarations (anonymous_subtype_for);

and I wouldn't like:
check declarations (anonymous_subtype_except_range_for);
;-)


>> So it is really symetrical, except that in the case of a loop, you are
>> allowed to "simplify" by omitting the "<type> range" part - forcing the
>> compiler to deduce the type from the range, which is not a good idea IMHO.
>
> Why is that a bad idea (in the second case)?
>
As noted before, it would be so simpler to say "no type inference". In
general, in the rare cases where Ada tried to save some typing, it was a
bad idea...
--
---------------------------------------------------------
J-P. Rosen (rosen(a)adalog.fr)
Visit Adalog's web site at http://www.adalog.fr