* Re: Looking for feedback: ISO 3166-1 country Country Code Reference in Ada
2023-04-15 18:52 8% Looking for feedback: ISO 3166-1 country Country Code Reference in Ada A.J.
@ 2023-04-17 9:36 0% ` Jeffrey R.Carter
0 siblings, 0 replies; 84+ results
From: Jeffrey R.Carter @ 2023-04-17 9:36 UTC (permalink / raw)
On 2023-04-15 20:52, A.J. wrote:
> I just created a library for accessing ISO 3166-1 records in Ada compatible with Ada.Locales. Before I try to publish it to Alire, I'm hoping to get some feedback if anyone has some. It's possible that feedback will result in the function calls, naming convention, or structure being set up differently, so please let me know what you think.
>
> https://github.com/AJ-Ianozi/iso_3166
Some initial thoughts on what you have:
It seems likely that your clients will use the alpha codes for input and
display. It will be more convenient for that if the alpha codes are subtypes of
String rather than distinct types.
Since you have already enumerated all 250 possible alpha codes, your predicates
could look like
subtype Alpha_Code_2 is String (1 .. 2) with
Dynamic_Predicate => Alpha_Code_2 in "AF" | "AL" | ...;
and similar for the 3-letter codes.
Since you have already enumerated all 250 possible numeric codes, you could use
a restricted range for your numeric (sub)type, with a predicate restricting it
to valid values.
These use the language to do validity checking for you.
Regarding the design of such a pkg, my initial instinct was to use enumeration
types for the alpha codes, but a little investigation shows that some of the
codes are Ada reserved words, so that doesn't work. So I would stick with the
String subtypes and provide functions such that, given one of the values, the
client can obtain the others, as well as the name. Alternatively, one could have
functions to return a record such as you provide. Which is preferable depends on
how such a pkg is typically used.
There are various possible implementations, with different tradeoffs.
--
Jeff Carter
"He nevere yet no vileynye ne sayde
In al his lyf unto no maner wight."
Canterbury Tales
156
^ permalink raw reply [relevance 0%]
* Looking for feedback: ISO 3166-1 country Country Code Reference in Ada
@ 2023-04-15 18:52 8% A.J.
2023-04-17 9:36 0% ` Jeffrey R.Carter
0 siblings, 1 reply; 84+ results
From: A.J. @ 2023-04-15 18:52 UTC (permalink / raw)
I just created a library for accessing ISO 3166-1 records in Ada compatible with Ada.Locales. Before I try to publish it to Alire, I'm hoping to get some feedback if anyone has some. It's possible that feedback will result in the function calls, naming convention, or structure being set up differently, so please let me know what you think.
https://github.com/AJ-Ianozi/iso_3166
I also posted this on the subreddit, so apologies for any redundancy for those viewing both!
^ permalink raw reply [relevance 8%]
* Re: Currency Library for Ada?
2023-04-13 17:37 8% ` J-P. Rosen
@ 2023-04-13 18:12 0% ` A.J.
0 siblings, 0 replies; 84+ results
From: A.J. @ 2023-04-13 18:12 UTC (permalink / raw)
J-P. Rosen,
On Thursday, April 13, 2023 at 1:37:22 PM UTC-4, J-P. Rosen wrote:
> It's a standard package, Ada.Locales
Thanks for finding that! This looks like a good foundation for validating county codes, though it doesn't appear to contain an index of them, or expand into the 3-letter codes (e.g. USA vs US). I was looking into the implementation, and the GNAT[1] runtime seems to be true to spec, while the Drake runtime[2] looks like it's expanding into closer to what I'm looking for with its iso639 tables [3]. I may be able to build on this set, though and use the existing structures.
AJ
[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgnat/a-locale.ads & https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgnat/a-locale.adb
[2] https://github.com/ytomino/drake/blob/master/source/environment/a-locale.ads
[3] https://github.com/ytomino/drake/blob/master/source/environment/a-locale.adb#L60
^ permalink raw reply [relevance 0%]
* Re: Currency Library for Ada?
@ 2023-04-13 17:37 8% ` J-P. Rosen
2023-04-13 18:12 0% ` A.J.
0 siblings, 1 reply; 84+ results
From: J-P. Rosen @ 2023-04-13 17:37 UTC (permalink / raw)
Le 13/04/2023 à 16:17, A.J. a écrit :
> I'm also interested in if there's any ada libraries for iso 3166 (country codes).
It's a standard package, Ada.Locales
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr
^ permalink raw reply [relevance 8%]
* Re: Is the Documentation In a spec File Usually Enough For You ?
@ 2018-10-18 15:24 6% ` Brad Moore
0 siblings, 0 replies; 84+ results
From: Brad Moore @ 2018-10-18 15:24 UTC (permalink / raw)
It should also be mentioned that with Ada 2012, the addition of contracts helps also aid to reader of a spec understand what a subprogram does, and how it was intended to be used by the author.
A problem with documentation is that it can become stale if not maintained, whereas the contracts are assertions in the code and thus tend to be more accurate.
A designer of a package should consider, for example, what pre and post conditions should be applied to the subprograms of that package. The addition of contracts tends to simplify the documentation that is needed.
As an example, in the standard package
Ada.Locales, there is;
type Country_Code is new String (1 .. 2)
with Dynamic_Predicate =>
(for all E of Country_Code => E in 'A' .. 'Z');
function Country return Country_Code;
If we didn't have the contract for Dynamic_Predicate on the Country_Code type,
we would need to document that the function Country returns a 2 character string where all the characters of the string consist of capital letters from A to Z inclusive.
With the contract, this doesn't need to be documented, and the contract is more concise for the reader than having to read a full paragraph of text. Further, anywhere the Country_Code result is used in the user's program, it is clear that the contract holds, since it is a property of the type.
If the implementation changes in a way that breaks the contracts, then this tends to get caught, and either the implementation is adjusted to meet the contracts, or the contracts are adjusted to meet the implementation. Generally one tries to avoid making changes to contracts, particularly if there are existing users of those contracts.
Brad
^ permalink raw reply [relevance 6%]
* Re: gettext for Ada
@ 2017-11-23 20:24 7% ` Shark8
0 siblings, 0 replies; 84+ results
From: Shark8 @ 2017-11-23 20:24 UTC (permalink / raw)
On Thursday, November 23, 2017 at 11:55:46 AM UTC-7, G. B. wrote:
> Shark8 wrote:
>
> >> The set of locales may grow. ‘Last etc. would change.
> >
> > Why would you use 'Last or 'Succ on languages?
>
> No type can be exempt from general Ada semantics.
> That’s like asking why I would use 13 for Ada in the USA?
I'm not saying the type should be exempt from the general semantics; I'm saying that the operations don't make sense in the context of language... and that fact could be put into the standard with something like:
"The order and position of the Language and Locale types should not be relied upon, particularly since the referenced standards may be updated and Package Ada.Locales may be updated at any time to reflect the current state of those standards; therefore, usage of 'First, 'Last, 'Succ, 'Pred, 'Val, and 'Pos are discouraged."
Getting the proper value when the OS (or some non-Ada library) returns a string could be done via the 'Value attribute; e.g.:
Function Get_Language return Language is
Function OS_Get_Language return C_String
with Import, Convention => C, Link_Name => "getlang";
Begin
Return Language'Value( To_Ada_String( OS_Get_Language ) );
Exception
When Constraint_Error => Return und;
End Get Language;
^ permalink raw reply [relevance 7%]
* Re: gettext for Ada
2017-11-23 0:30 0% ` Randy Brukardt
@ 2017-11-23 3:08 0% ` Shark8
0 siblings, 0 replies; 84+ results
From: Shark8 @ 2017-11-23 3:08 UTC (permalink / raw)
On Wednesday, November 22, 2017 at 5:30:28 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message
> news:f008ea86-60a5-411d-88ab-0130bcda63a8...
> On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote:
> ...
> >> I would make a set of parallel child packages with the same operations in
> >> each. Then one could use an if (or maybe a case, if the proposed Ada 2020
> >> extension comes to pass) to select them.
> >
> >Are you talking about a case-statement for selecting a child package,
> >perhaps something like:
> > PACKAGE Actual_Messages RENAMES (CASE Language is
> > WHEN English => Messages.English, WHEN German => Messages.German,
> > WHEN French => Messages.French, WHEN OTHERS => Raise Program_Error)
> >?? -- or something like case-selection on strings? -- or something
> >different altogether?
>
> Case selection on fixed length strings (which these are). Would need an
> others clause, of course.
Is it a case-insensitive string comparison? Because case-sensitive would make your cases explode exponentially if it weren't... and if they ARE case-insensitive I'd expect a lot of programmers (notably those of C backgrounds) to complain. (Or is there some sort of magic/syntax to determine between the two?)
In all, CASE-on-Strings is rather disappointing... it kinda comes off as an "Ada also does X like Java!"-feature like INTERFACE was/is. (Interface could have, and IMO should have, been far more useful than Java's notion.)
Something like extending CASE to renaming-packages or extending the GENERIC hierarchy sounds much more useful to me. {There are several interesting ways generics could be extended: (a) allowing non-generic packages as parameters, which would require some ability to specify characteristics about the publicly available properties of the specification [honestly, a LOT of work, but could simplify the construction of standard packages]; (b) allowing generic subprograms in a manner like current generic packages may be parametrized; (c) easing some restrictions on incomplete formal parameters, allowing a function returning said type to be used.}
>
> >> Or (perhaps better), use a full OOP design, with an abstract Root_Locale
> >> type (with a set of dispatching operations), a series of specific Locale
> >> types (English_Locale, French_Locale, etc.) giving implementations to
> >> those
> >> types, and a map and factory to create objects of those types as needed.
> >> (The Claw GUI Builder has an internal design much like this, other than
> >> the
> >> factory, which didn't exist in Ada 95, so I had to use a massive case
> >> statement instead. A factory would have been much better.)
> >
> >Do you still have the giant case, or did you opt to use the
> > Generic_Dispatching_Constructor when Ada 2005 added it?
>
> Claw is still pure Ada 95 code.
Ah, I see.
I remember you mentioning that Janus/Ada had a few Ada 2005 features implemented and was wondering if perhaps something like updating Claw (or some similar SW package) was the/a motivating factor.
>
> >> > Also, shouldn't the stuff in Ada.Locales actually be proper
> >> > enumerations rather than strings?
> >>
> >> There's a near infinite number of possible Locales, so enumerating them
> >> is
> >> next to impossible. We decided against even giving names to the most
> >> common
> >> ones, as that would have led to endless debates about which ones are the
> >> most important. The strings come from a freely available ISO standard, so
> >> they will never change and are easy to find out and are maintained by
> >> someone other than us Ada people (so no need for debates on our end on
> >> topics outside of our expertise). This is the same reason that we depend
> >> on
> >> character set standards rather than rolling our own character set rules
> >> (even though the latter would be easier to maintain, we wouldn't really
> >> know
> >> what we were doing).
> >
> >Er... "The strings come from a freely available ISO standard, so they will
> >never change"
> >
> >So why not enumerate the strings, that way proper cases can be done on
> >either languages and/or locales?
>
> Because the underlying Standard changes frequently, adding new languages and
> locales. There is no practical way to do that for Ada enumerations. (Note
> that I said the "strings don't change", meaning that the meanings of the
> strings don't change, not that the *list* of strings doesn't change often,
> usually with new additions.)
And? / I fail to see a meaningful distinction here.
>
> >
> >-- ISO 3166-1 Country & Territory Codes
> >-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
> >Type Locale is (
> > AF, -- Afghanistan
> > AX, -- Åland Islands
> ...
>
> There are many hundreds of locales, and new ones are added periodically.
> Maintaining that in the Ada standard would be a nightmare, and what
> precisely would be the point? The same applies (even moreso) to languages.
>
> In addition, this scheme would fail misreably if an OS update caused some
> unknown (to Ada) locale or language to be returned. That's not possible for
> the string scheme (as it matches both the ISO Standard and what OSes
> actually do).
No; it really wouldn't, there are enumerations that perfectly map to "I don't understand this"-states:
From my example:
* Locale'(ZZ)
* Language'(und)
If you're encountering unknown-to-Ada locale/language the correct thing to do is either FAIL (throw the appropriate exception) and/or DEFAULT to something that is known.
^ permalink raw reply [relevance 0%]
* Re: gettext for Ada
2017-11-22 15:38 0% ` Shark8
@ 2017-11-23 0:30 0% ` Randy Brukardt
2017-11-23 3:08 0% ` Shark8
1 sibling, 1 reply; 84+ results
From: Randy Brukardt @ 2017-11-23 0:30 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
"Shark8" <onewingedshark@gmail.com> wrote in message
news:f008ea86-60a5-411d-88ab-0130bcda63a8@googlegroups.com...
On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote:
...
>> I would make a set of parallel child packages with the same operations in
>> each. Then one could use an if (or maybe a case, if the proposed Ada 2020
>> extension comes to pass) to select them.
>
>Are you talking about a case-statement for selecting a child package,
>perhaps something like:
> PACKAGE Actual_Messages RENAMES (CASE Language is
> WHEN English => Messages.English, WHEN German => Messages.German,
> WHEN French => Messages.French, WHEN OTHERS => Raise Program_Error)
>?? -- or something like case-selection on strings? -- or something
>different altogether?
Case selection on fixed length strings (which these are). Would need an
others clause, of course.
>> Or (perhaps better), use a full OOP design, with an abstract Root_Locale
>> type (with a set of dispatching operations), a series of specific Locale
>> types (English_Locale, French_Locale, etc.) giving implementations to
>> those
>> types, and a map and factory to create objects of those types as needed.
>> (The Claw GUI Builder has an internal design much like this, other than
>> the
>> factory, which didn't exist in Ada 95, so I had to use a massive case
>> statement instead. A factory would have been much better.)
>
>Do you still have the giant case, or did you opt to use the
> Generic_Dispatching_Constructor when Ada 2005 added it?
Claw is still pure Ada 95 code.
>> > Also, shouldn't the stuff in Ada.Locales actually be proper
>> > enumerations rather than strings?
>>
>> There's a near infinite number of possible Locales, so enumerating them
>> is
>> next to impossible. We decided against even giving names to the most
>> common
>> ones, as that would have led to endless debates about which ones are the
>> most important. The strings come from a freely available ISO standard, so
>> they will never change and are easy to find out and are maintained by
>> someone other than us Ada people (so no need for debates on our end on
>> topics outside of our expertise). This is the same reason that we depend
>> on
>> character set standards rather than rolling our own character set rules
>> (even though the latter would be easier to maintain, we wouldn't really
>> know
>> what we were doing).
>
>Er... "The strings come from a freely available ISO standard, so they will
>never change"
>
>So why not enumerate the strings, that way proper cases can be done on
>either languages and/or locales?
Because the underlying Standard changes frequently, adding new languages and
locales. There is no practical way to do that for Ada enumerations. (Note
that I said the "strings don't change", meaning that the meanings of the
strings don't change, not that the *list* of strings doesn't change often,
usually with new additions.)
>
>-- ISO 3166-1 Country & Territory Codes
>-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
>Type Locale is (
> AF, -- Afghanistan
> AX, -- Åland Islands
...
There are many hundreds of locales, and new ones are added periodically.
Maintaining that in the Ada standard would be a nightmare, and what
precisely would be the point? The same applies (even moreso) to languages.
In addition, this scheme would fail misreably if an OS update caused some
unknown (to Ada) locale or language to be returned. That's not possible for
the string scheme (as it matches both the ISO Standard and what OSes
actually do).
Randy.
Randy.
^ permalink raw reply [relevance 0%]
* Re: gettext for Ada
2017-11-22 1:10 0% ` Randy Brukardt
@ 2017-11-22 15:38 0% ` Shark8
2017-11-23 0:30 0% ` Randy Brukardt
0 siblings, 2 replies; 84+ results
From: Shark8 @ 2017-11-22 15:38 UTC (permalink / raw)
On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message
> news:40dc6a79-9434-4b5a-bed0-50ee1dfb74c5...
> > On Monday, November 20, 2017 at 3:43:21 PM UTC-7, Randy Brukardt wrote:
> >> "Shark8" wrote in message
> >> news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f...
> >> On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
> >> > Where can I get a gettext bindings for Ada?
> >>
> >> ...
> >> >And then at compile-time select the proper language to build the
> >> >application via
> >> >GPR-projects, makefiles, or whatever paramaterizable build-system you
> >> >wish
> >> >to use.
> >>
> >> Or, use parallel packages and select the correct one to use at runtime
> >> based
> >> on Ada.Locales (A.19). That's the primary purpose of the Locales package,
> >> after all.
> >
> > Parallel packages? I've not heard the term before, how are they used &
> > selected
> > at runtime?
>
> I would make a set of parallel child packages with the same operations in
> each. Then one could use an if (or maybe a case, if the proposed Ada 2020
> extension comes to pass) to select them.
Are you talking about a case-statement for selecting a child package, perhaps something like:
PACKAGE Actual_Messages RENAMES (CASE Language is
WHEN English => Messages.English, WHEN German => Messages.German,
WHEN French => Messages.French, WHEN OTHERS => Raise Program_Error)
?? -- or something like case-selection on strings? -- or something different altogether?
>
> Or (perhaps better), use a full OOP design, with an abstract Root_Locale
> type (with a set of dispatching operations), a series of specific Locale
> types (English_Locale, French_Locale, etc.) giving implementations to those
> types, and a map and factory to create objects of those types as needed.
> (The Claw GUI Builder has an internal design much like this, other than the
> factory, which didn't exist in Ada 95, so I had to use a massive case
> statement instead. A factory would have been much better.)
Do you still have the giant case, or did you opt to use the Generic_Dispatching_Constructor when Ada 2005 added it?
>
> > Also, shouldn't the stuff in Ada.Locales actually be proper
> > enumerations rather than strings?
>
> There's a near infinite number of possible Locales, so enumerating them is
> next to impossible. We decided against even giving names to the most common
> ones, as that would have led to endless debates about which ones are the
> most important. The strings come from a freely available ISO standard, so
> they will never change and are easy to find out and are maintained by
> someone other than us Ada people (so no need for debates on our end on
> topics outside of our expertise). This is the same reason that we depend on
> character set standards rather than rolling our own character set rules
> (even though the latter would be easier to maintain, we wouldn't really know
> what we were doing).
Er... "The strings come from a freely available ISO standard, so they will never change"
So why not enumerate the strings, that way proper cases can be done on either languages and/or locales?
-- ISO 3166-1 Country & Territory Codes
-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
Type Locale is (
AF, -- Afghanistan
AX, -- Åland Islands
AL, -- Albania
DZ, -- Algeria
AS, -- American Samoa
AD, -- Andorra
...
ZZ -- Unknown Country
);
-- Enumeration of the ISO 639-3 alpha-3 code that identifies a language
-- See: http://www-01.sil.org/iso639-3/codes.asp?order=639_3&letter=%25
Type Language is (
aaa, -- Ghotuo
aab, -- Alumu-Tesu
aac, -- Ari
aad, -- Amal
aae, -- Arbëreshë Albanian
aaf, -- Aranadan
aag, -- Ambrak
aah, -- Abu' Arapesh
...
und, -- Undetermined
...
zyp, -- Zyphe Chin
zza, -- Zaza
zzj -- Zuojiang Zhuang
);
And, perhaps a Image function for Language which returns the lower-cased-string of the enumeration itself.
^ permalink raw reply [relevance 0%]
* Re: gettext for Ada
2017-11-21 0:28 8% ` Shark8
2017-11-21 8:29 0% ` G. B.
@ 2017-11-22 1:10 0% ` Randy Brukardt
2017-11-22 15:38 0% ` Shark8
1 sibling, 1 reply; 84+ results
From: Randy Brukardt @ 2017-11-22 1:10 UTC (permalink / raw)
"Shark8" <onewingedshark@gmail.com> wrote in message
news:40dc6a79-9434-4b5a-bed0-50ee1dfb74c5@googlegroups.com...
> On Monday, November 20, 2017 at 3:43:21 PM UTC-7, Randy Brukardt wrote:
>> "Shark8" wrote in message
>> news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f...
>> On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
>> > Where can I get a gettext bindings for Ada?
>>
>> ...
>> >And then at compile-time select the proper language to build the
>> >application via
>> >GPR-projects, makefiles, or whatever paramaterizable build-system you
>> >wish
>> >to use.
>>
>> Or, use parallel packages and select the correct one to use at runtime
>> based
>> on Ada.Locales (A.19). That's the primary purpose of the Locales package,
>> after all.
>
> Parallel packages? I've not heard the term before, how are they used &
> selected
> at runtime?
I would make a set of parallel child packages with the same operations in
each. Then one could use an if (or maybe a case, if the proposed Ada 2020
extension comes to pass) to select them.
Or (perhaps better), use a full OOP design, with an abstract Root_Locale
type (with a set of dispatching operations), a series of specific Locale
types (English_Locale, French_Locale, etc.) giving implementations to those
types, and a map and factory to create objects of those types as needed.
(The Claw GUI Builder has an internal design much like this, other than the
factory, which didn't exist in Ada 95, so I had to use a massive case
statement instead. A factory would have been much better.)
> Also, shouldn't the stuff in Ada.Locales actually be proper
> enumerations rather than strings?
There's a near infinite number of possible Locales, so enumerating them is
next to impossible. We decided against even giving names to the most common
ones, as that would have led to endless debates about which ones are the
most important. The strings come from a freely available ISO standard, so
they will never change and are easy to find out and are maintained by
someone other than us Ada people (so no need for debates on our end on
topics outside of our expertise). This is the same reason that we depend on
character set standards rather than rolling our own character set rules
(even though the latter would be easier to maintain, we wouldn't really know
what we were doing).
Randy.
^ permalink raw reply [relevance 0%]
* Re: gettext for Ada
2017-11-21 8:29 0% ` G. B.
@ 2017-11-21 13:48 0% ` J-P. Rosen
0 siblings, 0 replies; 84+ results
From: J-P. Rosen @ 2017-11-21 13:48 UTC (permalink / raw)
Le 21/11/2017 à 09:29, G. B. a écrit :
> Shark8 <onewingedshark@gmail.com> wrote:
>>
>>
>> Also, shouldn't the stuff in Ada.Locales actually be proper enumerations
>> rather than strings?
>
>
> Given the volatility in the political world,
> Ada enumerating locales will be an extraordinary
> achievement.
>
Moreover, there is an ISO standard for country and language strings; Ada
just refers to it.
--
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 [relevance 0%]
* Re: gettext for Ada
2017-11-21 0:28 8% ` Shark8
@ 2017-11-21 8:29 0% ` G. B.
2017-11-21 13:48 0% ` J-P. Rosen
2017-11-22 1:10 0% ` Randy Brukardt
1 sibling, 1 reply; 84+ results
From: G. B. @ 2017-11-21 8:29 UTC (permalink / raw)
Shark8 <onewingedshark@gmail.com> wrote:
>
>
> Also, shouldn't the stuff in Ada.Locales actually be proper enumerations
> rather than strings?
Given the volatility in the political world,
Ada enumerating locales will be an extraordinary
achievement.
^ permalink raw reply [relevance 0%]
* Re: gettext for Ada
2017-11-20 22:43 10% ` Randy Brukardt
@ 2017-11-21 0:28 8% ` Shark8
2017-11-21 8:29 0% ` G. B.
2017-11-22 1:10 0% ` Randy Brukardt
0 siblings, 2 replies; 84+ results
From: Shark8 @ 2017-11-21 0:28 UTC (permalink / raw)
On Monday, November 20, 2017 at 3:43:21 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message
> news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f...
> On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
> > Where can I get a gettext bindings for Ada?
>
> ...
> >And then at compile-time select the proper language to build the
> >application via
> >GPR-projects, makefiles, or whatever paramaterizable build-system you wish
> >to use.
>
> Or, use parallel packages and select the correct one to use at runtime based
> on Ada.Locales (A.19). That's the primary purpose of the Locales package,
> after all.
Parallel packages? I've not heard the term before, how are they used & selected at runtime? Also, shouldn't the stuff in Ada.Locales actually be proper enumerations rather than strings?
^ permalink raw reply [relevance 8%]
* Re: gettext for Ada
@ 2017-11-20 22:43 10% ` Randy Brukardt
2017-11-21 0:28 8% ` Shark8
0 siblings, 1 reply; 84+ results
From: Randy Brukardt @ 2017-11-20 22:43 UTC (permalink / raw)
"Shark8" <onewingedshark@gmail.com> wrote in message
news:2c5d0dff-bc12-4b37-b8e1-ac176c3e675f@googlegroups.com...
On Sunday, November 19, 2017 at 1:40:55 PM UTC-7, Victor Porton wrote:
> Where can I get a gettext bindings for Ada?
...
>And then at compile-time select the proper language to build the
>application via
>GPR-projects, makefiles, or whatever paramaterizable build-system you wish
>to use.
Or, use parallel packages and select the correct one to use at runtime based
on Ada.Locales (A.19). That's the primary purpose of the Locales package,
after all.
Randy.
^ permalink raw reply [relevance 10%]
* Re: Q: Regional settings snippet (Windows) ?
@ 2014-01-25 1:51 8% ` exitcode0
0 siblings, 0 replies; 84+ results
From: exitcode0 @ 2014-01-25 1:51 UTC (permalink / raw)
I don't know if this solves your particular problem, but you can get the country and language with the Ada.Locales package
http://webcache.googleusercontent.com/search?q=cache:-rAibkOPx3QJ:www.ada-auth.org/standards/12aarm/html/AA-A-19.html+&cd=1&hl=en&ct=clnk&gl=us
^ permalink raw reply [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 7:43 8% ` Jacob Sparre Andersen
@ 2012-08-09 20:47 8% ` Randy Brukardt
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 17:51 8% ` Jeffrey R. Carter
@ 2012-08-09 21:17 8% ` Randy Brukardt
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:33 8% ` J-P. Rosen
2012-08-08 11:44 7% ` Niklas Holsti
@ 2012-08-09 21:00 7% ` Randy Brukardt
1 sibling, 0 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 17:37 6% ` Michael Rohan
2012-08-06 18:23 8% ` Marius Amado-Alves
@ 2012-08-09 21:15 6% ` Randy Brukardt
1 sibling, 0 replies; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-09 8:31 5% ` Niklas Holsti
@ 2012-08-09 12:17 6% ` Dmitry A. Kazakov
2012-08-09 15:25 6% ` Niklas Holsti
0 siblings, 1 reply; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-09 12:17 6% ` Dmitry A. Kazakov
@ 2012-08-09 15:25 6% ` Niklas Holsti
2012-08-09 16:43 5% ` Dmitry A. Kazakov
0 siblings, 1 reply; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-09 15:25 6% ` Niklas Holsti
@ 2012-08-09 16:43 5% ` Dmitry A. Kazakov
0 siblings, 0 replies; 84+ results
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 [relevance 5%]
* Re: Ada.Locales pseudo-string types
2012-08-08 14:01 7% ` Niklas Holsti
@ 2012-08-09 7:48 7% ` Dmitry A. Kazakov
2012-08-09 8:31 5% ` Niklas Holsti
0 siblings, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-07 22:19 8% ` Adam Beneschan
@ 2012-08-08 0:37 8% ` Robert A Duff
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 13:14 7% ` Marius Amado-Alves
2012-08-07 15:42 7% ` Adam Beneschan
@ 2012-08-07 21:59 7% ` Robert A Duff
2012-08-07 22:19 8% ` Adam Beneschan
1 sibling, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:14 7% ` Niklas Holsti
@ 2012-08-08 11:59 8% ` Dmitry A. Kazakov
2012-08-08 14:01 7% ` Niklas Holsti
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:35 8% ` Marius Amado-Alves
@ 2012-08-08 12:24 8% ` Dmitry A. Kazakov
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 9:32 7% ` Marius Amado-Alves
@ 2012-08-08 10:11 6% ` Dmitry A. Kazakov
2012-08-08 11:28 8% ` Marius Amado-Alves
2012-08-08 11:35 8% ` Marius Amado-Alves
0 siblings, 2 replies; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-06 19:34 21% ` Simon Wright
2012-08-06 20:07 8% ` Marius Amado-Alves
@ 2012-08-07 17:51 16% ` Simon Wright
1 sibling, 0 replies; 84+ results
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 [relevance 16%]
* Re: Ada.Locales pseudo-string types
2012-08-08 10:11 6% ` Dmitry A. Kazakov
2012-08-08 11:28 8% ` Marius Amado-Alves
@ 2012-08-08 11:35 8% ` Marius Amado-Alves
2012-08-08 12:24 8% ` Dmitry A. Kazakov
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:28 8% ` Marius Amado-Alves
@ 2012-08-08 11:30 8% ` Marius Amado-Alves
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 10:11 6% ` Dmitry A. Kazakov
@ 2012-08-08 11:28 8% ` Marius Amado-Alves
2012-08-08 11:30 8% ` Marius Amado-Alves
2012-08-08 11:35 8% ` Marius Amado-Alves
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:07 16% ` Adam Beneschan
@ 2012-08-06 23:23 8% ` Vasiliy Molostov
2012-08-06 23:46 8% ` Adam Beneschan
2012-08-07 7:20 7% ` Dmitry A. Kazakov
` (2 subsequent siblings)
3 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:35 7% ` Dmitry A. Kazakov
@ 2012-08-08 9:32 7% ` Marius Amado-Alves
2012-08-08 10:11 6% ` Dmitry A. Kazakov
2012-08-08 11:52 8% ` Niklas Holsti
1 sibling, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 16:45 16% Ada.Locales pseudo-string types Marius Amado-Alves
2012-08-06 17:10 16% ` Marius Amado-Alves
2012-08-06 17:37 6% ` Michael Rohan
@ 2012-08-07 5:57 8% ` Jeffrey R. Carter
2012-08-07 15:46 16% ` Adam Beneschan
2 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 15:42 7% ` Adam Beneschan
@ 2012-08-07 18:22 8% ` Marius Amado-Alves
2012-08-07 20:10 7% ` Adam Beneschan
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 15:26 13% ` Adam Beneschan
@ 2012-08-07 18:07 8% ` Marius Amado-Alves
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 21:59 7% ` Robert A Duff
@ 2012-08-07 22:19 8% ` Adam Beneschan
2012-08-08 0:37 8% ` Robert A Duff
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 20:10 7% ` Adam Beneschan
@ 2012-08-07 20:42 8% ` Marius Amado-Alves
2012-08-07 21:38 8% ` Adam Beneschan
2012-08-08 7:04 7% ` Niklas Holsti
2012-08-07 20:43 8% ` Marius Amado-Alves
1 sibling, 2 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 18:22 8% ` Marius Amado-Alves
@ 2012-08-07 20:10 7% ` Adam Beneschan
2012-08-07 20:42 8% ` Marius Amado-Alves
2012-08-07 20:43 8% ` Marius Amado-Alves
0 siblings, 2 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 20:57 8% ` Simon Wright
@ 2012-08-06 21:09 8% ` Vasiliy Molostov
2012-08-06 23:07 16% ` Adam Beneschan
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 13:14 7% ` Marius Amado-Alves
@ 2012-08-07 15:42 7% ` Adam Beneschan
2012-08-07 18:22 8% ` Marius Amado-Alves
2012-08-07 21:59 7% ` Robert A Duff
1 sibling, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-07 15:46 16% ` Adam Beneschan
@ 2012-08-07 17:51 8% ` Jeffrey R. Carter
2012-08-09 21:17 8% ` Randy Brukardt
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 8:44 7% ` Marius Amado-Alves
2012-08-07 13:14 7% ` Marius Amado-Alves
@ 2012-08-07 15:26 13% ` Adam Beneschan
2012-08-07 18:07 8% ` Marius Amado-Alves
1 sibling, 1 reply; 84+ results
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 [relevance 13%]
* Re: Ada.Locales pseudo-string types
2012-08-06 20:07 8% ` Marius Amado-Alves
@ 2012-08-06 20:57 8% ` Simon Wright
2012-08-06 21:09 8% ` Vasiliy Molostov
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 17:37 6% ` Michael Rohan
@ 2012-08-06 18:23 8% ` Marius Amado-Alves
2012-08-06 19:36 8% ` Michael Rohan
2012-08-09 21:15 6% ` Randy Brukardt
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 17:10 16% ` Marius Amado-Alves
@ 2012-08-06 19:15 8% ` J-P. Rosen
2012-08-06 19:34 21% ` Simon Wright
2012-08-06 20:00 8% ` Marius Amado-Alves
2012-08-06 19:49 8% ` Jacob Sparre Andersen
1 sibling, 2 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 16:45 16% Ada.Locales pseudo-string types Marius Amado-Alves
@ 2012-08-06 17:10 16% ` Marius Amado-Alves
2012-08-06 19:15 8% ` J-P. Rosen
2012-08-06 19:49 8% ` Jacob Sparre Andersen
2012-08-06 17:37 6% ` Michael Rohan
2012-08-07 5:57 8% ` Jeffrey R. Carter
2 siblings, 2 replies; 84+ results
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 [relevance 16%]
* Re: Ada.Locales pseudo-string types
2012-08-07 8:44 7% ` Marius Amado-Alves
@ 2012-08-07 13:14 7% ` Marius Amado-Alves
2012-08-07 15:42 7% ` Adam Beneschan
2012-08-07 21:59 7% ` Robert A Duff
2012-08-07 15:26 13% ` Adam Beneschan
1 sibling, 2 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 17:10 16% ` Marius Amado-Alves
2012-08-06 19:15 8% ` J-P. Rosen
@ 2012-08-06 19:49 8% ` Jacob Sparre Andersen
2012-08-06 20:11 8% ` Marius Amado-Alves
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:46 8% ` Adam Beneschan
@ 2012-08-07 1:17 8% ` Vasiliy Molostov
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 16:45 16% Ada.Locales pseudo-string types Marius Amado-Alves
2012-08-06 17:10 16% ` Marius Amado-Alves
@ 2012-08-06 17:37 6% ` Michael Rohan
2012-08-06 18:23 8% ` Marius Amado-Alves
2012-08-09 21:15 6% ` Randy Brukardt
2012-08-07 5:57 8% ` Jeffrey R. Carter
2 siblings, 2 replies; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:09 7% ` Dmitry A. Kazakov
@ 2012-08-08 11:14 7% ` Niklas Holsti
2012-08-08 11:59 8% ` Dmitry A. Kazakov
0 siblings, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:28 7% ` J-P. Rosen
@ 2012-08-08 11:35 7% ` Niklas Holsti
2012-08-08 14:05 6% ` Georg Bauhaus
0 siblings, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:18 8% ` Dmitry A. Kazakov
@ 2012-08-08 7:37 7% ` Niklas Holsti
2012-08-08 8:09 7% ` Dmitry A. Kazakov
2012-08-08 8:28 7% ` J-P. Rosen
0 siblings, 2 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-07 20:42 8% ` Marius Amado-Alves
2012-08-07 21:38 8% ` Adam Beneschan
@ 2012-08-08 7:04 7% ` Niklas Holsti
2012-08-08 7:18 8% ` Dmitry A. Kazakov
` (2 more replies)
1 sibling, 3 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:32 7% ` J-P. Rosen
@ 2012-08-08 8:17 11% ` Niklas Holsti
2012-08-08 8:33 8% ` J-P. Rosen
2012-08-08 8:35 7% ` Dmitry A. Kazakov
0 siblings, 2 replies; 84+ results
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 [relevance 11%]
* Re: Ada.Locales pseudo-string types
2012-08-09 7:48 7% ` Dmitry A. Kazakov
@ 2012-08-09 8:31 5% ` Niklas Holsti
2012-08-09 12:17 6% ` Dmitry A. Kazakov
0 siblings, 1 reply; 84+ results
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 [relevance 5%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:59 8% ` Dmitry A. Kazakov
@ 2012-08-08 14:01 7% ` Niklas Holsti
2012-08-09 7:48 7% ` Dmitry A. Kazakov
0 siblings, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:35 7% ` Dmitry A. Kazakov
2012-08-08 9:32 7% ` Marius Amado-Alves
@ 2012-08-08 11:52 8% ` Niklas Holsti
2012-08-08 13:21 8% ` Dmitry A. Kazakov
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:33 8% ` J-P. Rosen
@ 2012-08-08 11:44 7% ` Niklas Holsti
2012-08-09 21:00 7% ` Randy Brukardt
1 sibling, 0 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 19:15 8% ` J-P. Rosen
@ 2012-08-06 19:34 21% ` Simon Wright
2012-08-06 20:07 8% ` Marius Amado-Alves
2012-08-07 17:51 16% ` Simon Wright
2012-08-06 20:00 8% ` Marius Amado-Alves
1 sibling, 2 replies; 84+ results
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 [relevance 21%]
* Re: Ada.Locales pseudo-string types
2012-08-06 18:23 8% ` Marius Amado-Alves
@ 2012-08-06 19:36 8% ` Michael Rohan
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:07 16% ` Adam Beneschan
2012-08-06 23:23 8% ` Vasiliy Molostov
2012-08-07 7:20 7% ` Dmitry A. Kazakov
@ 2012-08-07 7:43 8% ` Jacob Sparre Andersen
2012-08-09 20:47 8% ` Randy Brukardt
2012-08-07 8:44 7% ` Marius Amado-Alves
3 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:07 16% ` Adam Beneschan
2012-08-06 23:23 8% ` Vasiliy Molostov
@ 2012-08-07 7:20 7% ` Dmitry A. Kazakov
2012-08-07 7:43 8% ` Jacob Sparre Andersen
2012-08-07 8:44 7% ` Marius Amado-Alves
3 siblings, 0 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:35 7% ` Niklas Holsti
@ 2012-08-08 14:05 6% ` Georg Bauhaus
0 siblings, 0 replies; 84+ results
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 [relevance 6%]
* Re: Ada.Locales pseudo-string types
2012-08-08 11:52 8% ` Niklas Holsti
@ 2012-08-08 13:21 8% ` Dmitry A. Kazakov
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:04 7% ` Niklas Holsti
2012-08-08 7:18 8% ` Dmitry A. Kazakov
2012-08-08 7:32 7% ` J-P. Rosen
@ 2012-08-08 9:07 8% ` Marius Amado-Alves
2 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:17 11% ` Niklas Holsti
2012-08-08 8:33 8% ` J-P. Rosen
@ 2012-08-08 8:35 7% ` Dmitry A. Kazakov
2012-08-08 9:32 7% ` Marius Amado-Alves
2012-08-08 11:52 8% ` Niklas Holsti
1 sibling, 2 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 8:17 11% ` Niklas Holsti
@ 2012-08-08 8:33 8% ` J-P. Rosen
2012-08-08 11:44 7% ` Niklas Holsti
2012-08-09 21:00 7% ` Randy Brukardt
2012-08-08 8:35 7% ` Dmitry A. Kazakov
1 sibling, 2 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:37 7% ` Niklas Holsti
2012-08-08 8:09 7% ` Dmitry A. Kazakov
@ 2012-08-08 8:28 7% ` J-P. Rosen
2012-08-08 11:35 7% ` Niklas Holsti
1 sibling, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:37 7% ` Niklas Holsti
@ 2012-08-08 8:09 7% ` Dmitry A. Kazakov
2012-08-08 11:14 7% ` Niklas Holsti
2012-08-08 8:28 7% ` J-P. Rosen
1 sibling, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:04 7% ` Niklas Holsti
2012-08-08 7:18 8% ` Dmitry A. Kazakov
@ 2012-08-08 7:32 7% ` J-P. Rosen
2012-08-08 8:17 11% ` Niklas Holsti
2012-08-08 9:07 8% ` Marius Amado-Alves
2 siblings, 1 reply; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-08 7:04 7% ` Niklas Holsti
@ 2012-08-08 7:18 8% ` Dmitry A. Kazakov
2012-08-08 7:37 7% ` Niklas Holsti
2012-08-08 7:32 7% ` J-P. Rosen
2012-08-08 9:07 8% ` Marius Amado-Alves
2 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 20:42 8% ` Marius Amado-Alves
@ 2012-08-07 21:38 8% ` Adam Beneschan
2012-08-08 7:04 7% ` Niklas Holsti
1 sibling, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 20:10 7% ` Adam Beneschan
2012-08-07 20:42 8% ` Marius Amado-Alves
@ 2012-08-07 20:43 8% ` Marius Amado-Alves
1 sibling, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-07 5:57 8% ` Jeffrey R. Carter
@ 2012-08-07 15:46 16% ` Adam Beneschan
2012-08-07 17:51 8% ` Jeffrey R. Carter
0 siblings, 1 reply; 84+ results
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 [relevance 16%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:07 16% ` Adam Beneschan
` (2 preceding siblings ...)
2012-08-07 7:43 8% ` Jacob Sparre Andersen
@ 2012-08-07 8:44 7% ` Marius Amado-Alves
2012-08-07 13:14 7% ` Marius Amado-Alves
2012-08-07 15:26 13% ` Adam Beneschan
3 siblings, 2 replies; 84+ results
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 [relevance 7%]
* Re: Ada.Locales pseudo-string types
2012-08-06 23:23 8% ` Vasiliy Molostov
@ 2012-08-06 23:46 8% ` Adam Beneschan
2012-08-07 1:17 8% ` Vasiliy Molostov
0 siblings, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 21:09 8% ` Vasiliy Molostov
@ 2012-08-06 23:07 16% ` Adam Beneschan
2012-08-06 23:23 8% ` Vasiliy Molostov
` (3 more replies)
0 siblings, 4 replies; 84+ results
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 [relevance 16%]
* Re: Ada.Locales pseudo-string types
2012-08-06 19:34 21% ` Simon Wright
@ 2012-08-06 20:07 8% ` Marius Amado-Alves
2012-08-06 20:57 8% ` Simon Wright
2012-08-07 17:51 16% ` Simon Wright
1 sibling, 1 reply; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 19:49 8% ` Jacob Sparre Andersen
@ 2012-08-06 20:11 8% ` Marius Amado-Alves
0 siblings, 0 replies; 84+ results
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 [relevance 8%]
* Re: Ada.Locales pseudo-string types
2012-08-06 19:15 8% ` J-P. Rosen
2012-08-06 19:34 21% ` Simon Wright
@ 2012-08-06 20:00 8% ` Marius Amado-Alves
1 sibling, 0 replies; 84+ results
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 [relevance 8%]
* Ada.Locales pseudo-string types
@ 2012-08-06 16:45 16% Marius Amado-Alves
2012-08-06 17:10 16% ` Marius Amado-Alves
` (2 more replies)
0 siblings, 3 replies; 84+ results
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 [relevance 16%]
Results 1-84 of 84 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2012-08-06 16:45 16% Ada.Locales pseudo-string types Marius Amado-Alves
2012-08-06 17:10 16% ` Marius Amado-Alves
2012-08-06 19:15 8% ` J-P. Rosen
2012-08-06 19:34 21% ` Simon Wright
2012-08-06 20:07 8% ` Marius Amado-Alves
2012-08-06 20:57 8% ` Simon Wright
2012-08-06 21:09 8% ` Vasiliy Molostov
2012-08-06 23:07 16% ` Adam Beneschan
2012-08-06 23:23 8% ` Vasiliy Molostov
2012-08-06 23:46 8% ` Adam Beneschan
2012-08-07 1:17 8% ` Vasiliy Molostov
2012-08-07 7:20 7% ` Dmitry A. Kazakov
2012-08-07 7:43 8% ` Jacob Sparre Andersen
2012-08-09 20:47 8% ` Randy Brukardt
2012-08-07 8:44 7% ` Marius Amado-Alves
2012-08-07 13:14 7% ` Marius Amado-Alves
2012-08-07 15:42 7% ` Adam Beneschan
2012-08-07 18:22 8% ` Marius Amado-Alves
2012-08-07 20:10 7% ` Adam Beneschan
2012-08-07 20:42 8% ` Marius Amado-Alves
2012-08-07 21:38 8% ` Adam Beneschan
2012-08-08 7:04 7% ` Niklas Holsti
2012-08-08 7:18 8% ` Dmitry A. Kazakov
2012-08-08 7:37 7% ` Niklas Holsti
2012-08-08 8:09 7% ` Dmitry A. Kazakov
2012-08-08 11:14 7% ` Niklas Holsti
2012-08-08 11:59 8% ` Dmitry A. Kazakov
2012-08-08 14:01 7% ` Niklas Holsti
2012-08-09 7:48 7% ` Dmitry A. Kazakov
2012-08-09 8:31 5% ` Niklas Holsti
2012-08-09 12:17 6% ` Dmitry A. Kazakov
2012-08-09 15:25 6% ` Niklas Holsti
2012-08-09 16:43 5% ` Dmitry A. Kazakov
2012-08-08 8:28 7% ` J-P. Rosen
2012-08-08 11:35 7% ` Niklas Holsti
2012-08-08 14:05 6% ` Georg Bauhaus
2012-08-08 7:32 7% ` J-P. Rosen
2012-08-08 8:17 11% ` Niklas Holsti
2012-08-08 8:33 8% ` J-P. Rosen
2012-08-08 11:44 7% ` Niklas Holsti
2012-08-09 21:00 7% ` Randy Brukardt
2012-08-08 8:35 7% ` Dmitry A. Kazakov
2012-08-08 9:32 7% ` Marius Amado-Alves
2012-08-08 10:11 6% ` Dmitry A. Kazakov
2012-08-08 11:28 8% ` Marius Amado-Alves
2012-08-08 11:30 8% ` Marius Amado-Alves
2012-08-08 11:35 8% ` Marius Amado-Alves
2012-08-08 12:24 8% ` Dmitry A. Kazakov
2012-08-08 11:52 8% ` Niklas Holsti
2012-08-08 13:21 8% ` Dmitry A. Kazakov
2012-08-08 9:07 8% ` Marius Amado-Alves
2012-08-07 20:43 8% ` Marius Amado-Alves
2012-08-07 21:59 7% ` Robert A Duff
2012-08-07 22:19 8% ` Adam Beneschan
2012-08-08 0:37 8% ` Robert A Duff
2012-08-07 15:26 13% ` Adam Beneschan
2012-08-07 18:07 8% ` Marius Amado-Alves
2012-08-07 17:51 16% ` Simon Wright
2012-08-06 20:00 8% ` Marius Amado-Alves
2012-08-06 19:49 8% ` Jacob Sparre Andersen
2012-08-06 20:11 8% ` Marius Amado-Alves
2012-08-06 17:37 6% ` Michael Rohan
2012-08-06 18:23 8% ` Marius Amado-Alves
2012-08-06 19:36 8% ` Michael Rohan
2012-08-09 21:15 6% ` Randy Brukardt
2012-08-07 5:57 8% ` Jeffrey R. Carter
2012-08-07 15:46 16% ` Adam Beneschan
2012-08-07 17:51 8% ` Jeffrey R. Carter
2012-08-09 21:17 8% ` Randy Brukardt
2014-01-24 22:07 Q: Regional settings snippet (Windows) ? gautier_niouzes
2014-01-25 1:51 8% ` exitcode0
2017-11-19 20:40 gettext for Ada Victor Porton
2017-11-20 15:40 ` Shark8
2017-11-20 22:43 10% ` Randy Brukardt
2017-11-21 0:28 8% ` Shark8
2017-11-21 8:29 0% ` G. B.
2017-11-21 13:48 0% ` J-P. Rosen
2017-11-22 1:10 0% ` Randy Brukardt
2017-11-22 15:38 0% ` Shark8
2017-11-23 0:30 0% ` Randy Brukardt
2017-11-23 3:08 0% ` Shark8
2017-11-23 8:25 ` G. B.
2017-11-23 16:02 ` Shark8
2017-11-23 18:55 ` G. B.
2017-11-23 20:24 7% ` Shark8
2018-10-15 0:42 Is the Documentation In a spec File Usually Enough For You ? patrick
2018-10-15 16:50 ` Jeffrey R. Carter
2018-10-16 9:57 ` AdaMagica
2018-10-16 16:57 ` Jeffrey R. Carter
2018-10-18 9:06 ` AdaMagica
2018-10-18 15:24 6% ` Brad Moore
2023-04-13 14:17 Currency Library for Ada? A.J.
2023-04-13 17:37 8% ` J-P. Rosen
2023-04-13 18:12 0% ` A.J.
2023-04-15 18:52 8% Looking for feedback: ISO 3166-1 country Country Code Reference in Ada A.J.
2023-04-17 9:36 0% ` Jeffrey R.Carter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox