Inferring array index type from array object
in [ADA]
|
From: Niklas Holsti on 23 Jun 2010 16:24 Peter C. Chapin wrote: > 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. Another, perhaps more readable way would be to introduce some attributes that return types: I : S'Index_Type; Y : X'Type; > 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. I would not call these examples "type inference", as they require no global or even subprogram-wide analysis. The desired type can be derived directly from what is written locally (and, of course, from the meaning of the identifiers). > 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. The type of implicitly declared loop index variables (for I in S'Range loop) needs only local analysis, so I would not call it type inference. Resolution of overloaded subprogram and operator names is much more complex and could deserve to be called type inference. But even that requires only local analysis, although (I believe) it needs more than one traversal of the syntactic structure of the (nested) call. "Real" type inference would be needed if these suggestions were extended to let variables be declared using the return type of an overloaded function call, with the overload resolution extended to take constraints from the use-sites of the variable. I won't try to give an example of that, as I agree with Peter that such non-local type inference would be against the Ada way. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Niklas Holsti on 23 Jun 2010 16:39 Warren wrote: > Niklas Holsti expounded in news:88ec2vF3uqU1(a)mid.individual.net: >> Dmitry A. Kazakov wrote: >>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote: > .. >>>> 2. Is it possible to declare the index variable without hardcoding >>>> the index type (that is, to infer it from the array object)? >>> No, without improving the type system. E.g. introducing abstract >>> index types, and abstract range types (or more general sets of index >>> types), and abstract composite types like arrays. >> 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 ...". > > I think most would agree that this is a "convenience" feature. Yes, but in other contexts, when we advocate Ada, we often make a big point of the "convenience" of the 'Range attribute for arrays, such as "No need to pass extra parameters for array index bounds, just use 'Range". The suggestion to let variables be declared by the "type" S'Range (or, if desired, a new attribute S'Index_Type) has a similar advantage (but a weaker one, I admit). > I think the language (and its compiler) is probably complicated > enough for these types of additions. Don't forget each new feature > requires a "test suite" and validation, in addition to the > compiler itself. Yes, of course. But as time goes on, and as long as the extensions are backwards compatible, I think the compiler writers and validators could live with a growing test and validation suite. But then I am not one of those guys... On the other hand, I do worry about language and compiler complexity. If the creation and maintenance of Ada compilers is very costly and difficult, it creates a risk for the survival of Ada, as well as a brake on the evolution of Ada. When we talk about "the Ada way", it seems to me that we have in mind a simpler and more elegant and uniform thing than the current Ada language -- some "core of Ada" that perhaps could be defined and implemented in an easier way. I suspect that Dmitry has the same feeling, which is why he keeps suggesting (or dreaming about) such large and fundamental changes to Ada. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: J-P. Rosen on 24 Jun 2010 02:16 Robert A Duff a �crit : > I'd suggest something like "default_integer_range". It's not just > for 'for' loops -- the same language malfeature occurs for array > type decls, for example. > The "_for" is because I have separate rules for loops, indexing, case statements... -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Georg Bauhaus on 24 Jun 2010 03:25 On 6/23/10 9:09 PM, Simon Wright wrote: > "J-P. Rosen"<rosen(a)adalog.fr> writes: > >> 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? > > Formal types, yes, not so sure about formal objects. Consider eg a > generic signature package .. > > generic > > type Severity_Code is (<>); > -- Messages are logged with this indication of severity. > > Error : Severity_Code; > -- This value is used for error messages. > > Informational : Severity_Code; > -- This value is used for informational messages. > > with procedure Log (Severity : Severity_Code; Message : String); > > package Logging_Signature is > > -- Make the actual instantiation parameters visible. > package Exported is > Error : Severity_Code renames Logging_Signature.Error; > Informational : Severity_Code renames Logging_Signature.Informational; > procedure Log (Severity : Severity_Code; Message : String) > renames Logging_Signature.Log; > end Exported; > Similarly, without reference to names outside the generic, at least as a temptation: If some container has a "regular interface", one can think of an algorithm in terms of names that from the container only. with Some_Container; generic with package Collection is new Some_Container (<>); procedure Copy (input: Collection.T; output: in out Collection.T); -- copies objects of type Collection.E, -- from and to objects of type Collection.T, -- pointed to by objects of type Collection.Cursor. generic type Element_Type is private; package Some_Container is subtype E is Element_Type; type ... Set, List, Map, ... is private; subtype T is ... Set, List, Map, ...; ... type Cursor is private; ... private ... end Some_Container; OTOH, it might be OK to make the Copy procedure from above a child of Some_Container. Since everything needed by Copy is then "exported" by Some_Container to children, this might do. (It is not a solution to Simon's case, though, I guess.)
From: Warren on 28 Jun 2010 09:44
Niklas Holsti expounded in news:88f9osFmcmU1(a)mid.individual.net: > Warren wrote: >> Niklas Holsti expounded in news:88ec2vF3uqU1(a)mid.individual.net: >>> Dmitry A. Kazakov wrote: >>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote: >> .. >>>>> 2. Is it possible to declare the index variable without hardcoding >>>>> the index type (that is, to infer it from the array object)? >>>> No, without improving the type system. E.g. introducing abstract >>>> index types, and abstract range types (or more general sets of index >>>> types), and abstract composite types like arrays. >>> 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 ...". >> >> I think most would agree that this is a "convenience" feature. > > Yes, but in other contexts, when we advocate Ada, we often make a big > point of the "convenience" of the 'Range attribute for arrays, such as > "No need to pass extra parameters for array index bounds, just use > 'Range". The suggestion to let variables be declared by the "type" > S'Range (or, if desired, a new attribute S'Index_Type) has a similar > advantage (but a weaker one, I admit). But how far down that road do you want to go? This is the crux of the issue. I'd find ++X or X += n convenient. But should that be implemented in Ada? I'm ok with leaving it out. At some point, you have to draw a line in the sand. Warren |