Ada.Locales pseudo-string types

Ada.Locales pseudo-string types

[Marius Amado-Alves]

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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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

Re: Ada.Locales pseudo-string types

[Michael Rohan]

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

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> 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. */

Re: Ada.Locales pseudo-string types

[J-P. Rosen]

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

Re: Ada.Locales pseudo-string types

[Simon Wright]

"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!

Re: Ada.Locales pseudo-string types

[Michael Rohan]

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.

Re: Ada.Locales pseudo-string types

[Jacob Sparre Andersen]

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)

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> 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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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!

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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));

!!

Re: Ada.Locales pseudo-string types

[Simon Wright]

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".

Re: Ada.Locales pseudo-string types

[Vasiliy Molostov]

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/

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Vasiliy Molostov]

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/

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Vasiliy Molostov]

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/

Re: Ada.Locales pseudo-string types

[Jeffrey R. Carter]

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;

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Jacob Sparre Andersen]

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 :)"

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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.)

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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).

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Jeffrey R. Carter]

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 ...

Re: Ada.Locales pseudo-string types

[Simon Wright]

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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> 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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> >    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.

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> > > >    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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> > ... 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.

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Robert A Duff]

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

Re: Ada.Locales pseudo-string types

[Adam Beneschan]

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

Re: Ada.Locales pseudo-string types

[Robert A Duff]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[J-P. Rosen]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[J-P. Rosen]

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

Re: Ada.Locales pseudo-string types

[J-P. Rosen]

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

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> 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!

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

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.

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> > 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.

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> > That depends on the way you define wrongness.
> 
> An invalid value.

or an exception, or a crash...

Re: Ada.Locales pseudo-string types

[Marius Amado-Alves]

> 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'); 

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Georg Bauhaus]

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;

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Niklas Holsti]

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
      .      @       .

Re: Ada.Locales pseudo-string types

[Dmitry A. Kazakov]

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

Re: Ada.Locales pseudo-string types

[Randy Brukardt]

"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.

Re: Ada.Locales pseudo-string types

[Randy Brukardt]

[-- 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.

Re: Ada.Locales pseudo-string types

[Randy Brukardt]

"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.

Re: Ada.Locales pseudo-string types

[Randy Brukardt]

"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.