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: Revised Text: Actions taken: October 19, 1998: received 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 > > > > >