Inferring array index type from array object
in [ADA]
|
From: J-P. Rosen on 23 Jun 2010 08:52 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 23 Jun 2010 09:12 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 23 Jun 2010 10:27 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 23 Jun 2010 10:38 "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 23 Jun 2010 11:17
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 |