* Ada.Locales pseudo-string types @ 2012-08-06 16:45 Marius Amado-Alves 2012-08-06 17:10 ` Marius Amado-Alves ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 16:45 UTC (permalink / raw) Ada 2012 has this new Ada.Locales package (annex A.19) containing type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; type Country_Code is array (1 .. 2) of Character range 'A' .. 'Z'; Language_Unknown : constant Language_Code := "und"; Country_Unknown : constant Country_Code := "ZZ"; function Language return Language_Code; function Country return Country_Code; Now how does one print the darn codes? Should not Ada.Text_IO.Put for String work? Should not the types be convertible to String? Thanks a lot. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 16:45 Ada.Locales pseudo-string types Marius Amado-Alves @ 2012-08-06 17:10 ` Marius Amado-Alves 2012-08-06 19:15 ` J-P. Rosen 2012-08-06 19:49 ` Jacob Sparre Andersen 2012-08-06 17:37 ` Michael Rohan 2012-08-07 5:57 ` Jeffrey R. Carter 2 siblings, 2 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 17:10 UTC (permalink / raw) To clarify: Put_Line does NOT work. The compiler (GNAT GPL 2012) says: Put_Line (Country) => expected type "Standard.String" found type "Ada.Locales.Country_Code" Put_Line (String (Country)) => component subtypes must statically match ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 17:10 ` Marius Amado-Alves @ 2012-08-06 19:15 ` J-P. Rosen 2012-08-06 19:34 ` Simon Wright 2012-08-06 20:00 ` Marius Amado-Alves 2012-08-06 19:49 ` Jacob Sparre Andersen 1 sibling, 2 replies; 69+ messages in thread From: J-P. Rosen @ 2012-08-06 19:15 UTC (permalink / raw) Le 06/08/2012 19:10, Marius Amado-Alves a �crit : > To clarify: Put_Line does NOT work. The compiler (GNAT GPL 2012) says: > > Put_Line (Country) => > expected type "Standard.String" > found type "Ada.Locales.Country_Code" > > Put_Line (String (Country)) => > component subtypes must statically match > But they can be converted to String: Put_Line (String (Country)); -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 19:15 ` J-P. Rosen @ 2012-08-06 19:34 ` Simon Wright 2012-08-06 20:07 ` Marius Amado-Alves 2012-08-07 17:51 ` Simon Wright 2012-08-06 20:00 ` Marius Amado-Alves 1 sibling, 2 replies; 69+ messages in thread From: Simon Wright @ 2012-08-06 19:34 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > Le 06/08/2012 19:10, Marius Amado-Alves a écrit : >> To clarify: Put_Line does NOT work. The compiler (GNAT GPL 2012) says: >> >> Put_Line (Country) => >> expected type "Standard.String" >> found type "Ada.Locales.Country_Code" >> >> Put_Line (String (Country)) => >> component subtypes must statically match >> > But they can be converted to String: > Put_Line (String (Country)); Not with GNAT GPL 2012 or GCC 4.7.0: GNAT GPL 2012 (20120509) Copyright 1992-2012, Free Software Foundation, Inc. Compiling: locales.adb (source file time stamp: 2012-08-06 19:30:36) 1. with Ada.Locales; | >>> warning: "Ada.Locales" is an internal GNAT unit >>> warning: use of this unit is non-portable and version-dependent 2. with Ada.Text_IO; use Ada.Text_IO; 3. procedure Locales is 4. begin 5. Put_Line (String (Ada.Locales.Language_Code)); | >>> component subtypes must statically match 6. Put_Line (String (Ada.Locales.Country_Code)); | >>> component subtypes must statically match 7. end Locales; But note the warning! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 19:34 ` Simon Wright @ 2012-08-06 20:07 ` Marius Amado-Alves 2012-08-06 20:57 ` Simon Wright 2012-08-07 17:51 ` Simon Wright 1 sibling, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 20:07 UTC (permalink / raw) On Monday, August 6, 2012 8:34:22 PM UTC+1, Simon Wright wrote: > 5. Put_Line (String (Ada.Locales.Language_Code)); > >>> component subtypes must statically match This code is wrong: Language_Code is the type, not the function. But the right code gives the same error! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 20:07 ` Marius Amado-Alves @ 2012-08-06 20:57 ` Simon Wright 2012-08-06 21:09 ` Vasiliy Molostov 0 siblings, 1 reply; 69+ messages in thread From: Simon Wright @ 2012-08-06 20:57 UTC (permalink / raw) Marius Amado-Alves <amado.alves@gmail.com> writes: > On Monday, August 6, 2012 8:34:22 PM UTC+1, Simon Wright wrote: >> 5. Put_Line (String (Ada.Locales.Language_Code)); >> >>> component subtypes must statically match > > This code is wrong: Language_Code is the type, not the function. Oops. > But the right code gives the same error! It seems to be the "Character range 'a' .. 'z'" that's the problem; that'll be why the error message was "component subtypes must statically match". ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 20:57 ` Simon Wright @ 2012-08-06 21:09 ` Vasiliy Molostov 2012-08-06 23:07 ` Adam Beneschan 0 siblings, 1 reply; 69+ messages in thread From: Vasiliy Molostov @ 2012-08-06 21:09 UTC (permalink / raw) Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug 2012 00:57:53 +0400: > Marius Amado-Alves <amado.alves@gmail.com> writes: > >> On Monday, August 6, 2012 8:34:22 PM UTC+1, Simon Wright wrote: >>> 5. Put_Line (String (Ada.Locales.Language_Code)); >>> >>> component subtypes must statically match >> >> This code is wrong: Language_Code is the type, not the function. > > Oops. > >> But the right code gives the same error! > > It seems to be the "Character range 'a' .. 'z'" that's the problem; > that'll be why the error message was "component subtypes must statically > match". they should be a subtype of character to be convertable, I suppose. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 21:09 ` Vasiliy Molostov @ 2012-08-06 23:07 ` Adam Beneschan 2012-08-06 23:23 ` Vasiliy Molostov ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: Adam Beneschan @ 2012-08-06 23:07 UTC (permalink / raw) On Monday, August 6, 2012 2:09:48 PM UTC-7, Vasiliy Molostov wrote: > > It seems to be the "Character range 'a' .. 'z'" that's the problem; > > that'll be why the error message was "component subtypes must statically > > match". > > they should be a subtype of character to be convertable, I suppose. They already are a subtype of Character, i.e. the subtype "Character range 'a' .. 'z'". The only way to make it convertible is to get rid of the range. I just sent a note to Ada-Comment requesting that To_String and From_String operations be added to Ada.Locales. Maybe that isn't the right solution, but it does seem like something needs to change. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:07 ` Adam Beneschan @ 2012-08-06 23:23 ` Vasiliy Molostov 2012-08-06 23:46 ` Adam Beneschan 2012-08-07 7:20 ` Dmitry A. Kazakov ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Vasiliy Molostov @ 2012-08-06 23:23 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> писал(а) в своём письме Tue, 07 Aug 2012 03:07:02 +0400: > On Monday, August 6, 2012 2:09:48 PM UTC-7, Vasiliy Molostov wrote: > >> > It seems to be the "Character range 'a' .. 'z'" that's the problem; >> > that'll be why the error message was "component subtypes must >> statically >> > match". >> >> they should be a subtype of character to be convertable, I suppose. > > They already are a subtype of Character, i.e. the subtype "Character > range 'a' .. 'z'". The only way to make it convertible is to get rid of > the range. > > I just sent a note to Ada-Comment requesting that To_String and > From_String operations be added to Ada.Locales. Maybe that isn't the > right solution, but it does seem like something needs to change. > > -- Adam > > Sorry my mistake - subtype of string I meant. The workaround here can be done via 'image() attribute since it always return string -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:23 ` Vasiliy Molostov @ 2012-08-06 23:46 ` Adam Beneschan 2012-08-07 1:17 ` Vasiliy Molostov 0 siblings, 1 reply; 69+ messages in thread From: Adam Beneschan @ 2012-08-06 23:46 UTC (permalink / raw) On Monday, August 6, 2012 4:23:13 PM UTC-7, Vasiliy Molostov wrote: > >> > It seems to be the "Character range 'a' .. 'z'" that's the problem; > >> > that'll be why the error message was "component subtypes must > >> statically > >> > match". > > >> they should be a subtype of character to be convertable, I suppose. > > > They already are a subtype of Character, i.e. the subtype "Character > > range 'a' .. 'z'". The only way to make it convertible is to get rid of > > the range. > > Sorry my mistake - subtype of string I meant. Making the two types subtypes of String means that you cannot put a constraint on the component subtype. So if we assume that they really want the range constraints 'A'..'Z' and 'a'..'z', the types can't be made subtypes of String. > > The workaround here can be done via 'image() attribute since it always > return string If you mean something like Language_Code'Image(L) or Country_Code'Image(C), that's not legal. 'Image is defined only for scalar types, not array types. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:46 ` Adam Beneschan @ 2012-08-07 1:17 ` Vasiliy Molostov 0 siblings, 0 replies; 69+ messages in thread From: Vasiliy Molostov @ 2012-08-07 1:17 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> писал(а) в своём письме Tue, 07 Aug 2012 03:46:37 +0400: >> Sorry my mistake - subtype of string I meant. > > Making the two types subtypes of String means that you cannot put a > constraint on the component subtype. So if we assume that they really > want the range constraints 'A'..'Z' and 'a'..'z', the types can't be > made subtypes of String. >> >> The workaround here can be done via 'image() attribute since it always >> return string > > If you mean something like Language_Code'Image(L) or > Country_Code'Image(C), that's not legal. 'Image is defined only for > scalar types, not array types. yep. seems to me I am out of order today. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:07 ` Adam Beneschan 2012-08-06 23:23 ` Vasiliy Molostov @ 2012-08-07 7:20 ` Dmitry A. Kazakov 2012-08-07 7:43 ` Jacob Sparre Andersen 2012-08-07 8:44 ` Marius Amado-Alves 3 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-07 7:20 UTC (permalink / raw) On Mon, 6 Aug 2012 16:07:02 -0700 (PDT), Adam Beneschan wrote: > I just sent a note to Ada-Comment requesting that To_String and > From_String operations be added to Ada.Locales. Maybe that isn't the > right solution, but it does seem like something needs to change. Yes, the right one would be an array subtype which is presently impossible to have. E.g. subtype Language_Code is String (1 .. 3) of Character range 'a' .. 'z'; A similar case where array elements need to be constrained is an array of class-wide elements as a replacement to generics: type Container is array (Positive range <>) of T'Class; -- No objects allowed type S is new T with ...; subtype Container_Of_S is Container of S; Syntax is imaginary. Maybe, aspects could help better express element constraints. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:07 ` Adam Beneschan 2012-08-06 23:23 ` Vasiliy Molostov 2012-08-07 7:20 ` Dmitry A. Kazakov @ 2012-08-07 7:43 ` Jacob Sparre Andersen 2012-08-09 20:47 ` Randy Brukardt 2012-08-07 8:44 ` Marius Amado-Alves 3 siblings, 1 reply; 69+ messages in thread From: Jacob Sparre Andersen @ 2012-08-07 7:43 UTC (permalink / raw) Adam Beneschan wrote: > They already are a subtype of Character, i.e. the subtype "Character > range 'a' .. 'z'". The only way to make it convertible is to get rid > of the range. What about using an aspect to instead of a subtype? Wouldn't that allow the conversion, while still keeping the constraints? subtype Language_Code is String (1 .. 3) with Static_Predicate => Language_Code (1) in 'a' .. 'z' and Language_Code (2) in 'a' .. 'z' and Language_Code (3) in 'a' .. 'z'; Greetings, Jacob -- "If we weren't at least occasionally surprised by the results, we might as well save ourselves the trouble of measuring :)" ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 7:43 ` Jacob Sparre Andersen @ 2012-08-09 20:47 ` Randy Brukardt 0 siblings, 0 replies; 69+ messages in thread From: Randy Brukardt @ 2012-08-09 20:47 UTC (permalink / raw) "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message news:87mx274066.fsf@adaheads.sparre-andersen.dk... > Adam Beneschan wrote: > >> They already are a subtype of Character, i.e. the subtype "Character >> range 'a' .. 'z'". The only way to make it convertible is to get rid >> of the range. > > What about using an aspect to instead of a subtype? Wouldn't that allow > the conversion, while still keeping the constraints? No. > subtype Language_Code is String (1 .. 3) > with Static_Predicate => Language_Code (1) in 'a' .. 'z' and > Language_Code (2) in 'a' .. 'z' and > Language_Code (3) in 'a' .. 'z'; The rule requires static matching, and that requires the same static predicates. The requirement on the type conversions seems rather unfriendly, certainly for String; but I can't predict what the ARG will do with this one. Randy. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 23:07 ` Adam Beneschan ` (2 preceding siblings ...) 2012-08-07 7:43 ` Jacob Sparre Andersen @ 2012-08-07 8:44 ` Marius Amado-Alves 2012-08-07 13:14 ` Marius Amado-Alves 2012-08-07 15:26 ` Adam Beneschan 3 siblings, 2 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 8:44 UTC (permalink / raw) On Tuesday, August 7, 2012 12:07:02 AM UTC+1, Adam Beneschan wrote: > I just sent a note to Ada-Comment requesting that To_String and From_String operations be added to Ada.Locales. Maybe that isn't the right solution, but it does seem like something needs to change. What needs to change is the language doing the obvious thing: if types are compatible (down to no any level of composition) then they are convertible. I was pretty sure arrays of convertible elements were convertible and I am much surprised to find they are not and I am still not convinced that this is not a compiler bug. If it is a language limitation, then before 20X0 lifts it, is not there an aspect clause to restrict the character range with the array being a subtype of string? subtype Language_Code is String (1 .. 2) with Component_Range in 'a' .. 'z'; (Instead of adding To/From_String functions.) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 8:44 ` Marius Amado-Alves @ 2012-08-07 13:14 ` Marius Amado-Alves 2012-08-07 15:42 ` Adam Beneschan 2012-08-07 21:59 ` Robert A Duff 2012-08-07 15:26 ` Adam Beneschan 1 sibling, 2 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 13:14 UTC (permalink / raw) I took the chance to learn subtype aspect clauses, and changed Ada_Locales thus: subtype Country_Code is String (1 .. 2) with Static_Predicate => Country_Code (1) in 'A' .. 'Z' and Country_Code (2) in 'A' .. 'Z'; (Now Text_IO.Put works of course, but I think it should work in the first place.) This little experiment exposed other strange things: (1) It seems the compiler accepts the type name, in the aspect clause, as a representative of a value of the type. I could not find this documented in the RM. (2) The aspect clause does not seem to have effect. The following code compiles and runs normally. CC : Ada_Locales.Country_Code := "34"; Of course (2) can be an effect of the semantic void of (1). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 13:14 ` Marius Amado-Alves @ 2012-08-07 15:42 ` Adam Beneschan 2012-08-07 18:22 ` Marius Amado-Alves 2012-08-07 21:59 ` Robert A Duff 1 sibling, 1 reply; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 15:42 UTC (permalink / raw) On Tuesday, August 7, 2012 6:14:13 AM UTC-7, Marius Amado-Alves wrote: > I took the chance to learn subtype aspect clauses, and changed Ada_Locales thus: > > subtype Country_Code is String (1 .. 2) > with Static_Predicate => > Country_Code (1) in 'A' .. 'Z' and > Country_Code (2) in 'A' .. 'Z'; > > (Now Text_IO.Put works of course, but I think it should work in the first place.) If GNAT accepts this, then *that* is a compiler bug, I think. I don't see how this expression is allowed as a static predicate. (The rule in 3.2.4(17) says that the "current instance" may be used as the expression in a membership test. But it looks to me that "current instance" refers strictly to the name Country_Code, period, without any indexes or component selectors or anything. So you can't use Country_Code(1) in a static predicate, as I interpret it.) Dynamic_Predicate might work. I haven't studied all the rules, though. > This little experiment exposed other strange things: > > (1) It seems the compiler accepts the type name, in the aspect clause, as a representative of a value of the type. I could not find this documented in the RM. That's what "current instance" means. See 8.6(17). > > (2) The aspect clause does not seem to have effect. The following code compiles and runs normally. > > CC : Ada_Locales.Country_Code := "34"; > > Of course (2) can be an effect of the semantic void of (1). -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 15:42 ` Adam Beneschan @ 2012-08-07 18:22 ` Marius Amado-Alves 2012-08-07 20:10 ` Adam Beneschan 0 siblings, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 18:22 UTC (permalink / raw) > > subtype Country_Code is String (1 .. 2) > > with Static_Predicate => > > Country_Code (1) in 'A' .. 'Z' and > > Country_Code (2) in 'A' .. 'Z'; > But it looks to me that "current instance" refers strictly to the name Country_Code, period, without any indexes... If Country_Code denotes the object (?), and the object is a String, then I don't see a problem in indexing it. I agree it looks more dynamic than static. I've tried Dynamic_Predicate to see if the predicate had effect. It did not. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 18:22 ` Marius Amado-Alves @ 2012-08-07 20:10 ` Adam Beneschan 2012-08-07 20:42 ` Marius Amado-Alves 2012-08-07 20:43 ` Marius Amado-Alves 0 siblings, 2 replies; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 20:10 UTC (permalink / raw) On Tuesday, August 7, 2012 11:22:17 AM UTC-7, Marius Amado-Alves wrote: > > > subtype Country_Code is String (1 .. 2) > > > with Static_Predicate => > > > Country_Code (1) in 'A' .. 'Z' and > > > Country_Code (2) in 'A' .. 'Z'; > > > But it looks to me that "current instance" refers strictly to the name Country_Code, period, without any indexes... > > If Country_Code denotes the object (?), and the object is a String, then I > don't see a problem in indexing it. I don't know what you mean by "you don't see a problem". There are (I'm sure) places in the language where a "current instance" of an array type can be indexed, but a static predicate isn't one of them. And when you do, the indexed expression, as a whole, wouldn't be called a "current instance" for the purposes of the language rules; only the array type name would be a "current instance". > I agree it looks more dynamic than static. I've tried Dynamic_Predicate to see > if the predicate had effect. It did not. Probably a compiler "bug", or a feature that isn't fully implemented yet. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 20:10 ` Adam Beneschan @ 2012-08-07 20:42 ` Marius Amado-Alves 2012-08-07 21:38 ` Adam Beneschan 2012-08-08 7:04 ` Niklas Holsti 2012-08-07 20:43 ` Marius Amado-Alves 1 sibling, 2 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 20:42 UTC (permalink / raw) > > > > subtype Country_Code is String (1 .. 2) > > > > with Static_Predicate => > > > > Country_Code (1) in 'A' .. 'Z' and > > > > Country_Code (2) in 'A' .. 'Z'; > > > If Country_Code denotes the object (?), and the object is a String, then I > > don't see a problem in indexing it. > > I don't know what you mean by "you don't see a problem". There are (I'm sure) places in the language where a "current instance" of an array type can be indexed, but a static predicate isn't one of them. Dynamic, then. But this is hardly useful. It has the same component-by-component ugliness as String'(1 => Country (1), 2 => Country (2)) The static match rule for component types is silly. It should be a compatibility match like it is for the main types. At least. Ada has way too strict rules for conversion. As a consequence Ada programs are ridden with Unchecked_Conversion instances. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 20:42 ` Marius Amado-Alves @ 2012-08-07 21:38 ` Adam Beneschan 2012-08-08 7:04 ` Niklas Holsti 1 sibling, 0 replies; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 21:38 UTC (permalink / raw) On Tuesday, August 7, 2012 1:42:32 PM UTC-7, Marius Amado-Alves wrote: > > > I don't know what you mean by "you don't see a problem". There are (I'm sure) places in the language where a "current instance" of an array type can be indexed, but a static predicate isn't one of them. > > Dynamic, then. Yes, it should be allowable there. > But this is hardly useful. It has the same component-by-component ugliness as > > String'(1 => Country (1), 2 => Country (2)) Check out Ada 2012's quantified expressions. Without trying it, I think this will work: subtype Country_Code is String (1 .. 2) with Dynamic_Predicate => (for all I in 1 .. 2 => Country_Code(I) in 'A' .. 'Z'); which should make you happy. Of course, there's no guarantee that your compiler accepts it yet. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 20:42 ` Marius Amado-Alves 2012-08-07 21:38 ` Adam Beneschan @ 2012-08-08 7:04 ` Niklas Holsti 2012-08-08 7:18 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 7:04 UTC (permalink / raw) On 12-08-07 23:42 , Marius Amado-Alves wrote: >>>>> subtype Country_Code is String (1 .. 2) >>>>> with Static_Predicate => >>>>> Country_Code (1) in 'A' .. 'Z' and >>>>> Country_Code (2) in 'A' .. 'Z'; >> >>> If Country_Code denotes the object (?), and the object is a String, then I >>> don't see a problem in indexing it. >> >> I don't know what you mean by "you don't see a problem". >> There are (I'm sure) places in the language where a "current >> instance" of an array type can be indexed, but a static predicate >> isn't one of them. > > Dynamic, then. > > But this is hardly useful. It has the same component-by-component ugliness as > > String'(1 => Country (1), 2 => Country (2)) > > The static match rule for component types is silly. It should > be a compatibility match like it is for the main types. At least. The rule does seem surprisingly rigid, for a value conversion. (The Annotated RM does not explain or motivate it.) For a value conversion, the default could be to convert element by element, and the compiler could then optimize this conversion based on what it can deduce statically about the matching of the source and target subtypes. In the example, the compiler should be able to deduce that element-by-element conversion is unnecessary since the source element subtype is a subrange of the target element subtype. > Ada has way too strict rules for conversion. As a consequence Ada > programs are ridden with Unchecked_Conversion instances. Depends. In my main Ada product, in size about 77,000 semicolons, there is not a single use of Unchecked_Conversion. Just one data point, of course. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:04 ` Niklas Holsti @ 2012-08-08 7:18 ` Dmitry A. Kazakov 2012-08-08 7:37 ` Niklas Holsti 2012-08-08 7:32 ` J-P. Rosen 2012-08-08 9:07 ` Marius Amado-Alves 2 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 7:18 UTC (permalink / raw) On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: > The rule does seem surprisingly rigid, for a value conversion. (The > Annotated RM does not explain or motivate it.) Ada didn't appreciate structured type equivalence in earlier times. These rules were designed before anonymous access types crept in. > For a value conversion, > the default could be to convert element by element, and the compiler > could then optimize this conversion based on what it can deduce > statically about the matching of the source and target subtypes. Could be interesting when elements themselves are arrays of discriminated record subtypes constrained via discriminants with array components again constrained etc. Type inference is evil. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:18 ` Dmitry A. Kazakov @ 2012-08-08 7:37 ` Niklas Holsti 2012-08-08 8:09 ` Dmitry A. Kazakov 2012-08-08 8:28 ` J-P. Rosen 0 siblings, 2 replies; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 7:37 UTC (permalink / raw) On 12-08-08 10:18 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: > >> The rule does seem surprisingly rigid, for a value conversion. (The >> Annotated RM does not explain or motivate it.) > > Ada didn't appreciate structured type equivalence in earlier times. These > rules were designed before anonymous access types crept in. But we are talking about explicitly requested type conversions, not implicit type equivalence. As I understood it, at least. >> For a value conversion, >> the default could be to convert element by element, and the compiler >> could then optimize this conversion based on what it can deduce >> statically about the matching of the source and target subtypes. > > Could be interesting when elements themselves are arrays of discriminated > record subtypes constrained via discriminants with array components again > constrained etc. Sure, but this should not require much new intelligence in the compiler. An array type conversion of the form A1 := A1_Type(A2); could just as well be written as an explicit loop with explicit element-by-element conversions, A1(I) := A1_Element_Type(A2(I)). A compiler could do this expansion internally, giving code that is legal today and which the compiler should already be able to compile. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:37 ` Niklas Holsti @ 2012-08-08 8:09 ` Dmitry A. Kazakov 2012-08-08 11:14 ` Niklas Holsti 2012-08-08 8:28 ` J-P. Rosen 1 sibling, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 8:09 UTC (permalink / raw) On Wed, 08 Aug 2012 10:37:51 +0300, Niklas Holsti wrote: > On 12-08-08 10:18 , Dmitry A. Kazakov wrote: >> On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: >> >>> The rule does seem surprisingly rigid, for a value conversion. (The >>> Annotated RM does not explain or motivate it.) >> >> Ada didn't appreciate structured type equivalence in earlier times. These >> rules were designed before anonymous access types crept in. > > But we are talking about explicitly requested type conversions, not > implicit type equivalence. As I understood it, at least. Yes, but the validity of this conversion relies on an inferred equivalence of the [sub]types of the elements. Ada considered them equivalent nominally. A less conservative approach is to consider only those for which constraints are no less permissive than ones of the target elements. The most lax would be to allow any subtype. >>> For a value conversion, >>> the default could be to convert element by element, and the compiler >>> could then optimize this conversion based on what it can deduce >>> statically about the matching of the source and target subtypes. >> >> Could be interesting when elements themselves are arrays of discriminated >> record subtypes constrained via discriminants with array components again >> constrained etc. > > Sure, but this should not require much new intelligence in the compiler. True. BTW, there is another issue with that. What happens when some element cannot be converted? Constraint_Error is to propagate. What happens with the target. Will be previously assigned elements rolled back? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:09 ` Dmitry A. Kazakov @ 2012-08-08 11:14 ` Niklas Holsti 2012-08-08 11:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 11:14 UTC (permalink / raw) On 12-08-08 11:09 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 10:37:51 +0300, Niklas Holsti wrote: > >> On 12-08-08 10:18 , Dmitry A. Kazakov wrote: >>> On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: >>> >>>> The rule does seem surprisingly rigid, for a value conversion. (The >>>> Annotated RM does not explain or motivate it.) >>> >>> Ada didn't appreciate structured type equivalence in earlier times. These >>> rules were designed before anonymous access types crept in. >> >> But we are talking about explicitly requested type conversions, not >> implicit type equivalence. As I understood it, at least. > > Yes, but the validity of this conversion relies on an inferred equivalence > of the [sub]types of the elements. No, I would rather think that the explicitly requested array-type conversion implies requests to convert the index [sub]types and the element [sub]types, too. > Ada considered them equivalent nominally. Yes, but in order to be sure that the conversion requires no active machine code and can be done just by relabeling the type of a reference to the array. > A less conservative approach is to consider only those for which > constraints are no less permissive than ones of the target elements. Yes (I wrote about that in another reply). >>>> For a value conversion, >>>> the default could be to convert element by element, and the compiler >>>> could then optimize this conversion based on what it can deduce >>>> statically about the matching of the source and target subtypes. >>> >>> Could be interesting when elements themselves are arrays of discriminated >>> record subtypes constrained via discriminants with array components again >>> constrained etc. >> >> Sure, but this should not require much new intelligence in the compiler. > > True. > > BTW, there is another issue with that. What happens when some element > cannot be converted? Constraint_Error is to propagate. What happens with > the target. Will be previously assigned elements rolled back? A matter of definition. Ada already contains the concept of a "disrupted" assignment, which can be caused by the failure of a language-defined check and in which the variable being assigned then becomes abnormal. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:14 ` Niklas Holsti @ 2012-08-08 11:59 ` Dmitry A. Kazakov 2012-08-08 14:01 ` Niklas Holsti 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 11:59 UTC (permalink / raw) On Wed, 08 Aug 2012 14:14:26 +0300, Niklas Holsti wrote: > On 12-08-08 11:09 , Dmitry A. Kazakov wrote: >> On Wed, 08 Aug 2012 10:37:51 +0300, Niklas Holsti wrote: >> >>> On 12-08-08 10:18 , Dmitry A. Kazakov wrote: >>>> On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: >>>> >>>>> The rule does seem surprisingly rigid, for a value conversion. (The >>>>> Annotated RM does not explain or motivate it.) >>>> >>>> Ada didn't appreciate structured type equivalence in earlier times. These >>>> rules were designed before anonymous access types crept in. >>> >>> But we are talking about explicitly requested type conversions, not >>> implicit type equivalence. As I understood it, at least. >> >> Yes, but the validity of this conversion relies on an inferred equivalence >> of the [sub]types of the elements. > > No, I would rather think that the explicitly requested array-type > conversion implies requests to convert the index [sub]types and the > element [sub]types, too. Yes, but the way this conversion is constructed is based on the assumption that subtypes of the element are equivalent up to a conversion. BTW, if you go that far you should also allow conversions between any array types of convertible elements. E.g. between arrays of floats and arrays of integers etc. >> Ada considered them equivalent nominally. > > Yes, but in order to be sure that the conversion requires no active > machine code and can be done just by relabeling the type of a reference > to the array. This is one possible point of view, which is pretty weak. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:59 ` Dmitry A. Kazakov @ 2012-08-08 14:01 ` Niklas Holsti 2012-08-09 7:48 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 14:01 UTC (permalink / raw) On 12-08-08 14:59 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 14:14:26 +0300, Niklas Holsti wrote: > >> On 12-08-08 11:09 , Dmitry A. Kazakov wrote: >>> On Wed, 08 Aug 2012 10:37:51 +0300, Niklas Holsti wrote: >>> >>>> On 12-08-08 10:18 , Dmitry A. Kazakov wrote: >>>>> On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: >>>>> >>>>>> The rule does seem surprisingly rigid, for a value conversion. (The >>>>>> Annotated RM does not explain or motivate it.) >>>>> >>>>> Ada didn't appreciate structured type equivalence in earlier times. These >>>>> rules were designed before anonymous access types crept in. >>>> >>>> But we are talking about explicitly requested type conversions, not >>>> implicit type equivalence. As I understood it, at least. >>> >>> Yes, but the validity of this conversion relies on an inferred equivalence >>> of the [sub]types of the elements. >> >> No, I would rather think that the explicitly requested array-type >> conversion implies requests to convert the index [sub]types and the >> element [sub]types, too. > > Yes, but the way this conversion is constructed is based on the assumption > that subtypes of the element are equivalent up to a conversion. > > BTW, if you go that far you should also allow conversions between any array > types of convertible elements. E.g. between arrays of floats and arrays of > integers etc. Well, for explicit value conversions, why not? But I don't think that there is significant need for such conversions on the array level. What I have sometimes found annoying is that operations on arrays of a parent type cannot easily be applied to arrays of a derived type. For example: type Parent is (A, B, C); type Parent_Arr is array (Positive range <>) of Parent; procedure Print (Item : in Parent_Arr) ... end Print; type Child is new Parent; type Child_Arr is array (Positive range <>) of Child; The operation Print on Parent_Arr is not inherited by Child_Arr, and conversion from Child_Arr to Parent_Arr is not allowed. Not a big problem, but one that has sometimes irritated me and forced me to use work-arounds (writing a special Print for Child_Arr, in this case). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 14:01 ` Niklas Holsti @ 2012-08-09 7:48 ` Dmitry A. Kazakov 2012-08-09 8:31 ` Niklas Holsti 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-09 7:48 UTC (permalink / raw) On Wed, 08 Aug 2012 17:01:23 +0300, Niklas Holsti wrote: > On 12-08-08 14:59 , Dmitry A. Kazakov wrote: >> BTW, if you go that far you should also allow conversions between any array >> types of convertible elements. E.g. between arrays of floats and arrays of >> integers etc. > > Well, for explicit value conversions, why not? But I don't think that > there is significant need for such conversions on the array level. I needed to convert array of access types in some cases. But I agree that there is no significant need in array conversion, in any array conversion, I would add. Don't we consider conversions bad, in Ada? If so, we should rather eliminate cases where conversions are needed, rather than inventing more and more sophisticated ways of conversion. > What I have sometimes found annoying is that operations on arrays of a > parent type cannot easily be applied to arrays of a derived type. > For example: > > type Parent is (A, B, C); > type Parent_Arr is array (Positive range <>) of Parent; > > procedure Print (Item : in Parent_Arr) > ... > end Print; > > type Child is new Parent; > type Child_Arr is array (Positive range <>) of Child; If arrays had classes you could inherit the Parent's interface which would bring Print with it. > The operation Print on Parent_Arr is not inherited by Child_Arr, Why should it? Child_Arr is unrelated to Parent. Somewhere in its declaration Child_Arr must say "new Parent" or "and Parent." Such type relationships must be manifested, not implied. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-09 7:48 ` Dmitry A. Kazakov @ 2012-08-09 8:31 ` Niklas Holsti 2012-08-09 12:17 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-09 8:31 UTC (permalink / raw) On 12-08-09 10:48 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 17:01:23 +0300, Niklas Holsti wrote: > >> On 12-08-08 14:59 , Dmitry A. Kazakov wrote: > >>> BTW, if you go that far you should also allow conversions between any array >>> types of convertible elements. E.g. between arrays of floats and arrays of >>> integers etc. >> >> Well, for explicit value conversions, why not? But I don't think that >> there is significant need for such conversions on the array level. > > I needed to convert array of access types in some cases. But I agree that > there is no significant need in array conversion, in any array conversion, > I would add. Don't we consider conversions bad, in Ada? If so, we should > rather eliminate cases where conversions are needed, rather than inventing > more and more sophisticated ways of conversion. I think that conversions are the logically right thing in some cases, while more inheritance (which I assume is your aim) is better in other cases. I would not like to reduce the conversion abilities of Ada. >> What I have sometimes found annoying is that operations on arrays of a >> parent type cannot easily be applied to arrays of a derived type. >> For example: >> >> type Parent is (A, B, C); >> type Parent_Arr is array (Positive range <>) of Parent; >> >> procedure Print (Item : in Parent_Arr) >> ... >> end Print; >> >> type Child is new Parent; >> type Child_Arr is array (Positive range <>) of Child; > > If arrays had classes you could inherit the Parent's interface which would > bring Print with it. It is not clear to me how that would work, in detail. Either one would have to override all the operations for Child_Arr, to substitude Parent with Child, or there would have to be some implicit rules for such substitutions, which would in effect establish the same implicit relationship between Child_Arr and Parent_Arr as I feel already exists. >> The operation Print on Parent_Arr is not inherited by Child_Arr, > > Why should it? Child_Arr is unrelated to Parent. It is just a feeling, and sometimes a practical need. Surely Child_Arr is in some sense related to Parent_Arr, since Child is related to Parent, and the same type construction (array) is used in both? If a Child is-a Parent, in the sense that primitive operations for Parents are also available (inherited) for Children, why are not operations on collections of Parents available for collections of Children? A collection (array) of Children is-a collection of Parents. (This relationship could be easier to see and implement if Ada had a "sequence" type construction in addition to the "array" type construction, because then we would not have to consider the possible difference in the index types of Child_Arr and Parent_Arr. That is, if a list of elements of type T could be defined as "sequence of T" without having to choose a specific type and range to index the sequence.) > Somewhere in its > declaration Child_Arr must say "new Parent" or "and Parent." Such type > relationships must be manifested, not implied. I'm not sure that making the relation manifest in that way is important. I think that an Ada-derived language could be defined that would let Child_Arr inherit Print from Parent_Arr, without requiring this manifest relation in the syntax. Other considerations (readability, reliability) would determine the decision. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-09 8:31 ` Niklas Holsti @ 2012-08-09 12:17 ` Dmitry A. Kazakov 2012-08-09 15:25 ` Niklas Holsti 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-09 12:17 UTC (permalink / raw) On Thu, 09 Aug 2012 11:31:44 +0300, Niklas Holsti wrote: > On 12-08-09 10:48 , Dmitry A. Kazakov wrote: >> On Wed, 08 Aug 2012 17:01:23 +0300, Niklas Holsti wrote: >> >>> On 12-08-08 14:59 , Dmitry A. Kazakov wrote: >> >>>> BTW, if you go that far you should also allow conversions between any array >>>> types of convertible elements. E.g. between arrays of floats and arrays of >>>> integers etc. >>> >>> Well, for explicit value conversions, why not? But I don't think that >>> there is significant need for such conversions on the array level. >> >> I needed to convert array of access types in some cases. But I agree that >> there is no significant need in array conversion, in any array conversion, >> I would add. Don't we consider conversions bad, in Ada? If so, we should >> rather eliminate cases where conversions are needed, rather than inventing >> more and more sophisticated ways of conversion. > > I think that conversions are the logically right thing in some cases, > while more inheritance (which I assume is your aim) is better in other > cases. I would not like to reduce the conversion abilities of Ada. I disagree. Conversion is bad when its outcome is not evident. Otherwise there should be no conversion. Considering the cases of many competing conversions, these should be dealt with using appropriately named functions. The names should indicate the result. >>> What I have sometimes found annoying is that operations on arrays of a >>> parent type cannot easily be applied to arrays of a derived type. >>> For example: >>> >>> type Parent is (A, B, C); >>> type Parent_Arr is array (Positive range <>) of Parent; >>> >>> procedure Print (Item : in Parent_Arr) >>> ... >>> end Print; >>> >>> type Child is new Parent; >>> type Child_Arr is array (Positive range <>) of Child; >> >> If arrays had classes you could inherit the Parent's interface which would >> bring Print with it. > > It is not clear to me how that would work, in detail. Either one would > have to override all the operations for Child_Arr, to substitude Parent > with Child, or there would have to be some implicit rules for such > substitutions, which would in effect establish the same implicit > relationship between Child_Arr and Parent_Arr as I feel already exists. Yes. Either operations are implemented anew or else they are generated per composition of a conversion provided by the programmer with the operation of Parent. >>> The operation Print on Parent_Arr is not inherited by Child_Arr, >> >> Why should it? Child_Arr is unrelated to Parent. > > It is just a feeling, and sometimes a practical need. Surely Child_Arr > is in some sense related to Parent_Arr, since Child is related to > Parent, and the same type construction (array) is used in both? type A is range 1..100; type B is range 1..100; How do you feel them, same, different? > If a Child is-a Parent, in the sense that primitive operations for > Parents are also available (inherited) for Children, why are not > operations on collections of Parents available for collections of > Children? A collection (array) of Children is-a collection of Parents. This relationship must be stated explicitly, e.g. Child implements the interface of Parent = Child and Parent are in the same class with the operations so and so defined. > (This relationship could be easier to see and implement if Ada had a > "sequence" type construction in addition to the "array" type > construction, because then we would not have to consider the possible > difference in the index types of Child_Arr and Parent_Arr. That is, if a > list of elements of type T could be defined as "sequence of T" without > having to choose a specific type and range to index the sequence.) Sequence of T is nothing but an interface (= abstract root type of a class). Array has an interface too, which is a sequence of T + random element access using index + mutability of elements. There is no need to invent new entities. Everything fits into one model. >> Somewhere in its >> declaration Child_Arr must say "new Parent" or "and Parent." Such type >> relationships must be manifested, not implied. > > I'm not sure that making the relation manifest in that way is important. How otherwise you could tell if Child could be used with Print? Child must be in the class of types having Print. Manifested typing requires this declared. It is a contract model. When declared in Parent'Class, the implementation of Child can be verified before anybody actually tried to pass Child to Print eons later. Inference is incompatible with contract driven design, IMO. > I think that an Ada-derived language could be defined that would let > Child_Arr inherit Print from Parent_Arr, without requiring this manifest > relation in the syntax. Other considerations (readability, reliability) > would determine the decision. I don't trust in type inference. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-09 12:17 ` Dmitry A. Kazakov @ 2012-08-09 15:25 ` Niklas Holsti 2012-08-09 16:43 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-09 15:25 UTC (permalink / raw) On 12-08-09 15:17 , Dmitry A. Kazakov wrote: Niklas: >>>> What I have sometimes found annoying is that operations on arrays of a >>>> parent type cannot easily be applied to arrays of a derived type. >>>> For example: >>>> >>>> type Parent is (A, B, C); >>>> type Parent_Arr is array (Positive range <>) of Parent; >>>> >>>> procedure Print (Item : in Parent_Arr) >>>> ... >>>> end Print; >>>> >>>> type Child is new Parent; >>>> type Child_Arr is array (Positive range <>) of Child; Dmitry: >>> If arrays had classes you could inherit the Parent's interface which would >>> bring Print with it. Niklas: >> It is not clear to me how that would work, in detail. Either one would >> have to override all the operations for Child_Arr, to substitude Parent >> with Child, or there would have to be some implicit rules for such >> substitutions, which would in effect establish the same implicit >> relationship between Child_Arr and Parent_Arr as I feel already exists. Dmitry: > Yes. Either operations are implemented anew or else they are generated per > composition of a conversion provided by the programmer with the operation > of Parent. So in the Child/Parent example, how would you "generate" the Print operation for Child_Arr? How much more text would that need than the current work-around, which is: procedure Print (Item : in Child_Arr) is Parents : Parent_Arr(Item'Range); begin for P in Parents'Range loop Parents(P) := Parent (Item(P)); end loop; Print (Parents); end Print; (This work-around becomes longer for operations with "in out" parameters.) Niklas: >>>> The operation Print on Parent_Arr is not inherited by Child_Arr, Dmitry: >>> Why should it? Child_Arr is unrelated to Parent. Niklas: >> It is just a feeling, and sometimes a practical need. Surely Child_Arr >> is in some sense related to Parent_Arr, since Child is related to >> Parent, and the same type construction (array) is used in both? Dmitry: > type A is range 1..100; > type B is range 1..100; > > How do you feel them, same, different? Types A and B are different, but both are related to (derived from) their (unnamed) 'Base types, and probably A'Base is the same as B'Base, in which case both A and B inherit all operations of that type. I don't think this example is similar to the Child/Parent example. Niklas: >> If a Child is-a Parent, in the sense that primitive operations for >> Parents are also available (inherited) for Children, why are not >> operations on collections of Parents available for collections of >> Children? A collection (array) of Children is-a collection of Parents. Dmitry: > This relationship must be stated explicitly, e.g. Child implements the > interface of Parent = Child and Parent are in the same class with the > operations so and so defined. "Must" is your opinion. I can disagree. Dmitry: >>> Somewhere in its >>> declaration Child_Arr must say "new Parent" or "and Parent." Such type >>> relationships must be manifested, not implied. Niklas: >> I'm not sure that making the relation manifest in that way is important. Dmitry: > How otherwise you could tell if Child could be used with Print? (I assume you mean whether Child_Arr could be used with Print.) The answer is: by making it a general language rule that "array of derived-type" inherits operations from "array of parent-type" when the index types match. Dmitry: > Child must > be in the class of types having Print. Manifested typing requires this > declared. It is a contract model. Contracts (even in real law, I believe) can be implied, and can contain implied requirements defined by general rules or laws. Whether they should be manifest (explicitly written out) is a trade-off. In this case, one should consider the possible harm, such as ambiguities, coding errors, unreadability, etc. that the implicit inheritance of (in this example) Print from Parent_Arr to Child_Arr could cause, weigh it against the benefits, and then decide, based on one's goals for the language. You consider the harm to be larger than the benefit; I'm not sure yet. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-09 15:25 ` Niklas Holsti @ 2012-08-09 16:43 ` Dmitry A. Kazakov 0 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-09 16:43 UTC (permalink / raw) On Thu, 09 Aug 2012 18:25:23 +0300, Niklas Holsti wrote: > On 12-08-09 15:17 , Dmitry A. Kazakov wrote: > > Niklas: >>>>> What I have sometimes found annoying is that operations on arrays of a >>>>> parent type cannot easily be applied to arrays of a derived type. >>>>> For example: >>>>> >>>>> type Parent is (A, B, C); >>>>> type Parent_Arr is array (Positive range <>) of Parent; >>>>> >>>>> procedure Print (Item : in Parent_Arr) >>>>> ... >>>>> end Print; >>>>> >>>>> type Child is new Parent; >>>>> type Child_Arr is array (Positive range <>) of Child; > > Dmitry: >>>> If arrays had classes you could inherit the Parent's interface which would >>>> bring Print with it. > > Niklas: >>> It is not clear to me how that would work, in detail. Either one would >>> have to override all the operations for Child_Arr, to substitude Parent >>> with Child, or there would have to be some implicit rules for such >>> substitutions, which would in effect establish the same implicit >>> relationship between Child_Arr and Parent_Arr as I feel already exists. > > Dmitry: >> Yes. Either operations are implemented anew or else they are generated per >> composition of a conversion provided by the programmer with the operation >> of Parent. > > So in the Child/Parent example, how would you "generate" the Print > operation for Child_Arr? Yes. Don't Child_Arr have Print? Are Child_Arr and Parent_Arr same types? The rest follows. > How much more text would that need than the > current work-around, which is: > > procedure Print (Item : in Child_Arr) > is > Parents : Parent_Arr(Item'Range); > begin > for P in Parents'Range loop > Parents(P) := Parent (Item(P)); > end loop; > Print (Parents); > end Print; None assuming the case that Print of Child_Arr to be implemented per composition: procedure Print (Item : Child_Arr) = Print (To_Parent_Array (Item)) I don't have syntax for that, sorry. > (This work-around becomes longer for operations with "in out" parameters.) No. in out operations are composed with two conversions. > Niklas: >>>>> The operation Print on Parent_Arr is not inherited by Child_Arr, > > Dmitry: >>>> Why should it? Child_Arr is unrelated to Parent. > > Niklas: >>> It is just a feeling, and sometimes a practical need. Surely Child_Arr >>> is in some sense related to Parent_Arr, since Child is related to >>> Parent, and the same type construction (array) is used in both? > > Dmitry: >> type A is range 1..100; >> type B is range 1..100; >> >> How do you feel them, same, different? > > Types A and B are different, but both are related to (derived from) > their (unnamed) 'Base types, and probably A'Base is the same as B'Base, > in which case both A and B inherit all operations of that type. Relation must be material, observable. The only way to observe types per operations of these types. The way types were implemented is irrelevant. > I don't think this example is similar to the Child/Parent example. But you are using same logic inventing a relationship of two types from the structure/construction. > Niklas: >>> If a Child is-a Parent, in the sense that primitive operations for >>> Parents are also available (inherited) for Children, why are not >>> operations on collections of Parents available for collections of >>> Children? A collection (array) of Children is-a collection of Parents. > > Dmitry: >> This relationship must be stated explicitly, e.g. Child implements the >> interface of Parent = Child and Parent are in the same class with the >> operations so and so defined. > > "Must" is your opinion. I can disagree. If you favor structural equivalence and inference. > Dmitry: >>>> Somewhere in its >>>> declaration Child_Arr must say "new Parent" or "and Parent." Such type >>>> relationships must be manifested, not implied. > > Niklas: >>> I'm not sure that making the relation manifest in that way is important. > > Dmitry: >> How otherwise you could tell if Child could be used with Print? > > (I assume you mean whether Child_Arr could be used with Print.) The > answer is: by making it a general language rule that "array of > derived-type" inherits operations from "array of parent-type" when the > index types match. This is structural equivalence. The rule you propose actually is: A composite type (e.g. array) is a subtype (=inherits operation, substitutable) of another other composite type when: 1. Their structures match (e.g. array index match, number of components is same etc) 2. Structures of individual components match (e.g. the corresponding component is a subtype/derived type) This is not Ada, or, maybe, was not Ada prior to anonymous access types and procedural access types. > Dmitry: >> Child must >> be in the class of types having Print. Manifested typing requires this >> declared. It is a contract model. > > Contracts (even in real law, I believe) can be implied, and can contain > implied requirements defined by general rules or laws. Whether they > should be manifest (explicitly written out) is a trade-off. Even implied contracts are written somewhere, e.g. in the RM. > In this case, one should consider the possible harm, such as > ambiguities, coding errors, unreadability, etc. that the implicit > inheritance of (in this example) Print from Parent_Arr to Child_Arr > could cause, weigh it against the benefits, and then decide, based on > one's goals for the language. You consider the harm to be larger than > the benefit; I'm not sure yet. One argument against inference is complexity of use, one must keep too much implied things in the head. (It makes the compiler more complex as well) Another argument is inflexibility. The implied contracts are imposed on both sides against their will. You cannot change the RM, when the implied contract is not the one you wanted to have. Then true type equivalence is undecidable. It works for false negatives too, you cannot have equivalent things which cannot be inferred. Furthermore, it is very fragile, because types equivalence would depend on the operations visible in the given context. The key advantage of tagged types is that they freeze the interface. You always know which primitive operations are in effect. For non-tagged types it becomes a swamp. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:37 ` Niklas Holsti 2012-08-08 8:09 ` Dmitry A. Kazakov @ 2012-08-08 8:28 ` J-P. Rosen 2012-08-08 11:35 ` Niklas Holsti 1 sibling, 1 reply; 69+ messages in thread From: J-P. Rosen @ 2012-08-08 8:28 UTC (permalink / raw) Le 08/08/2012 09:37, Niklas Holsti a �crit : > But we are talking about explicitly requested type conversions, not > implicit type equivalence. As I understood it, at least. Yes, or more precisely, about the special rules for array conversions, which are allowed if the types are structurally "close enough". > >>> For a value conversion, >>> the default could be to convert element by element, and the compiler >>> could then optimize this conversion based on what it can deduce >>> statically about the matching of the source and target subtypes. >> >> Could be interesting when elements themselves are arrays of discriminated >> record subtypes constrained via discriminants with array components again >> constrained etc. > > Sure, but this should not require much new intelligence in the compiler. > An array type conversion of the form A1 := A1_Type(A2); could just as > well be written as an explicit loop with explicit element-by-element > conversions, A1(I) := A1_Element_Type(A2(I)). A compiler could do this > expansion internally, giving code that is legal today and which the > compiler should already be able to compile. > That's the whole point: a possible costly loop implicitely generated by the compiler. The design choice was to /not/ hide this, i.e. allow array conversions only when no extra code was required. You are free to disagree with that design choice, of course... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:28 ` J-P. Rosen @ 2012-08-08 11:35 ` Niklas Holsti 2012-08-08 14:05 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 11:35 UTC (permalink / raw) On 12-08-08 11:28 , J-P. Rosen wrote: > Le 08/08/2012 09:37, Niklas Holsti a �crit : > >> But we are talking about explicitly requested type conversions, not >> implicit type equivalence. As I understood it, at least. > Yes, or more precisely, about the special rules for array conversions, > which are allowed if the types are structurally "close enough". >> >>>> For a value conversion, >>>> the default could be to convert element by element, and the compiler >>>> could then optimize this conversion based on what it can deduce >>>> statically about the matching of the source and target subtypes. >>> >>> Could be interesting when elements themselves are arrays of discriminated >>> record subtypes constrained via discriminants with array components again >>> constrained etc. >> >> Sure, but this should not require much new intelligence in the compiler. >> An array type conversion of the form A1 := A1_Type(A2); could just as >> well be written as an explicit loop with explicit element-by-element >> conversions, A1(I) := A1_Element_Type(A2(I)). A compiler could do this >> expansion internally, giving code that is legal today and which the >> compiler should already be able to compile. >> > That's the whole point: a possible costly loop implicitely generated by > the compiler. The design choice was to /not/ hide this, i.e. allow array > conversions only when no extra code was required. But such implicit loops can already be generated in several places, for example in the assignment of array values and in the application of relational or Boolean operators to arrays. So this design choice has not been applied uniformly. > You are free to disagree with that design choice, of course... I don't agree or disagree; it is a trade-off between ease of expression and simplicity of the resulting code. The all-or-nothing language design choices of early Ada, e.g. the "no subsets" rule, have given place to more flexibility, exemplified by configuration pragmas such as pragma Restrictions. In my professional area (worst-case execution-time analysis), compiler-generated implicit loops are often a problem, especially in Ada programs. A restriction identifier to forbid such loops (at least when the number of iterations is dynamic) could be useful here, and would let programmers choose between a restrictive or a permissive coding style. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:35 ` Niklas Holsti @ 2012-08-08 14:05 ` Georg Bauhaus 0 siblings, 0 replies; 69+ messages in thread From: Georg Bauhaus @ 2012-08-08 14:05 UTC (permalink / raw) On 08.08.12 13:35, Niklas Holsti wrote: > In my professional area (worst-case execution-time analysis), > compiler-generated implicit loops are often a problem, especially in Ada > programs. A restriction identifier to forbid such loops (at least when > the number of iterations is dynamic) could be useful here, and would let > programmers choose between a restrictive or a permissive coding style. Controlling the translation of array operations seems to be a tricky business, with, apparently, many of the properties of an Ada implementation being considered in addition to the array itself. Maybe the pragmas would have to be rather detailed? In the following example, I get a plain loop for array assignment only for a very specific array length, with an 8 bits component type, even at very low optimization settings. The compiler seems to have a rich repertoire from which to choose what to emit for assignments. The assignment of array X to array Y has been isolated in procedure Assign. package Types is pragma Pure (Types); Does_Not_Unroll : constant := 129; -- Values below 129 will generate unrolled array assignment, -- four components at a time; -- Values 129 and above yield rep; movsq on Intel; -- Values 8193 and above will call _memcpy. type Idx is range 1 .. Does_Not_Unroll; type Vlu is mod 256; type Ary is array (Idx) of Vlu; end Types; with Ada.Numerics.Discrete_Random; with Types; package Bitmaker is new Ada.Numerics.Discrete_Random (Types.Vlu); with Bitmaker; with Types; use Types; procedure Hidden (Result : out Vlu) is G : Bitmaker.Generator; X, Y : Ary; procedure Assign is begin Y := X; end Assign; begin for K in X'Range loop X (K) := Bitmaker.Random (G); end loop; Assign; declare Pick : constant Vlu := X (X'First); Position : constant Idx := Idx'First + Idx'Min (Idx'Last - 1, Vlu'Pos (Pick)); begin Result := Y (Position); end; end Hidden; ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:04 ` Niklas Holsti 2012-08-08 7:18 ` Dmitry A. Kazakov @ 2012-08-08 7:32 ` J-P. Rosen 2012-08-08 8:17 ` Niklas Holsti 2012-08-08 9:07 ` Marius Amado-Alves 2 siblings, 1 reply; 69+ messages in thread From: J-P. Rosen @ 2012-08-08 7:32 UTC (permalink / raw) Le 08/08/2012 09:04, Niklas Holsti a �crit : > The rule does seem surprisingly rigid, for a value conversion. (The > Annotated RM does not explain or motivate it.) For a value conversion, > the default could be to convert element by element, and the compiler > could then optimize this conversion based on what it can deduce > statically about the matching of the source and target subtypes. One of the founding principles of Ada was "no hidden inefficiencies" (whether this has been achieved is another story). Since an array can have many elements, this could be quite costly. And of course, it would force pass-by-copy > In the example, the compiler should be able to deduce that > element-by-element conversion is unnecessary since the source element > subtype is a subrange of the target element subtype. But if the conversion is used for an in-out parameter, it implies the opposite conversion - where nothing can be deduced. And you don't want a special rule that works only for in parameters, and only with compilers that pass arrays by copy, would you? -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:32 ` J-P. Rosen @ 2012-08-08 8:17 ` Niklas Holsti 2012-08-08 8:33 ` J-P. Rosen 2012-08-08 8:35 ` Dmitry A. Kazakov 0 siblings, 2 replies; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 8:17 UTC (permalink / raw) On 12-08-08 10:32 , J-P. Rosen wrote: > Le 08/08/2012 09:04, Niklas Holsti a �crit : >> The rule does seem surprisingly rigid, for a value conversion. (The >> Annotated RM does not explain or motivate it.) For a value conversion, >> the default could be to convert element by element, and the compiler >> could then optimize this conversion based on what it can deduce >> statically about the matching of the source and target subtypes. > One of the founding principles of Ada was "no hidden inefficiencies" > (whether this has been achieved is another story). Since an array can > have many elements, this could be quite costly. This is understood. Whether this inefficiency is "hidden" is debatable, of course. > And of course, it would force pass-by-copy I don't think so. If the source and target element subtypes statically match, or match well enough that no element conversions are necessary (as in the original Ada.Locales example), the compiled code could be the same as compilers use now. In other cases, the compiler could create a temporary array to hold the result of the conversion, and pass this array by reference. I admit that this could lead to cases where a small change in the types makes the compiler switch from the fast, no-copy, pass-by-reference code to the slower element-by-element copying code, which could cause a surprising drop in performance. Users might want compilers to warn them about such cases. >> In the example, the compiler should be able to deduce that >> element-by-element conversion is unnecessary since the source element >> subtype is a subrange of the target element subtype. > But if the conversion is used for an in-out parameter, it implies the > opposite conversion - where nothing can be deduced. > > And you don't want a special rule that works only for in parameters, "In" parameters already have special rules, since conversions for "in" parameters are considered value conversions rather than view conversions. > and only with compilers that pass arrays by copy, would you? So the movation for the present static-match rule is that it makes it simple for compilers always to pass arrays by reference, even when the array is the result of a type conversion. (I suppose it is a quibble to point out that a compiler is nevertheless not forced to pass by reference.) But the rule is still stronger than necessary. For value conversions, including "in" parameters, the exact match could be replaced by a static check that the constraints on the source elements are the same as or stronger than those on the target elements. This would allow Ada.Text_IO.Put (String (Some_Country_Code)). For "out" parameters, there could be a static check that the constraints on the actual (source) array elements are the same as or weaker than those on the formal (target) array elements. For "in out" parameters, the present static-match rule would be kept, as the logical conjunction of the "in" and "out" rules. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:17 ` Niklas Holsti @ 2012-08-08 8:33 ` J-P. Rosen 2012-08-08 11:44 ` Niklas Holsti 2012-08-09 21:00 ` Randy Brukardt 2012-08-08 8:35 ` Dmitry A. Kazakov 1 sibling, 2 replies; 69+ messages in thread From: J-P. Rosen @ 2012-08-08 8:33 UTC (permalink / raw) Le 08/08/2012 10:17, Niklas Holsti a �crit : >> And of course, it would force pass-by-copy > > I don't think so. If the source and target element subtypes statically > match, then the conversion is allowed > or match well enough that no element conversions are necessary > (as in the original Ada.Locales example), the compiled code could be the > same as compilers use now. But they won't match the other way round, and passing a conversion to in-out parameters requires two-way conversion > In other cases, the compiler could create a > temporary array to hold the result of the conversion, and pass this > array by reference. If you make a copy and pass it by reference, I would call it pass by copy ;-) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:33 ` J-P. Rosen @ 2012-08-08 11:44 ` Niklas Holsti 2012-08-09 21:00 ` Randy Brukardt 1 sibling, 0 replies; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 11:44 UTC (permalink / raw) On 12-08-08 11:33 , J-P. Rosen wrote: > Le 08/08/2012 10:17, Niklas Holsti a �crit : >>> And of course, it would force pass-by-copy >> >> I don't think so. If the source and target element subtypes statically >> match, > then the conversion is allowed Yes, and for sure the compiler could detect this case, and use the fast code. So it would not have to make a copy. >> or match well enough that no element conversions are necessary >> (as in the original Ada.Locales example), the compiled code could be the >> same as compilers use now. > But they won't match the other way round, and passing a conversion to > in-out parameters requires two-way conversion That is a view conversion. I was talking about value conversions, as was the original poster, I believe. >> In other cases, the compiler could create a >> temporary array to hold the result of the conversion, and pass this >> array by reference. > If you make a copy and pass it by reference, I would call it pass by > copy ;-) What you call a "copy" is the result of converting the array. If the conversion rules are relaxed, this may not be an exact bit-by-bit copy of the original array any more (for example, if conversion from integer elements to float elements is allowed). This is just the same as when the actual parameter is a function call that returns an array type. The result of the function can be passed by reference, although the object is no doubt a temporary one. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:33 ` J-P. Rosen 2012-08-08 11:44 ` Niklas Holsti @ 2012-08-09 21:00 ` Randy Brukardt 1 sibling, 0 replies; 69+ messages in thread From: Randy Brukardt @ 2012-08-09 21:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 861 bytes --] "J-P. Rosen" <rosen@adalog.fr> wrote in message news:jvt88b$u6l$1@dont-email.me... > Le 08/08/2012 10:17, Niklas Holsti a �crit : ... >> In other cases, the compiler could create a >> temporary array to hold the result of the conversion, and pass this >> array by reference. > If you make a copy and pass it by reference, I would call it pass by > copy ;-) I wouldn't. In the case of true pass-by-copy, all calls (no matter what the arguments) pass-by-copy. In the case you're talking about, you are passing by-reference, but some calls pass-by-copy. (Janus/Ada 83 used this technique a lot for generics, as pass-by-copy allowed one to change representations as needed; it's cheaper than using reading and writing thunks (which we have to do in Janus/Ada 95, because of the possibility of aliased components)). Randy. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:17 ` Niklas Holsti 2012-08-08 8:33 ` J-P. Rosen @ 2012-08-08 8:35 ` Dmitry A. Kazakov 2012-08-08 9:32 ` Marius Amado-Alves 2012-08-08 11:52 ` Niklas Holsti 1 sibling, 2 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 8:35 UTC (permalink / raw) On Wed, 08 Aug 2012 11:17:46 +0300, Niklas Holsti wrote: > For value conversions, including "in" parameters, the exact match could > be replaced by a static check that the constraints on the source > elements are the same as or stronger than those on the target elements. > This would allow Ada.Text_IO.Put (String (Some_Country_Code)). > > For "out" parameters, there could be a static check that the constraints > on the actual (source) array elements are the same as or weaker than > those on the formal (target) array elements. > > For "in out" parameters, the present static-match rule would be kept, as > the logical conjunction of the "in" and "out" rules. 1. You cannot check that statically because the constraint of the subtype can be dynamic. 2. It is extremely uncomfortable to have legality dependant on the constraint and the parameter mode. It is worse than just inference it is in effect weakly typing. I don't want repeating the discussing about dynamic contracts, but this is exactly same issue. You either not allow this, or else you add Constraint_Error to all contracts. There is no sane middle way. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:35 ` Dmitry A. Kazakov @ 2012-08-08 9:32 ` Marius Amado-Alves 2012-08-08 10:11 ` Dmitry A. Kazakov 2012-08-08 11:52 ` Niklas Holsti 1 sibling, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-08 9:32 UTC (permalink / raw) Cc: mailbox I agree that letting contracts contain dynamics stuff brings us dangerously close to weak typing. But let me recall that the original case is all static: we want to convert from type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; to type String is array(Positive range <>) of Character with Pack; Nothing could go wrong in this case. Or in the general case of converting from subranges to fullranges, no matter how deep in the type structure. If the structure is the same, and the operand has a subrange (or a match) in the same place as the target, then please (dear Ada 202X) convert it. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 9:32 ` Marius Amado-Alves @ 2012-08-08 10:11 ` Dmitry A. Kazakov 2012-08-08 11:28 ` Marius Amado-Alves 2012-08-08 11:35 ` Marius Amado-Alves 0 siblings, 2 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 10:11 UTC (permalink / raw) On Wed, 8 Aug 2012 02:32:53 -0700 (PDT), Marius Amado-Alves wrote: > I agree that letting contracts contain dynamics stuff brings us dangerously close to weak typing. > > But let me recall that the original case is all static: we want to convert from > > type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; > > to > > type String is array(Positive range <>) of Character > with Pack; > > Nothing could go wrong in this case. That depends on the way you define wrongness. To me it is already wrong because types are different. Note that from my POV being structurally equivalent means nothing. Type is a set of values and operations. What operations are defined on Language_Code? Are they same to ones of String? If so, then conversion is possible. But I don't know it. It is not the language business to determine. Moreover, for non-tagged types it is broken anyway, because any user-defined operations are not primitive and get ignored by the compiler where you expected that least. There really should be no types without classes and primitive operations. If I ran the circus I would allow means to make Language_Code a proper subtype of String while retaining necessary constraints. Furthermore, regarding the points J-P. made, it is important to have subtypes differently implemented. That would leave the issues of optimization to the programmer's discretion. You would define a conversion from Language_Code to String and use the former with any operations taking in-String. You would declare a backward conversion and would use it with all out-String operations. Two conversions more and you would be able to use String with Language_Code operations. > Or in the general case of converting from subranges to fullranges, no > matter how deep in the type structure. If the structure is the same, and > the operand has a subrange (or a match) in the same place as the target, > then please (dear Ada 202X) convert it. This is what I certainly disagree with. Structure is an implementation detail. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 10:11 ` Dmitry A. Kazakov @ 2012-08-08 11:28 ` Marius Amado-Alves 2012-08-08 11:30 ` Marius Amado-Alves 2012-08-08 11:35 ` Marius Amado-Alves 1 sibling, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-08 11:28 UTC (permalink / raw) Cc: mailbox > > But let me recall that the original case is all static: we want to convert from > > type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; > > to > > type String is array(Positive range <>) of Character > > with Pack; > > Nothing could go wrong in this case. > That depends on the way you define wrongness. An invalid value. > To me it is already wrong > because types are different. The whole point of the concept of conversion is precisely too bridge different types. Anyway, as you know, the language already converts between "different" arrays, as long as some aspects are equivalent. I am just suggesting changing the operand range = target range constraint, to <=. > Note that from my POV being structurally > equivalent means nothing. Type is a set of values and operations. What > operations are defined on Language_Code? Are they same to ones of String? > If so, then conversion is possible. Again, conversion is exactly to bridge these differences. If the operations were the same, we would not need to convert! > ... There really should be no types without > classes and primitive operations. I tend to agree here, but the above points stand. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:28 ` Marius Amado-Alves @ 2012-08-08 11:30 ` Marius Amado-Alves 0 siblings, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-08 11:30 UTC (permalink / raw) Cc: mailbox > > That depends on the way you define wrongness. > > An invalid value. or an exception, or a crash... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 10:11 ` Dmitry A. Kazakov 2012-08-08 11:28 ` Marius Amado-Alves @ 2012-08-08 11:35 ` Marius Amado-Alves 2012-08-08 12:24 ` Dmitry A. Kazakov 1 sibling, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-08 11:35 UTC (permalink / raw) Cc: mailbox > If I ran the circus I would allow means to make Language_Code a proper > subtype of String while retaining necessary constraints. Like this? subtype Country_Code is String (1 .. 2) with Dynamic_Predicate => (for all I in 1 .. 2 => Country_Code(I) in 'A' .. 'Z'); ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:35 ` Marius Amado-Alves @ 2012-08-08 12:24 ` Dmitry A. Kazakov 0 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 12:24 UTC (permalink / raw) On Wed, 8 Aug 2012 04:35:00 -0700 (PDT), Marius Amado-Alves wrote: >> If I ran the circus I would allow means to make Language_Code a proper >> subtype of String while retaining necessary constraints. > > Like this? > > subtype Country_Code is String (1 .. 2) > with Dynamic_Predicate => > (for all I in 1 .. 2 => Country_Code(I) in 'A' .. 'Z'); Yes, though the syntax makes me itch. And it is only second best. The true solution is interface inheritance: type Country_Code is array (1..2) of Character range 'A' .. 'Z' and String; You have a whatever array that also implements String interface. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 8:35 ` Dmitry A. Kazakov 2012-08-08 9:32 ` Marius Amado-Alves @ 2012-08-08 11:52 ` Niklas Holsti 2012-08-08 13:21 ` Dmitry A. Kazakov 1 sibling, 1 reply; 69+ messages in thread From: Niklas Holsti @ 2012-08-08 11:52 UTC (permalink / raw) On 12-08-08 11:35 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 11:17:46 +0300, Niklas Holsti wrote: > >> For value conversions, including "in" parameters, the exact match could >> be replaced by a static check that the constraints on the source >> elements are the same as or stronger than those on the target elements. >> This would allow Ada.Text_IO.Put (String (Some_Country_Code)). >> >> For "out" parameters, there could be a static check that the constraints >> on the actual (source) array elements are the same as or weaker than >> those on the formal (target) array elements. >> >> For "in out" parameters, the present static-match rule would be kept, as >> the logical conjunction of the "in" and "out" rules. > > 1. You cannot check that statically because the constraint of the subtype > can be dynamic. I meant (of course!) that the conversion would be allowed only if the strengths of the constraints can be checked statically, using similar kinds of rules as are now used for "statically matching" subtypes and constraints. In effect, the bounds of the ranges would have to match exactly, or be static expressions with values in the necessary order relationships. > 2. It is extremely uncomfortable to have legality dependant on the > constraint and the parameter mode. It is worse than just inference it is in > effect weakly typing. We won't agree on that one. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 11:52 ` Niklas Holsti @ 2012-08-08 13:21 ` Dmitry A. Kazakov 0 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2012-08-08 13:21 UTC (permalink / raw) On Wed, 08 Aug 2012 14:52:01 +0300, Niklas Holsti wrote: > On 12-08-08 11:35 , Dmitry A. Kazakov wrote: >> On Wed, 08 Aug 2012 11:17:46 +0300, Niklas Holsti wrote: >> >>> For value conversions, including "in" parameters, the exact match could >>> be replaced by a static check that the constraints on the source >>> elements are the same as or stronger than those on the target elements. >>> This would allow Ada.Text_IO.Put (String (Some_Country_Code)). >>> >>> For "out" parameters, there could be a static check that the constraints >>> on the actual (source) array elements are the same as or weaker than >>> those on the formal (target) array elements. >>> >>> For "in out" parameters, the present static-match rule would be kept, as >>> the logical conjunction of the "in" and "out" rules. >> >> 1. You cannot check that statically because the constraint of the subtype >> can be dynamic. > > I meant (of course!) that the conversion would be allowed only if the > strengths of the constraints can be checked statically, using similar > kinds of rules as are now used for "statically matching" subtypes and > constraints. In effect, the bounds of the ranges would have to match > exactly, or be static expressions with values in the necessary order > relationships. Well, that could work. However error messages would be quite annoying when something turns to be not so static as it appears. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-08 7:04 ` Niklas Holsti 2012-08-08 7:18 ` Dmitry A. Kazakov 2012-08-08 7:32 ` J-P. Rosen @ 2012-08-08 9:07 ` Marius Amado-Alves 2 siblings, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-08 9:07 UTC (permalink / raw) > In the example, the compiler should be able to deduce that > element-by-element conversion is unnecessary since the source element > subtype is a subrange of the target element subtype. (Niklas) Exactly! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 20:10 ` Adam Beneschan 2012-08-07 20:42 ` Marius Amado-Alves @ 2012-08-07 20:43 ` Marius Amado-Alves 1 sibling, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 20:43 UTC (permalink / raw) > > ... if the predicate had effect. It did not. > > Probably a compiler "bug", or a feature that isn't fully implemented yet. Sure. Give it time. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 13:14 ` Marius Amado-Alves 2012-08-07 15:42 ` Adam Beneschan @ 2012-08-07 21:59 ` Robert A Duff 2012-08-07 22:19 ` Adam Beneschan 1 sibling, 1 reply; 69+ messages in thread From: Robert A Duff @ 2012-08-07 21:59 UTC (permalink / raw) Marius Amado-Alves <amado.alves@gmail.com> writes: > I took the chance to learn subtype aspect clauses, and changed Ada_Locales thus: Predicates are my favorite new feature of Ada 2012! > subtype Country_Code is String (1 .. 2) > with Static_Predicate => > Country_Code (1) in 'A' .. 'Z' and > Country_Code (2) in 'A' .. 'Z'; Or "type Country_Code is String (1 .. 2) with ...". As has been noted, it should be Dynamic_Predicate. Or in GNAT, you can use just "with Predicate =>", but that's not standard. It's a bug that GNAT accepts it as a Static_Predicate. If you report the bug, AdaCore will fix it. If you are a supported customer, we will fix it quickly. > (1) It seems the compiler accepts the type name, in the aspect clause, > as a representative of a value of the type. I could not find this > documented in the RM. Look up "current instance". For types, this concept has been around since Ada 83. In Ada 2012, it works for subtypes, too. > (2) The aspect clause does not seem to have effect. The following code > compiles and runs normally. > > CC : Ada_Locales.Country_Code := "34"; It works for me, using the latest compiler. Did you remember to turn on checking of assertions, for example using the -gnata switch? - Bob ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 21:59 ` Robert A Duff @ 2012-08-07 22:19 ` Adam Beneschan 2012-08-08 0:37 ` Robert A Duff 0 siblings, 1 reply; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 22:19 UTC (permalink / raw) On Tuesday, August 7, 2012 2:59:54 PM UTC-7, Robert A Duff wrote: > > subtype Country_Code is String (1 .. 2) > > with Static_Predicate => > > Country_Code (1) in 'A' .. 'Z' and > > Country_Code (2) in 'A' .. 'Z'; > > Or "type Country_Code is String (1 .. 2) with ...". should be "type Country_Code is new String (1 .. 2) with ...", I think ... ^^^ -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 22:19 ` Adam Beneschan @ 2012-08-08 0:37 ` Robert A Duff 0 siblings, 0 replies; 69+ messages in thread From: Robert A Duff @ 2012-08-08 0:37 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > On Tuesday, August 7, 2012 2:59:54 PM UTC-7, Robert A Duff wrote: > >> > subtype Country_Code is String (1 .. 2) >> > with Static_Predicate => >> > Country_Code (1) in 'A' .. 'Z' and >> > Country_Code (2) in 'A' .. 'Z'; >> >> Or "type Country_Code is String (1 .. 2) with ...". > > should be "type Country_Code is new String (1 .. 2) with ...", I think ... Yes. Thank you for the correction. - Bob ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 8:44 ` Marius Amado-Alves 2012-08-07 13:14 ` Marius Amado-Alves @ 2012-08-07 15:26 ` Adam Beneschan 2012-08-07 18:07 ` Marius Amado-Alves 1 sibling, 1 reply; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 15:26 UTC (permalink / raw) On Tuesday, August 7, 2012 1:44:37 AM UTC-7, Marius Amado-Alves wrote: > On Tuesday, August 7, 2012 12:07:02 AM UTC+1, Adam Beneschan wrote: > > What needs to change is the language doing the obvious thing: if types are compatible (down to no any level of composition) then they are convertible. > > I was pretty sure arrays of convertible elements were convertible and I am much surprised to find they are not and I am still not convinced that this is not a compiler bug. The language rule is 4.6(24.5/2): when converting between different array types, "The component subtypes shall statically match". Statically matching subtypes means that the constraints have to be the same (and, basically, the compiler has to be able to tell at compile time that they're the same). The rule has been there since the beginning of Ada 95; however, I believe that in Ada 83, the type conversion would have failed at runtime since the component subtypes don't have the same constraints (AI83-00022 confirms this, I think). Thus, the language has never required a component-by-component constraint check when converting an array type. We can argue about whether that's the right decision; but as far as I know, nobody has complained about this in 29 years [*], and most likely there has been very little need to define array-of-character types with constraints on the component subtypes, until they added these types to Ada.Locales. So this is not a compiler bug. [*] I don't see anything in a quick scan of the AI83's, AI95's, AI05's, or Ada Commentaries. However, if there are other places where new feature requests can be formally made, I don't know where they are. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 15:26 ` Adam Beneschan @ 2012-08-07 18:07 ` Marius Amado-Alves 0 siblings, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-07 18:07 UTC (permalink / raw) > The language rule is 4.6(24.5/2): when converting between different array types, "The component subtypes shall statically match". Statically matching subtypes means that the constraints have to be the same. (Adam) Then the rule is extremely silly because the whole point of a conversion is to transfer between DIFFERENT types. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 19:34 ` Simon Wright 2012-08-06 20:07 ` Marius Amado-Alves @ 2012-08-07 17:51 ` Simon Wright 1 sibling, 0 replies; 69+ messages in thread From: Simon Wright @ 2012-08-07 17:51 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > GNAT GPL 2012 (20120509) > Copyright 1992-2012, Free Software Foundation, Inc. > > > Compiling: locales.adb (source file time stamp: 2012-08-06 19:30:36) > > 1. with Ada.Locales; > | > >>> warning: "Ada.Locales" is an internal GNAT unit > >>> warning: use of this unit is non-portable and version-dependent Ada.Locales isn't an internal GNAT unit, at least when compiling with -gnat12; AdaCore have fixed this in their latest Pro development version. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 19:15 ` J-P. Rosen 2012-08-06 19:34 ` Simon Wright @ 2012-08-06 20:00 ` Marius Amado-Alves 1 sibling, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 20:00 UTC (permalink / raw) > But they can be converted to String: > > Put_Line (String (Country)); > > J-P. Rosen I know! Theoretically this should work, but it doesn't! I'll check again. Thanks. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 17:10 ` Marius Amado-Alves 2012-08-06 19:15 ` J-P. Rosen @ 2012-08-06 19:49 ` Jacob Sparre Andersen 2012-08-06 20:11 ` Marius Amado-Alves 1 sibling, 1 reply; 69+ messages in thread From: Jacob Sparre Andersen @ 2012-08-06 19:49 UTC (permalink / raw) Marius Amado-Alves wrote: > To clarify: Put_Line does NOT work. The compiler (GNAT GPL 2012) says: > > Put_Line (Country) => > expected type "Standard.String" > found type "Ada.Locales.Country_Code" > > Put_Line (String (Country)) => > component subtypes must statically match It isn't beautiful, but what about: Put_Line (String'(1 => Country (1), 2 => Country (2), 3 => Country (3))); Greetings, Jacob -- Insanity: doing the same thing over and over again and expecting different results. (Albert Einstein) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 19:49 ` Jacob Sparre Andersen @ 2012-08-06 20:11 ` Marius Amado-Alves 0 siblings, 0 replies; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 20:11 UTC (permalink / raw) On Monday, August 6, 2012 8:49:01 PM UTC+1, Jacob Sparre Andersen wrote: > It isn't beautiful, but what about: > Put_Line (String'(1 => Country (1), > 2 => Country (2), > 3 => Country (3))); This should work... but also should the obvious (not ugly) conversion Put (String (Country)); !! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 16:45 Ada.Locales pseudo-string types Marius Amado-Alves 2012-08-06 17:10 ` Marius Amado-Alves @ 2012-08-06 17:37 ` Michael Rohan 2012-08-06 18:23 ` Marius Amado-Alves 2012-08-09 21:15 ` Randy Brukardt 2012-08-07 5:57 ` Jeffrey R. Carter 2 siblings, 2 replies; 69+ messages in thread From: Michael Rohan @ 2012-08-06 17:37 UTC (permalink / raw) On Monday, August 6, 2012 9:45:46 AM UTC-7, Marius Amado-Alves wrote: > Ada 2012 has this new Ada.Locales package (annex A.19) containing > > > > type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; > > type Country_Code is array (1 .. 2) of Character range 'A' .. 'Z'; > > > > Language_Unknown : constant Language_Code := "und"; > > Country_Unknown : constant Country_Code := "ZZ"; > > > > function Language return Language_Code; > > function Country return Country_Code; > > > > Now how does one print the darn codes? Should not Ada.Text_IO.Put for String work? Should not the types be convertible to String? > > Thanks a lot. Hi, It this really the all that's defined for Locales! At least the language code is of the correct length 1 .. 3, however the country code should also be 1 .. 3, On Monday, August 6, 2012 9:45:46 AM UTC-7, Marius Amado-Alves wrote: > Ada 2012 has this new Ada.Locales package (annex A.19) containing > > > > type Language_Code is array (1 .. 3) of Character range 'a' .. 'z'; > > type Country_Code is array (1 .. 2) of Character range 'A' .. 'Z'; > > > > Language_Unknown : constant Language_Code := "und"; > > Country_Unknown : constant Country_Code := "ZZ"; > > > > function Language return Language_Code; > > function Country return Country_Code; > > > > Now how does one print the darn codes? Should not Ada.Text_IO.Put for String work? Should not the types be convertible to String? > > Thanks a lot. Hi, Looks like this probably needs to be adjusted Language 1 .. 3 is OK, but Country should really be Territory 1 .. 3, e.g., Latin America has the code "419". It is also missing a definition for the Script, e.g., Simplified Chinese as spoken in China is zh_Hans_CN, and Serbian has two variants for the same territory: sr_Cyrl_SR, Serbian as spoken in Serbia using the Cyrillic script sr_Latn_SR, Serbian as spoken in Serbia using the Latin script So the locales package should be adjusted to include type Script_Code is array (1 .. 4) of Character; -- 'a' .. 'z' + 'A' .. 'Z' function Script return Script_Code; There's nothing here to adjust locale, etc. I guess this is start on making Ada locale aware but it looks like there's a lot of additional work needed. I've done some work in this area with my ZanyBlue library (http://zanyblue.sourceforge.net) and it would be good to see a more globalization friendly Ada. Take care, Michael ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 17:37 ` Michael Rohan @ 2012-08-06 18:23 ` Marius Amado-Alves 2012-08-06 19:36 ` Michael Rohan 2012-08-09 21:15 ` Randy Brukardt 1 sibling, 1 reply; 69+ messages in thread From: Marius Amado-Alves @ 2012-08-06 18:23 UTC (permalink / raw) > It this really the all that's defined for Locales! ... This package is only for the identification of the runtime locale. So no need for 3-letter country codes, neither for all other codes: such databases are necessary for many applications, but it's ok to let them outside the language. /* I think the package being called Locales, plural, is confusing. I know there is a convention of using plurals for package names, but it should have been avoided in this case. Runtime_Locale. */ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 18:23 ` Marius Amado-Alves @ 2012-08-06 19:36 ` Michael Rohan 0 siblings, 0 replies; 69+ messages in thread From: Michael Rohan @ 2012-08-06 19:36 UTC (permalink / raw) On Monday, August 6, 2012 11:23:34 AM UTC-7, Marius Amado-Alves wrote: > > It this really the all that's defined for Locales! ... > > > > This package is only for the identification of the runtime locale. So no need for 3-letter country codes, neither for all other codes: such databases are necessary for many applications, but it's ok to let them outside the language. > > > > /* I think the package being called Locales, plural, is confusing. I know there is a convention of using plurals for package names, but it should have been avoided in this case. Runtime_Locale. */ Hi, The spec file for what I believe locales should support is available at http://zanyblue.sourceforge.net/zanyblue/ref/zanyblue-text-locales__ads.html Just fyi. Take care, Michael. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 17:37 ` Michael Rohan 2012-08-06 18:23 ` Marius Amado-Alves @ 2012-08-09 21:15 ` Randy Brukardt 1 sibling, 0 replies; 69+ messages in thread From: Randy Brukardt @ 2012-08-09 21:15 UTC (permalink / raw) "Michael Rohan" <michael@zanyblue.com> wrote in message news:a6439817-c750-4c5e-a0db-2c37331b474e@googlegroups.com... ... > It this really the all that's defined for Locales! At least the language > code is > of the correct length 1 .. 3, however the country code should also be 1 .. > 3, These codes come from other ISO standards, used in many applications (including Posix). The lengths and definitions are exactly as those other standards (ISO 639-3 and ISO 3166-1) prescribe. You can look up the country and language codes on-line (both of those standards are public). See the list of other standards referenced by the Ada Standard for details. ... >Looks like this probably needs to be adjusted Language 1 .. 3 is OK, but >Country > should really be Territory 1 .. 3, e.g., Latin America has the code "419". Umm, no it doesn't. > It is also missing a definition for the Script, e.g., Simplified Chinese > as > spoken in China is zh_Hans_CN, and Serbian has two variants for the same > territory: That's part of the language code. Again, see the relevant ISO standards. ... >There's nothing here to adjust locale, etc. That's intentional: not all systems allow that. > I guess this is start on making Ada locale aware but it looks like there's > a lot of additional work needed. Of course, having this information doesn't necessarily allow you to do anything with it. There was absolutely no agreement on the value of having any such capabilities in the Standard (and capabilities of host OSes vary wildly). But just retrieving the current information was easy enough to support, and it allows programming in-house solutions on top of it. (For instance, the original requirement came from Canada, which needs to support both English and French in applications, but doesn't necessarily want to go beyond that.) Randy. Randy. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-06 16:45 Ada.Locales pseudo-string types Marius Amado-Alves 2012-08-06 17:10 ` Marius Amado-Alves 2012-08-06 17:37 ` Michael Rohan @ 2012-08-07 5:57 ` Jeffrey R. Carter 2012-08-07 15:46 ` Adam Beneschan 2 siblings, 1 reply; 69+ messages in thread From: Jeffrey R. Carter @ 2012-08-07 5:57 UTC (permalink / raw) This works: with Ada.Text_IO; with Ada.Unchecked_Conversion; procedure Weird_Output is type Weird is array (Positive range 1 .. 3) of Character range 'A' .. 'Z'; subtype Weird_Image is String (1 .. 3); function Image is new Ada.Unchecked_Conversion (Source => Weird, Target => Weird_Image); C : constant Weird := "ABC"; begin -- Weird_Output Ada.Text_IO.Put_Line (Item => Image (C) ); end Weird_Output; ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 5:57 ` Jeffrey R. Carter @ 2012-08-07 15:46 ` Adam Beneschan 2012-08-07 17:51 ` Jeffrey R. Carter 0 siblings, 1 reply; 69+ messages in thread From: Adam Beneschan @ 2012-08-07 15:46 UTC (permalink / raw) On Monday, August 6, 2012 10:57:33 PM UTC-7, Jeffrey R. Carter wrote: > This works: > > with Ada.Text_IO; > with Ada.Unchecked_Conversion; > > procedure Weird_Output is > type Weird is array (Positive range 1 .. 3) of Character range 'A' .. 'Z'; > > subtype Weird_Image is String (1 .. 3); > > function Image is new Ada.Unchecked_Conversion (Source => Weird, Target => Weird_Image); > > C : constant Weird := "ABC"; > begin -- Weird_Output > Ada.Text_IO.Put_Line (Item => Image (C) ); > end Weird_Output; Blecch. Using Unchecked_Conversion seems like a good solution--if it's buried in the implementation of a To_String function in the body of Ada.Locales as I proposed. Making users use it is just icky. -- Adam ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 15:46 ` Adam Beneschan @ 2012-08-07 17:51 ` Jeffrey R. Carter 2012-08-09 21:17 ` Randy Brukardt 0 siblings, 1 reply; 69+ messages in thread From: Jeffrey R. Carter @ 2012-08-07 17:51 UTC (permalink / raw) On Tuesday, August 7, 2012 8:46:09 AM UTC-7, Adam Beneschan wrote: > > Blecch. Using Unchecked_Conversion seems like a good solution--if it's buried in the implementation of a To_String function in the body of Ada.Locales as I proposed. Making users use it is just icky. I agree. But given that we have a situation where users have to deal with this kind of declaration ... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Ada.Locales pseudo-string types 2012-08-07 17:51 ` Jeffrey R. Carter @ 2012-08-09 21:17 ` Randy Brukardt 0 siblings, 0 replies; 69+ messages in thread From: Randy Brukardt @ 2012-08-09 21:17 UTC (permalink / raw) "Jeffrey R. Carter" <ggsub@pragmada.co.cc> wrote in message news:21aeae92-e309-4193-b29e-66d73df00569@googlegroups.com... > On Tuesday, August 7, 2012 8:46:09 AM UTC-7, Adam Beneschan wrote: >> >> Blecch. Using Unchecked_Conversion seems like a good solution--if it's >> buried in the implementation of a To_String function in the body of >> Ada.Locales as I proposed. Making users use it is just icky. > > I agree. But given that we have a situation where users have to deal with > this kind of declaration ... Since the number of characters are limited here, it's trivial to output them as an aggregate (as someone else already suggested): Put (String'(Country(1), Country(2), Country(3))); Admittedly, it looks pretty silly, but no Unchecked_Conversions are needed. (It's hard to get worked up about this "problem", given the relatively easy solution.) Randy. ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2012-08-15 2:48 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-06 16:45 Ada.Locales pseudo-string types Marius Amado-Alves 2012-08-06 17:10 ` Marius Amado-Alves 2012-08-06 19:15 ` J-P. Rosen 2012-08-06 19:34 ` Simon Wright 2012-08-06 20:07 ` Marius Amado-Alves 2012-08-06 20:57 ` Simon Wright 2012-08-06 21:09 ` Vasiliy Molostov 2012-08-06 23:07 ` Adam Beneschan 2012-08-06 23:23 ` Vasiliy Molostov 2012-08-06 23:46 ` Adam Beneschan 2012-08-07 1:17 ` Vasiliy Molostov 2012-08-07 7:20 ` Dmitry A. Kazakov 2012-08-07 7:43 ` Jacob Sparre Andersen 2012-08-09 20:47 ` Randy Brukardt 2012-08-07 8:44 ` Marius Amado-Alves 2012-08-07 13:14 ` Marius Amado-Alves 2012-08-07 15:42 ` Adam Beneschan 2012-08-07 18:22 ` Marius Amado-Alves 2012-08-07 20:10 ` Adam Beneschan 2012-08-07 20:42 ` Marius Amado-Alves 2012-08-07 21:38 ` Adam Beneschan 2012-08-08 7:04 ` Niklas Holsti 2012-08-08 7:18 ` Dmitry A. Kazakov 2012-08-08 7:37 ` Niklas Holsti 2012-08-08 8:09 ` Dmitry A. Kazakov 2012-08-08 11:14 ` Niklas Holsti 2012-08-08 11:59 ` Dmitry A. Kazakov 2012-08-08 14:01 ` Niklas Holsti 2012-08-09 7:48 ` Dmitry A. Kazakov 2012-08-09 8:31 ` Niklas Holsti 2012-08-09 12:17 ` Dmitry A. Kazakov 2012-08-09 15:25 ` Niklas Holsti 2012-08-09 16:43 ` Dmitry A. Kazakov 2012-08-08 8:28 ` J-P. Rosen 2012-08-08 11:35 ` Niklas Holsti 2012-08-08 14:05 ` Georg Bauhaus 2012-08-08 7:32 ` J-P. Rosen 2012-08-08 8:17 ` Niklas Holsti 2012-08-08 8:33 ` J-P. Rosen 2012-08-08 11:44 ` Niklas Holsti 2012-08-09 21:00 ` Randy Brukardt 2012-08-08 8:35 ` Dmitry A. Kazakov 2012-08-08 9:32 ` Marius Amado-Alves 2012-08-08 10:11 ` Dmitry A. Kazakov 2012-08-08 11:28 ` Marius Amado-Alves 2012-08-08 11:30 ` Marius Amado-Alves 2012-08-08 11:35 ` Marius Amado-Alves 2012-08-08 12:24 ` Dmitry A. Kazakov 2012-08-08 11:52 ` Niklas Holsti 2012-08-08 13:21 ` Dmitry A. Kazakov 2012-08-08 9:07 ` Marius Amado-Alves 2012-08-07 20:43 ` Marius Amado-Alves 2012-08-07 21:59 ` Robert A Duff 2012-08-07 22:19 ` Adam Beneschan 2012-08-08 0:37 ` Robert A Duff 2012-08-07 15:26 ` Adam Beneschan 2012-08-07 18:07 ` Marius Amado-Alves 2012-08-07 17:51 ` Simon Wright 2012-08-06 20:00 ` Marius Amado-Alves 2012-08-06 19:49 ` Jacob Sparre Andersen 2012-08-06 20:11 ` Marius Amado-Alves 2012-08-06 17:37 ` Michael Rohan 2012-08-06 18:23 ` Marius Amado-Alves 2012-08-06 19:36 ` Michael Rohan 2012-08-09 21:15 ` Randy Brukardt 2012-08-07 5:57 ` Jeffrey R. Carter 2012-08-07 15:46 ` Adam Beneschan 2012-08-07 17:51 ` Jeffrey R. Carter 2012-08-09 21:17 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox