Issue 2095: Suggestion on mapping the OMG IDL language to Ada (ada-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This is a suggestion for consideration by the Ada Revision Task Force. Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Resolution: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef’s of each other were assumed to be the same type or at least freely convertible in common IDL usage), but the desire to not “lose” the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the adopted mapping. However, it has been suggested that the mapping choice, subtype or derived type, could be effectively controlled by a pragma, an element that annotates but is not part of the IDL syntax proper. The CORBA specification does require the handling of pragmas: “Conforming IDL compilers may support additional non-standard pragmas, but must not refuse to compile IDL source containing non-standard pragmas that are not understood by the compiler.” This provision allows the introduction of Ada-specific pragmas without breaking interoperability. The revised text below introduces a pragma that overrides the default choice of mapping of typedefs. It has also been suggested that the Ada-specific specification of range constraints be introduced in the same way. Thus, the following IDL: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; maps to: subtype MyLong is CORBA.Long range 0 .. 100; Of course, these pragmas could be separately applied to produce a subtype without range constraint or range constrained derived type. Revised Text: Change the last sentence of the first paragraph under section 3.13 to read: “An IDL typedef maps to an Ada derived type by default, or to an Ada subtype (see section 3.13.1).” Insert a new sub-section 3.13.1 after the first paragraph of the current section 3.13: 3.13.1 Controlling pragmas The default choice of mapping of a typedef may be overridden or reinforced by a pragma that appears before the typedef clause in the IDL in the same scope. The syntax of the pragmas are: #pragma subtype <name> #pragma derived <name> where <name> is a simple identifier presumed to be type name that will be typedef’d in the same scope. It is an error to specify multiple subtype pragmas, multiple derived pragmas, or both subtype and derived pragmas for the same type. It is an error to specify a subtype pragma or a derived pragma after the corresponding type has been defined in IDL. It is an error to specify a subtype or a derived pragma for a type named in an array declarator. A range constraint may be introduced to the result of the mapping of a typedef’d IDL type through a range pragma. The BNF syntax of the pragma is: <range_pragma> ::= #pragma range <scoped_name> <range_constraint> <range_constraint> ::= [<const_exp>] [.. <const_exp>] | <string_literal> where <scoped_name> is an type name that will be typedef’d in the same scope (for a const_type), and <range_constraint> specifies the range. If the range_constraint is a string_literal ,i.e., enclosed by quotations, the literal express is assumed to be valid in the target language and will be mapped lexically. Otherwise, each const_exp will be interpreted as if it were an IDL constant expression. The first const_exp, if any, specifies the minimum of the range for the subtype. If missing, the minimum of the range shall be the minimum of the unconstrained type. The second const_exp (i.e., the one after the “..”) specifies the maximum of the range of the subtype. If missing, the maximum of the range shall be the maximum of the unconstrained type. It is an error to specify mulitple range pragmas for the same type. It is an error to specify a range pragma for a type named in an array declarator. It is an error to specify a range for a type that is not a <const_type>. It is an error to specify a range that is greater than the range of the parent type. Insert a new sub-section header after the inserted text above: 3.13.2 Mapping Substitute the following two paragraphs for the third (3rd) paragraph of the current section 3.13: Each simple declarator for a reference type, that is, a type in CORBA.Object.Ref'CLASS, shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is cited in a subtype pragma shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is not cited in a subtype pragma shall be mapped to a derived type declaration. The type or subtype name shall be the identifier provided in the simple declarator. The type definition shall be the mapping of the typespec, as specified elsewhere in this section. If the type or subtype name is cited in a range pragma the mapped typespec shall include an Ada range constraint clause. If the IDL range_constraint is a string literal, the range constraint shall be ěrange <string_literal>î. Otherwise, the minimum for the range specification shall be mapped from the IDL minimum const_exp, if any, or the 'first of the mapped type, if no minimum was defined. The maximum for the range specification shall be mapped from the IDL maximum const_exp, if any, or the 'last of the mapped type, if no maximum was defined. Add the following to the example IDL typedef’s: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; #pragma range NewLong “MyLong’range” typedef long NewLong; const long MinNatural = 0; #pragma range Natural MinNatural typedef long Natural; Add the following to the example mappings: subtype MyLong is CORBA.Long range 0 .. 100; type NewLong is new CORBA.Long range MyLong’range; MinNatural : constant CORBA.Long = 0; type Natural is new CORBA.Long range MinNatural .. CORBA.Long’last; Disposition: Resolved Actions taken: October 19, 1998: received issue January 12, 2010: closed issue Discussion: End of Annotations:===== MG Meeting Washington, DC December 4-8, 2006 Return-Path: X-Sender: e982450@popcorn.llnl.gov Date: Fri, 16 Oct 1998 15:16:26 -0800 To: ada-rtf@omg.org, vtg@ois.com From: "John P. Woodruff" Subject: Suggestion on mapping the OMG IDL language to Ada Suggestion on mapping the OMG IDL language to Ada Proposed by John Woodruff, woodruff1@llnl.gov Lawrence Livermore National Lab 925.422.4661 This is a suggestion for consideration by the Ada Revision Task Force. Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. By way of example, consider the following IDL type definitions: module try_subtypes { typedef string as_generated_1 ; typedef string <60> as_generated_2 ; typedef short as_generated_3 ; const as_generated_3 min_as_generated_3 = 7 ; const as_generated_3 max_as_generated_3 = 42 ; }; This module specification is mapped to an Ada package specification as follows: with Corba; pragma Elaborate_All (Corba); with Corba.Bounded_String_60; -- a generated package package Try_Subtypes is type As_Generated_1 is new Corba.String; type As_Generated_2 is new Corba.Bounded_String_60.Bounded_String; type As_Generated_3 is new Corba.Short range Corba.Short (7) .. Corba.Short (42); Min_As_Generated_3 : constant As_Generated_3 := As_Generated_3 (7); Max_As_Generated_3 : constant As_Generated_3 := As_Generated_3 (42); end Try_Subtypes; I suggest that a set of subtypes such as the following are a more useful translation for the IDL module: package Try_Subtypes.Better is subtype Better_1 is String; subtype Better_2 is Corba.Bounded_String_60.Bounded_String; Better_Min : constant Corba.Short := Corba.Short (7); Better_Max : constant Corba.Short := Corba.Short (42); subtype Better_3 is Corba.Short range Better_Min .. Better_Max; end Try_Subtypes.Better; Motivation for suggesting this revision is pragmatic: when a group of engineers collaborates on a product that has numerous IDL interfaces, different workers commonly define the same type for data being transmitted between components. Under the present IDL to Ada mapping, each of these interfaces generates a distinct type, and workers choose to make type conversions among the types. A more attractive result would be to let workers share a common set of base types and let different interfaces be specified by the constraints imposed by subtype definitions. -- John Woodruff N I F \ ^ / Lawrence Livermore National Lab =====---- < o > 925 422 4661 / v \ Reply-To: From: "Victor Giddings" To: Cc: "'Nick Roberts'" Subject: Proposed Resolution for 2095 - for Comment Date: Wed, 17 Aug 2005 17:03:45 -0400 Organization: Objective Interface System X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWjbydZhEz4QrKfRtCiasd+SivvxQ== OMG Issue No: 2095 Title: Suggestion on mapping the OMG IDL language to Ada Source: Lawrence Livermore National Laboratory ­ John Woodruff: woodruff1@llnl.gov Summary: Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Discussion: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef.s of each other were assumed to be the same type in common IDL usage), but the desire to not .lose. the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the mapping adopted. To changed basic decision at this point might cause a major reverse compatibility problem. However, this issue is left .deferred. in anticipation of an RFP to revise the Ada mapping to accommodate the new language version due next year. Disposition: Deferred Victor Giddings mailto:victor.giddings@mail.ois.com Senior Scientist +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 To: ada-rtf@omg.org Cc: Nick Roberts Subject: Proposed Revised Resolution for Issue 2095 From: Victor Giddings Date: Wed, 30 Apr 2008 11:12:04 -0400 X-Mailer: Apple Mail (2.753) Note that we voted on 2095 in Vote #1 with a Deferred disposition. This was done to allow it to be addressed in an Ada 2005 revision of the mapping. Since this doesn't seem to be happening for some time, I think we should close it out instead. OMG Issue No: 2095 Title: Suggestion on mapping the OMG IDL language to Ada Source: Lawrence Livermore National Laboratory . John Woodruff: woodruff1@llnl.gov Summary: Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Discussion: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef.s of each other were assumed to be the same type in common IDL usage), but the desire to not .lose. the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the adopted mapping. To changed basic decision at this point might cause a major reverse compatibility problem. This issues is closed with no change. Disposition: Closed, no change Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com Cc: ada-rtf@omg.org From: Victor Giddings Subject: Re: Proposed Revised Resolution for Issue 2095 Date: Wed, 30 Apr 2008 13:01:37 -0400 To: Char Wales X-Mailer: Apple Mail (2.753) Char, The IDL typedef statement creates a new name for a type: typedef long MyLong; typedef long YourLong; The intended semantics are limited to the following statement in the CORBA specification: "OMG IDL uses the typedef keyword to associate a name with a data type." This is all that a typedef implies in IDL, in C, and in C++. The IDL to C mapping and IDL to C++ mapping both map IDL typedef to native language typedef, and that is the end of it. Java doesn't support typedef, so in the IDL to Java mapping, typedef names disappear and are replaced by the type that they typedef. In Ada there are two possible mappings: - derived type: An Ada derived type defines a new type that inherits all of the "primitive operations" of the type derived from. Since it is a new type, instances of the parent type cannot be directly assigned to instances of derived type. They are not "type compatible": one : MyLong := 1; two : YourLong := one; -- illegal (won't compile) two : YourLong := YourLong(one); -- legal - subtype: An Ada subtype introduces a new name for a type (and may constrain the range of legal values of a type. This is not relevant to the IDL mapping discussion.) Instances of the subtypes can be directly assigned from one to another. one : MyLong := 1; two : YourLong := one; -- legal "Type compatibility" is more than an issue of coding a simple conversion. For example, if you define a sequence of parent type and a separate sequence of the derived type, you cannot assign one sequence to another except through: - assigning each element (with type conversion) from one to the other - using Unchecked_Conversion, a big enough "hole" in the type system that most DoD programs require a waiver to use it (although the same is done in C++ very easily and without checking.) (Same applies to arrays, etc.) The discussions that lead to the initial mapping of IDL typedef were along the lines of: - subtyping is closer to the intended (or at least de jure) semantics of IDL - derived typing, while it would cause additional code to be written to use many IDL specifications, would, at least in the context of an Ada-only CORBA application, allow CORBA Ada developers to enjoy the additional type safety that they enjoy when using "pure Ada" specifications. So the vote of those involved was to go with derived typing and that was put into the adopted specification. John Woodruff's (BTW John is long retired) experience (BTW John is long retired) lead him to question this decision and to favor subtyping. This is a position that I have some sympathy for, given not only use considerations, but also implementation considerations. However, I am taking the position that the "horse has left the barn" and we will have to live with our initial decision. Hope this helps, Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com On Apr 30, 2008, at 11:25 AM, Char Wales wrote: what exactly was this guy from LLL asking for? And what exactly does the existing spec call for now? Not sure I understand 'doesn't seem to be haping for some time' -- WHAT isn't happening for some time? No sure I undertand (or the ramifications of): generated as subtypes of a single (family of) types. What exactly would this look like? Right now -- it appears that each IDL TypeDef is mapped to an Ada type? Does he now want to increase the granularity of the mapping to include Ada subtypes as well? Is that it? But isn't that inherent in mapping a IDL TypeDef to an Ada Type? If I map an IDL TypeDef X to Ada Type X then I am also - by derivation -- mapping IDL TypeDef X to Ada Type X and all the subtypes of Ada Type X. Or am I completely ignorant of how Ada works? Char Victor Giddings wrote: Note that we voted on 2095 in Vote #1 with a Deferred disposition. This was done to allow it to be addressed in an Ada 2005 revision of the mapping. Since this doesn't seem to be happening for some time, I think we should close it out instead. OMG Issue No: 2095 Title: Suggestion on mapping the OMG IDL language to Ada Source: Lawrence Livermore National Laboratory . John Woodruff: woodruff1@llnl.gov Summary: Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Discussion: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef.s of each other were assumed to be the same type in common IDL usage), but the desire to not .lose. the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the adopted mapping. To changed basic decision at this point might cause a major reverse compatibility problem. This issues is closed with no change. Disposition: Closed, no change Victor Giddings Objective Interface Systems victor.giddings@mail.ois.com -- Charlotte W. Wales Lead Information Systems Engineer The MITRE Corporation/Army Enterprise Systems http://www.mitre.org Mailing Address: 7525 Colshire Drive, MS H120 McLean, VA 22102 Ph: 703-983-7024 || Fax: 703-983-6143 || Cell: 703-850-4955 Email: charwing@mitre.org | charlotte.wales1@us.army.mil X-Authentication-Warning: mailrelay1.vs.dasa.de: iscan owned process doing -bs From: Oliver Kellogg To: Victor Giddings Subject: Re: Proposed Revised Resolution for Issue 2095 Date: Tue, 13 May 2008 09:20:48 +0200 User-Agent: KMail/1.8 Cc: Char Wales , ada-rtf@omg.org X-SpamInfo: helo-dns, X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m4D7PJMo007447 FYI, we have solved this problem using pragmas, for example #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; leads to the following generated code: subtype MyLong is CORBA.Long range 0 .. 100; Regards, Oliver M. Kellogg -- Mission Systems & Solutions MSOP22 Defence and Communication Systems DCS Woerthstrasse 85 89077 Ulm Germany Phone: Â +49 (0) 731 392 7138 Fax: Â Â +49 (0) 731 392 7301 mailto: oliver.kellogg@eads.com EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB 107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (Chairman), Michael Hecht On Wednesday 30 April 2008 19:01, Victor Giddings wrote: > Char, > > The IDL typedef statement creates a new name for a type: > > typedef long MyLong; > typedef long YourLong; > > The intended semantics are limited to the following statement in the > CORBA specification: "OMG IDL uses the typedef keyword to associate a > name with a data type." > > This is all that a typedef implies in IDL, in C, and in C++. The IDL > to C mapping and IDL to C++ mapping both map IDL typedef to native > language typedef, and that is the end of it. Java doesn't support > typedef, so in the IDL to Java mapping, typedef names disappear and > are replaced by the type that they typedef. > > In Ada there are two possible mappings: > - derived type: An Ada derived type defines a new type that inherits > all of the "primitive operations" of the type derived from. Since it > is a new type, instances of the parent type cannot be directly > assigned to instances of derived type. They are not "type compatible": > one : MyLong := 1; > two : YourLong := one; -- illegal (won't compile) > two : YourLong := YourLong(one); -- legal > - subtype: An Ada subtype introduces a new name for a type (and may > constrain the range of legal values of a type. This is not relevant > to the IDL mapping discussion.) Instances of the subtypes can be > directly assigned from one to another. > one : MyLong := 1; > two : YourLong := one; -- legal > "Type compatibility" is more than an issue of coding a simple > conversion. For example, if you define a sequence of parent type and > a separate sequence of the derived type, you cannot assign one > sequence to another except through: > - assigning each element (with type conversion) from one to the other > - using Unchecked_Conversion, a big enough "hole" in the type system > that most DoD programs require a waiver to use it (although the same > is done in C++ very easily and without checking.) > (Same applies to arrays, etc.) > > The discussions that lead to the initial mapping of IDL typedef were > along the lines of: > - subtyping is closer to the intended (or at least de jure) semantics > of IDL > - derived typing, while it would cause additional code to be written > to use many IDL specifications, would, at least in the context of an > Ada-only CORBA application, allow CORBA Ada developers to enjoy the > additional type safety that they enjoy when using "pure Ada" > specifications. > > So the vote of those involved was to go with derived typing and that > was put into the adopted specification. > > John Woodruff's (BTW John is long retired) experience (BTW John is > long retired) lead him to question this decision and to favor > subtyping. This is a position that I have some sympathy for, given > not only use considerations, but also implementation considerations. > However, I am taking the position that the "horse has left the barn" > and we will have to live with our initial decision. > > Hope this helps, > > Victor Giddings Objective Interface Systems > victor.giddings@mail.ois.com > > > > > On Apr 30, 2008, at 11:25 AM, Char Wales wrote: > > > what exactly was this guy from LLL asking for? And what exactly > > does the existing spec call for now? Not sure I understand > > 'doesn't seem to be haping for some time' -- WHAT isn't happening > > for some time? > > > > No sure I undertand (or the ramifications of): generated as > > subtypes of a single (family of) types. > > What exactly would this look like? Right now -- it appears that > > each IDL TypeDef is mapped to an Ada type? Does he now want to > > increase the granularity of the mapping to include Ada subtypes as > > well? Is that it? But isn't that inherent in mapping a IDL > > TypeDef to an Ada Type? If I map an IDL TypeDef X to Ada Type X > > then I am also - by derivation -- mapping IDL TypeDef X to Ada Type > > X and all the subtypes of Ada Type X. Or am I completely ignorant > > of how Ada works? > > > > Char > > Victor Giddings wrote: > >> > >> Note that we voted on 2095 in Vote #1 with a Deferred disposition. > >> This was done to allow it to be addressed in an Ada 2005 revision > >> of the mapping. Since this doesn't seem to be happening for some > >> time, I think we should close it out instead. > >> > >> OMG Issue No: 2095 > >> Title: Suggestion on mapping the OMG IDL language to Ada > >> Source: > >> > >> Lawrence Livermore National Laboratory ­ John Woodruff: > >> woodruff1@llnl.gov > >> Summary: > >> > >> Experience with the IDL to Ada mapping (OMG Document 95-5-16) > >> convention for generating distinct types for each IDL typedef > >> leads me to suggest that generating a distinct Ada type for each > >> IDL typedef results in numerous types which might more clearly be > >> generated as subtypes of a single (family of) types. > >> Discussion: > >> > >> The mapping of an IDL typedef to either a new Ada derived type or > >> to an Ada subtype was discussed extensively during the initial > >> development of the Ada mapping in 1995. At that time, it was > >> recognized that the intended semantics of IDL fit Ada subtyping > >> better (for example, arrays and sequences of elements that were > >> typedefâ..s of each other were assumed to be the same type in common > >> IDL usage), but the desire to not â..loseâ.ť the stronger typing of > >> Ada lead most to opt for the stronger derived typing mapping. That > >> was the adopted mapping. > >> > >> To changed basic decision at this point might cause a major > >> reverse compatibility problem. This issues is closed with no change. > >> Disposition: Closed, no change > >> > >> > >> Victor Giddings Objective Interface Systems > >> victor.giddings@mail.ois.com > >> > >> > >> > >> > > > > -- > > Charlotte W. Wales > > Lead Information Systems Engineer > > The MITRE Corporation/Army Enterprise Systems > > http://www.mitre.org > > > > > > Mailing Address: > > 7525 Colshire Drive, MS H120 > > McLean, VA 22102 > > > > Ph: 703-983-7024 || Fax: 703-983-6143 || Cell: 703-850-4955 > > Email: charwing@mitre.org | charlotte.wales1@us.army.mil > > > > > From: Victor Giddings To: ada-rtf@omg.org Subject: Updated Proposed Resolution to 2095 Date: Fri, 24 Oct 2008 18:00:07 -0400 Cc: Nick Roberts X-Mailer: Apple Mail (2.929.2) All, Recall that we have an accepted resolution of this issue. The following is an alternate suggestion from Oliver Kellogg that I think has more merit. I have therefore, formalized the resolution. Feed back on the approach as well as the write-up are welcome: Disposition: Resolved OMG Issue No: 2095 Title: Suggestion on mapping the OMG IDL language to Ada Source: Lawrence Livermore National Laboratory . John Woodruff: woodruff1@llnl.gov Summary: Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Resolution: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef.s of each other were assumed to be the same type or at least freely convertible in common IDL usage), but the desire to not .lose. the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the adopted mapping. However, it has been suggested that the mapping choice, subtype or derived type, could be effectively controlled by a pragma, an element that annotates but is not part of the IDL syntax proper. The CORBA specification does require the handling of pragmas: .Conforming IDL compilers may support additional non-standard pragmas, but must not refuse to compile IDL source containing non-standard pragmas that are not understood by the compiler.. This provision allows the introduction of Ada-specific pragmas without breaking interoperability. The revised text below introduces a pragma that overrides the default choice of mapping of typedefs. It has also been suggested that the Ada-specific specification of range constraints be introduced in the same way. Thus, the following IDL: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; maps to: subtype MyLong is CORBA.Long range 0 .. 100; Of course, these pragmas could be separately applied to produce a subtype without range constraint or range constrained derived type. Revised Text: Change the last sentence of the first paragraph under section 3.13 to read: .An IDL typedef maps to an Ada derived type by default, or to an Ada subtype (see section 3.13.1).. Insert a new sub-section 3.13.1 after the first paragraph of the current section 3.13: 3.13.1 Controlling pragmas The default choice of mapping of a typedef may be overridden or reinforced by a pragma that appears before the typedef clause in the IDL in the same scope. The syntax of the pragmas are: #pragma .subtype. #pragma .derived. where is a simple identifier presumed to be type name that will be typedef.d in the same scope. A range constraint may be introduced to the result of the mapping of a typedef.d IDL type through a range pragma. The syntax of the pragma is: #pragma .range. where is a simple identifier presumed to be type name that will be typedef.d in the same scope, and range is a valid Ada range specification of the form .... , where both and are valid literals of the Ada subtype that the type specified in will be mapped to. Insert a new sub-section header after the inserted text above: 3.13.2 Mapping Substitute the following two paragraphs for the third (3rd) paragraph of the current section 3.13: Each simple declarator for a non-reference type, that is, a type not in CORBA.Object.Ref.CLASS, and that is not cited in a previous subtype or derived pragma, shall be mapped to a derived type declaration. Each simple declaration for a non-reference type that has previously been cited in a subtype pragma and for which the most recent subtype or derived pragma is a subtype pragma, shall be mapped to a subtype declaration. Each simple declaration for a non-reference type that has previously been cited in a derived pragma and for which the most recent subtype or derived pragma is a derived pragma, shall be mapped to a derived type declaration. Each simple declarator for a reference type shall be mapped to a subtype declaration. The type or subtype name shall be the identifier provided in the simple declarator. The type definition shall be the mapping of the typespec, as specified elsewhere in this section. Add the following to the example IDL typedef.s: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; Add the following to the example mappings: subtype MyLong is CORBA.Long range 0 .. 100; Disposition: Resolved Subject: RE: Updated Proposed Resolution to 2095 From: oliver.kellogg@t-online.de (Oliver Kellogg) Reply-To: okellogg@users.sourceforge.net To: steve.deller@ois.com Cc: "'Victor Giddings'" , "'Oliver Kellogg'" , ada-rtf@omg.org Date: Fri, 07 Aug 2009 18:11:13 +0200 X-Mailer: Evolution 2.24.1.1 X-ID: r1UdokZpohVwOIGqw5Vz8STAdB0-hVetq26ruwM2Ybub71ybFEfN40enaGMcyCfwdm X-TOI-MSGID: 7982c39b-7ada-4279-ac05-be8a7ecbd3a8 Hello Steve, On Fri, 2009-08-07 at 10:34 -0400, Steven Deller wrote: > Oliver, Vic, > If the values are IDL expressions, which I tend to like, perhaps they could be expressions that either resolve to a numeric constant or to a string constant. If numeric, then that number is used in the target language. If a string constant, the string would be passed "intact" to the target language. The logic could use the same resolution as that used for resolving the in a . That is the syntax would be > #pragma range [ .. ] > > With the added "feature" that each either resolve to the type or to a string literal. Sounds okay to me. In fact, sounds better than introducing an extra pragma just for the target language specific form of bound expressions. > e.g. all the following would be legal: > #pragma range my_t 1 .. "other_type'last + 1" > #pragma range my_t "other_type'range" > #pragma range my_t m_a::LB + 1 .. m_b::UB - 1 > > Note that for 'range to work, the pragma form would have to allow the .. and following expression to be optional. I guess that could be done; when the is not given, the maximum value of the type should be assumed as the default. If we take that route then IMHO the should also be made optional for symmetry. When not given, the default would be the minimum value of the type. So for example, typedef short my_t; with #pragma range my_t 0 would constrain my_t to 0 .. 32767 (Ada: CORBA.Short'Last), whereas #pragma range my_t .. 0 would constrain my_t to -32768 to 0. As a corner case, #pragma range my_t .. would imply the min and max type value as the range (effectively no constraint.) > ALTERNATIVELY, we could be more restrictive and define it as: > ::= #pragma range > ::= .. > | > > So then > #pragma range my_t 1 .. "other_type'last + 1" > > would not be allowed, but could be written as: > > #pragma range my_t "1 .. other_type'last + 1" > > I kind of like this last idea. It seems clean (can't mix IDL resolution > for one range end with target-language-specific for the other range end), > is able to do what I originally suggested, and should be easy to implement (IMO). > > Comments? > If we make the s optional then both solutions are fine with me. Oliver > -----Original Message----- > From: Oliver Kellogg [mailto:oliver.kellogg@t-online.de] > Sent: Thursday, August 06, 2009 12:35 PM > To: Victor Giddings > Cc: Oliver Kellogg; Steve Deller > Subject: Re: Updated Proposed Resolution to 2095 > > On Mon, 2009-08-03 at 10:28 -0400, Victor Giddings wrote: > > [...] > > > > On Mar 22, 2009, at 3:34 PM, Oliver Kellogg wrote: > > [...] > > > Looking again at your proposed resolution, > > > [...] > > > > where is a simple identifier presumed to be type name that > > > > will be typedefâ..d in the same scope, and range is a valid Ada > > > > range > > > > specification of the form â....â.ť , where > > > > both and are valid literals of the Ada > > > > subtype that the type specified in will be mapped to. > > > > > > You propose that and be Ada literals. > > > How about letting them be IDL literals? > > > That would be less specific to Ada, and would allow possible future > > > mapping revisions for other languages to exploit the same pragma. > > > > > > For example, in C++ the setters for valuetype members could use > > > the range information to code range checking in a similar way > > > as is built into Ada. > > > > > > > > > I had a different suggestion from Steve Deller -- to treat the range > > specification as opaque: > > > 3. The range constraint currently restricts the specification to a > > > subset of valid Ada range constraints. That implies the IDL > > > compiler ought to parse the range text to ensure it is only of the > > > form specified. I'd suggest that the pragma range permit an > > > arbitrary expression after the type name, which would be applied in > > > its entireity into the generated code. That would permit > > > expressions such as > > > other_type'range > > > and > > > 1 .. other_type'last+1 > > > besides the proposed > > > 1 .. 100 > > > > > > The description would then be: > > > ... that will be typedefâ..d later in the same scope, and range is a > > > valid Ada range specification for the Ada subtype or derived type > > > that the type specified in will be mapped to. > > > > > > The examples should then show "X'Range" and "1 .. 100" as possible > > > values so that it is understood that the Ada range specifiction may > > > involve multiple words. > > > > > > (Note that I believe this change is less onerous on IDL compilers, > > > since the string may just be copied verbatim, rather than requiring > > > the IDL compiler to parse the Ada range syntax to ensure it is of > > > the more restricted form currently proposed.) > > > > > > This would allow 'range expressions, etc. Any thoughts? > > As hinted at, we use the #pragma range in a target language independent > way, i.e. our IDL-to-C++, IDL-to-Java, and IDL-to-Ada translators all > use the same #pragma range syntax. > Leaving the lower/upper bound expressions in IDL syntax would permit > moving the range pragma from the IDL to Ada mapping standard to a more > general place, such as the IDL definition standard, with potential > application to all target languages. > > What I am proposing is that the and > be IDL expressions that resolve to constants that are of the same > IDL type as the typedef to which the range pragma is applied. > For example, > > module m_a { > const short LB = -1; > }; > module m_b { > const short UB = 100; > }; > module m_c { > typedef short small_number_t; > #pragma range small_number_t m_a::LB + 1 .. m_b::UB - 1 > }; > > would constrain small_number_t to the range 0 to 99. > (Expression resolution could be done either by the IDL compiler, or > the range expressions could be handed down into the generated code > for resolution by the target language compiler.) > > -- > > OTOH, it may be interesting to permit Ada specific syntax in the range > expressions. > How about introducing an extra pragma, such as > > #pragma ada_range .. > > where the range expressions could be defined as Steve Deller suggests. > > The pragma name would make it clear that this pragma is only intended > for IDL-to-Ada translation. > > Just my 2 cents - > > Oliver > > > > From: Victor Giddings To: ada-rtf@omg.org, Oliver Kellogg Subject: Proposed Revised Resolution for Issue 2095 Date: Sat, 8 Aug 2009 19:26:15 -0400 Cc: Steve Deller X-Mailer: Apple Mail (2.936) There has been further discussion around the "range" pragma introduced by last voted on resolution of this issue, so I would like to put a new resolution forward for review: Please be aware that I will be calling for a final vote on Monday for the remaining work of the RTF: Disposition: Resolved OMG Issue No: 2095 Title: Suggestion on mapping the OMG IDL language to Ada Source: Lawrence Livermore National Laboratory . John Woodruff: woodruff1@llnl.gov Summary: Experience with the IDL to Ada mapping (OMG Document 95-5-16) convention for generating distinct types for each IDL typedef leads me to suggest that generating a distinct Ada type for each IDL typedef results in numerous types which might more clearly be generated as subtypes of a single (family of) types. Resolution: The mapping of an IDL typedef to either a new Ada derived type or to an Ada subtype was discussed extensively during the initial development of the Ada mapping in 1995. At that time, it was recognized that the intended semantics of IDL fit Ada subtyping better (for example, arrays and sequences of elements that were typedef.s of each other were assumed to be the same type or at least freely convertible in common IDL usage), but the desire to not .lose. the stronger typing of Ada lead most to opt for the stronger derived typing mapping. That was the adopted mapping. However, it has been suggested that the mapping choice, subtype or derived type, could be effectively controlled by a pragma, an element that annotates but is not part of the IDL syntax proper. The CORBA specification does require the handling of pragmas: .Conforming IDL compilers may support additional non-standard pragmas, but must not refuse to compile IDL source containing non-standard pragmas that are not understood by the compiler.. This provision allows the introduction of Ada-specific pragmas without breaking interoperability. The revised text below introduces a pragma that overrides the default choice of mapping of typedefs. It has also been suggested that the Ada-specific specification of range constraints be introduced in the same way. Thus, the following IDL: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; maps to: subtype MyLong is CORBA.Long range 0 .. 100; Ada RTF 1.3 Disposition: Closed No Change OMG Issue No: 2095 Document {Report document number} Page 5 Of course, these pragmas could be separately applied to produce a subtype without range constraint or range constrained derived type. Revised Text: Change the last sentence of the first paragraph under section 3.13 to read: .An IDL typedef maps to an Ada derived type by default, or to an Ada subtype (see section 3.13.1).. Insert a new sub-section 3.13.1 after the first paragraph of the current section 3.13: 3.13.1 Controlling pragmas The default choice of mapping of a typedef may be overridden or reinforced by a pragma that appears before the typedef clause in the IDL in the same scope. The syntax of the pragmas are: #pragma subtype #pragma derived where is a simple identifier presumed to be type name that will be typedef.d in the same scope. It is an error to specify multiple subtype pragmas, multiple derived pragmas, or both subtype and derived pragmas for the same type. It is an error to specify a subtype pragma or a derived pragma after the corresponding type has been defined in IDL. It is an error to specify a subtype or a derived pragma for a type named in an array declarator. A range constraint may be introduced to the result of the mapping of a typedef.d IDL type through a range pragma. The BNF syntax of the pragma is: ::= #pragma range ::= [] [.. ] | where is a simple identifier presumed to be type name that will be typedef.d in the same scope, and specifies the range. If the range_constraint is a string_literal ,i.e., enclosed by quotations, the literal express is assumed to be valid in the target language and will be mapped lexically. Otherwise, each const_exp will be interpreted as if it were an IDL constant expression. The first const_exp, if any, specifies the minimum of the range for the subtype. If missing, the minimum of the range shall be the minimum of the unconstrained type. The second const_exp (i.e., the one after the ....) specifies the maximum of the range of the subtype. If missing, the maximum of the range shall be the maximum of the unconstrained type. It is an error to specify mulitple range pragmas for the same type. It is an error to specify a range pragma for a type named in an array declarator. It is an error to specify a range that is greater than the range of the parent type. Insert a new sub-section header after the inserted text above: 3.13.2 Mapping Substitute the following two paragraphs for the third (3rd) paragraph of the current section 3.13: Each simple declarator for a reference type, that is, a type in CORBA.Object.Ref'CLASS, shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is cited in a subtype pragma shall be mapped to a subtype declaration. Each simple declarator for a non-reference type that is not cited in a subtype pragma shall be mapped to a derived type declaration. The type or subtype name shall be the identifier provided in the simple declarator. The type definition shall be the mapping of the typespec, as specified elsewhere in this section. Add the following to the example IDL typedef.s: #pragma subtype Mylong #pragma range MyLong 0 .. 100 typedef long MyLong; #pragma range NewLong .MyLong.range. typedef long NewLong; const long MinNatural = 0; #pragma range Natural MinNatural typedef long Natural; Add the following to the example mappings: subtype MyLong is CORBA.Long range 0 .. 100; type NewLong is new CORBA.Long range MyLong.range; MinNatural : constant CORBA.Long = 0; type Natural is new CORBA.Long range MinNatural .. CORBA.Long.last; Disposition: Resolved Regards, Vic Victor Giddings victor_giddings@omg.org