* Ada202X: Easy to use "UML private"-like components @ 2013-06-21 8:43 Martin 2013-06-21 9:23 ` Dmitry A. Kazakov 2013-06-21 18:36 ` Robert A Duff 0 siblings, 2 replies; 54+ messages in thread From: Martin @ 2013-06-21 8:43 UTC (permalink / raw) I occasionally have the need to explain to people that Ada can support UML public, protected, private class data member scoping but to say it's confusing and clunky would be putting it mildly... Firstly, I have to public - that's easy: package CLA is type UML_Public is tagged record I : Integer; -- public to all, UML "public" F : Float; end record; end CLA; Secondly, I have to explain that using Ada "private" gives you "UML protected": package CLA is type UML_Protected is tagged private; private type UML_Protected is tagged record I : Integer; -- private to everyone excepted derived, UML "protected" F : Float; end record; end CLA; Finally, I have to explain that to get "UML private", you need to use an "opaque type" and and "access type": package CLA is type UML_Private is tagged private; private type Opaque; type UML_Private is tagged record I : Integer; -- private to everyone excepted derived, UML "protected" O : access Opaque; -- has to be access, as compiler doesn't -- know what Opaque is! end record; end CLA; package body CLA is type Opaque is record I : Integer; -- private to everyone, UML "private" F : Float; end record; end CLA; By now, the other person is usually rolling their eyes in disbelief and I'm nearly joining them... There's nothing we can do about Ada "private" v UML "protected" but I think there is a relatively small addition that could be made to the language that would at least avoid the embarrassment of the third part. My proposal would be to allow an optional "private component list" to record definitions, e.g. package CLA is type UML_Private is tagged private; private type UML_Private is tagged record I : Integer; -- private to everyone excepted derived, UML "protected" private F : Float; -- private to everyone - even derived, UML "private" end record; end CLA; Where a record had nothing but private components, it could either use: Option 1: type T is tagged record private F : Float; end record; or Option 2: type T is tagged record null; private F : Float; end record; I prefer Option 2. Thoughts? -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 8:43 Ada202X: Easy to use "UML private"-like components Martin @ 2013-06-21 9:23 ` Dmitry A. Kazakov 2013-06-21 9:33 ` Martin 2013-06-21 18:36 ` Robert A Duff 1 sibling, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-21 9:23 UTC (permalink / raw) On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 9:23 ` Dmitry A. Kazakov @ 2013-06-21 9:33 ` Martin 2013-06-21 10:14 ` G.B. 2013-06-21 14:51 ` Dmitry A. Kazakov 0 siblings, 2 replies; 54+ messages in thread From: Martin @ 2013-06-21 9:33 UTC (permalink / raw) On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote: > On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de But no easy means of keeping member data private from children. -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 9:33 ` Martin @ 2013-06-21 10:14 ` G.B. 2013-06-21 11:19 ` Martin 2013-06-21 14:51 ` Dmitry A. Kazakov 1 sibling, 1 reply; 54+ messages in thread From: G.B. @ 2013-06-21 10:14 UTC (permalink / raw) On 21.06.13 11:33, Martin wrote: > On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote: >> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de > > But no easy means of keeping member data private from children. But no pointers needed; I hope the following example is a reasonably accurate paraphrase of a hint given by Tucker Taft some years ago, memory is vague. Not sure if UML has a concept for capturing this, but confident that Grady Booch knows Ada's visibility rules well. (Or should one find a sentence that has "possibilities" instead of "rules"?) package Opaque is type Exposed is tagged private; private package Invisible is type T is tagged private; private type Scalr is range 1 .. 2; type T is tagged record Comp_1 : Scalr; end record; end Invisible; type Exposed is new Invisible.T with null record; end Opaque; private package Opaque.Child is A : Invisible.T; Y : Invisible.Scalr := A.Comp_1; end Opaque.Child; Compiling: opaque-child.ads (source file time stamp: 2013-06-21 10:06:44) 4. Y : Invisible.Scalr := A.Comp_1; 1 2 >>> "Scalr" is not a visible entity of "Invisible" >>> no selector "Comp_1" for private type "T" defined at opaque.ads:8 5 lines: 2 errors Thus, even a private child cannot see anything behind doubled fences. I imagine that explaining this needs some spin doctoring. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 10:14 ` G.B. @ 2013-06-21 11:19 ` Martin 0 siblings, 0 replies; 54+ messages in thread From: Martin @ 2013-06-21 11:19 UTC (permalink / raw) On Friday, June 21, 2013 11:14:12 AM UTC+1, G.B. wrote: > On 21.06.13 11:33, Martin wrote: > On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote: >> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de > > But no easy means of keeping member data private from children. But no pointers needed; I hope the following example is a reasonably accurate paraphrase of a hint given by Tucker Taft some years ago, memory is vague. Not sure if UML has a concept for capturing this, but confident that Grady Booch knows Ada's visibility rules well. (Or should one find a sentence that has "possibilities" instead of "rules"?) package Opaque is type Exposed is tagged private; private package Invisible is type T is tagged private; private type Scalr is range 1 .. 2; type T is tagged record Comp_1 : Scalr; end record; end Invisible; type Exposed is new Invisible.T with null record; end Opaque; private package Opaque.Child is A : Invisible.T; Y : Invisible.Scalr := A.Comp_1; end Opaque.Child; Compiling: opaque-child.ads (source file time stamp: 2013-06-21 10:06:44) 4. Y : Invisible.Scalr := A.Comp_1; 1 2 >>> "Scalr" is not a visible entity of "Invisible" >>> no selector "Comp_1" for private type "T" defined at opaque.ads:8 5 lines: 2 errors Thus, even a private child cannot see anything behind doubled fences. I imagine that explaining this needs some spin doctoring. Yeah, ok...hadn't thought of that way... But really, it's still a bit embaressing and it's almost as bad as the access type solution...almost... -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 9:33 ` Martin 2013-06-21 10:14 ` G.B. @ 2013-06-21 14:51 ` Dmitry A. Kazakov 2013-06-22 11:16 ` Martin 1 sibling, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-21 14:51 UTC (permalink / raw) On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote: > But no easy means of keeping member data private from children. On the contrary, don't make them children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 14:51 ` Dmitry A. Kazakov @ 2013-06-22 11:16 ` Martin 2013-06-22 12:10 ` Dmitry A. Kazakov 0 siblings, 1 reply; 54+ messages in thread From: Martin @ 2013-06-22 11:16 UTC (permalink / raw) On Friday, June 21, 2013 3:51:32 PM UTC+1, Dmitry A. Kazakov wrote: > On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote: > > > > > But no easy means of keeping member data private from children. > > > > On the contrary, don't make them children. But then I loose visibility of the classes protected operations... -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-22 11:16 ` Martin @ 2013-06-22 12:10 ` Dmitry A. Kazakov 0 siblings, 0 replies; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-22 12:10 UTC (permalink / raw) On Sat, 22 Jun 2013 04:16:55 -0700 (PDT), Martin wrote: > On Friday, June 21, 2013 3:51:32 PM UTC+1, Dmitry A. Kazakov wrote: >> On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote: >> >>> But no easy means of keeping member data private from children. >> >> On the contrary, don't make them children. > > But then I loose visibility of the classes protected operations... No operation can be both protected and private, not even in UML... The point is that Ada offers the same choice as UML does. However the roles are different. UML follows C++ where it is the provider of the type who must choose between public/protected/private. In Ada its public vs. not public for this role. Protected vs. public is to be decided by the user, i.e. much later. It is a good approach IMO, because protected vs. private choice is frequently far to premature for the provider. A too heavy burden to do, as usage of C++ shows. In the end the most sound policy for C++ is to avoid private operations except for the cases when Ada programmer would a subprogram into the package body. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 8:43 Ada202X: Easy to use "UML private"-like components Martin 2013-06-21 9:23 ` Dmitry A. Kazakov @ 2013-06-21 18:36 ` Robert A Duff 2013-06-22 16:41 ` Niklas Holsti 2013-07-09 11:24 ` Martin 1 sibling, 2 replies; 54+ messages in thread From: Robert A Duff @ 2013-06-21 18:36 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Not exactly. Ada "private" means clients can't see it, but child packages (which should be thought of as part of the same abstraction) can. It's a completely different visibility model than UML. I don't see any reason to be embarrassed about that. > Option 2: > type T is tagged record > null; > private > F : Float; > end record; > > > I prefer Option 2. > > Thoughts? I don't think making Ada more like UML is a worthwhile goal. If it were, I'd prefer your option 1. But I don't see the point: In Ada, packages are about visibility. That's different from languages that conflate the concept of "module" and "type" (which has both advantages and disadvantages). Overall, I prefer the Ada way. If you want derived types to see their parent types components, you put the derived types in a child package; if you don't, then you don't. Attempts to mimic UML in Ada lead to a mess, as you've shown. I share your disdain for what you called "opaque" types -- it forces you into heap management, which leads to extra trouble. But I object to calling them "opaque" types. Ada folks usually call them "stt access types" and "stt incomplete types", or "Taft amendment types", because they were invented by Tucker Taft and added to Ada 83 at the last minute when nobody realized all the headaches they cause for compiler writers. The term "opaque type" comes from Modula-2, IIRC, and is more like an Ada private type, with some annoying restrictions added. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 18:36 ` Robert A Duff @ 2013-06-22 16:41 ` Niklas Holsti 2013-06-22 19:05 ` Dennis Lee Bieber 2013-07-09 11:24 ` Martin 1 sibling, 1 reply; 54+ messages in thread From: Niklas Holsti @ 2013-06-22 16:41 UTC (permalink / raw) On 13-06-21 21:36 , Robert A Duff wrote: > I share your disdain for what you called "opaque" types -- it forces you > into heap management, which leads to extra trouble. But I object to > calling them "opaque" types. Ada folks usually call them "stt access > types" and "stt incomplete types", or "Taft amendment types", because > they were invented by Tucker Taft and added to Ada 83 at the last minute > when nobody realized all the headaches they cause for compiler writers. > The term "opaque type" comes from Modula-2, IIRC, and is more like > an Ada private type, with some annoying restrictions added. According to the Modula-2 Reference at http://www.modula2.org/reference/modules.php, when a Modula-2 definition module declares an opaque type, "The corresponding implementation module must contain a full type declaration for any opaque types declared in the definition module. The full type declaration must define a pointer type." I take this to mean that a Modula-2 opaque type uses indirection through a pointer type, just as the "stt access types" in Ada, and unlike Ada private types in general. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-22 16:41 ` Niklas Holsti @ 2013-06-22 19:05 ` Dennis Lee Bieber 2013-06-22 22:57 ` Niklas Holsti 0 siblings, 1 reply; 54+ messages in thread From: Dennis Lee Bieber @ 2013-06-22 19:05 UTC (permalink / raw) On Sat, 22 Jun 2013 19:41:00 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> declaimed the following: > >"The corresponding implementation module must contain a full type >declaration for any opaque types declared in the definition module. The >full type declaration must define a pointer type." > >I take this to mean that a Modula-2 opaque type uses indirection through >a pointer type, just as the "stt access types" in Ada, and unlike Ada >private types in general. I suspect that limitation comes about as lacking any knowledge of a structure, only the type name, the compiler doing the import has to make assumptions about the storage space of the type -- only a pointer would have a common, preknown, storage size for all imported opaque types. From "Programming in Modula-2: 3rd, corrected edition" [N. Wirth; 1985 Springer-Verlag], page 169: """ Definition modules imply the use of qualified export. Type definitions may consist of the full specification of the type (in this case its export is said to be transparent), or they may consist of the type identifier only. In this case the full specification must appear in the corresponding implementation module, and its export is said to be /opaque/. The type is known in the importing client modules by its name only, and all its properties are hidden. Therefore, procedures operating on operands of this type, and in particular operating on its components, must be defined in the same implementation module which hides the type's properties. Opaque export is restricted to pointers. Assignment and test for equality are applicable to all opaque types. """ Ada puts the details of the "hidden" part into the specification, where the compiler is capable of determining required space and generating instructions to copy (assign) or otherwise manipulate the structure -- even while preventing the programmer importing the specification from taking advantage of that knowledge. The use of a Modula-2 opaque export doesn't see it as a pointer -- it just a variable of the named type; the implementation module is where it is defined a pointer to some structure. Note that a strict reading of PiM-2 is not defining an "opaque type" but rather an "opaque export" <G>. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-22 19:05 ` Dennis Lee Bieber @ 2013-06-22 22:57 ` Niklas Holsti 2013-06-23 3:26 ` Dennis Lee Bieber 2013-06-23 12:28 ` Robert A Duff 0 siblings, 2 replies; 54+ messages in thread From: Niklas Holsti @ 2013-06-22 22:57 UTC (permalink / raw) On 13-06-22 22:05 , Dennis Lee Bieber wrote: > On Sat, 22 Jun 2013 19:41:00 +0300, Niklas Holsti > <niklas.holsti@tidorum.invalid> declaimed the following: > >> >> "The corresponding implementation module must contain a full type >> declaration for any opaque types declared in the definition module. The >> full type declaration must define a pointer type." >> >> I take this to mean that a Modula-2 opaque type uses indirection through >> a pointer type, just as the "stt access types" in Ada, and unlike Ada >> private types in general. > > I suspect that limitation comes about as lacking any knowledge of a > structure, only the type name, the compiler doing the import has to make > assumptions about the storage space of the type -- only a pointer would > have a common, preknown, storage size for all imported opaque types. Of course. The same consideration applies to the Ada "stt access type". > Ada puts the details of the "hidden" part into the specification, where > the compiler is capable of determining required space and generating > instructions to copy (assign) or otherwise manipulate the structure -- even > while preventing the programmer importing the specification from taking > advantage of that knowledge. For private types, yes; for "stt access types", the details of the accessed type are deferred to the package body, as for Modula-2 opaque types/exports. > The use of a Modula-2 opaque export doesn't see it as a pointer -- it > just a variable of the named type; Just as for an Ada private type which (in the private part of the spec) is completed as an "stt access type". I think this is the usual way in which "stt access types" are used in Ada: their "access" nature is not made public. > the implementation module is where it is > defined a pointer to some structure. But, since Modula-2 allows only pointer types to be opaque, the Modula-2 compiler knows that the type is a pointer even when compiling the definition module and before compiling the implementation module. Just as for Ada "stt access types". Maybe my post was unclear: I tried to contradict Bob Duff's recollection that an opaque type in Modula-2 is more like an Ada private type than like an "stt access type". I think that a Modula-2 opaque type is very similar to an "stt access type". Do you agree with me? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-22 22:57 ` Niklas Holsti @ 2013-06-23 3:26 ` Dennis Lee Bieber 2013-06-23 7:32 ` Niklas Holsti 2013-06-23 12:28 ` Robert A Duff 1 sibling, 1 reply; 54+ messages in thread From: Dennis Lee Bieber @ 2013-06-23 3:26 UTC (permalink / raw) On Sun, 23 Jun 2013 01:57:17 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> declaimed the following: > >Maybe my post was unclear: I tried to contradict Bob Duff's recollection >that an opaque type in Modula-2 is more like an Ada private type than >like an "stt access type". I think that a Modula-2 opaque type is very >similar to an "stt access type". Do you agree with me? Having just refetched a few days of the thread to find out what "stt access type" means, I can not comment on your assertion. My first exposure with Ada, proper, was in January of 1981 when Lockheed sent a cadre to a class -- a point in time when the NYU Ada/Ed Translator was the only thing almost available, and just three weeks after Mil-Std 1815 was announced (I'd had earlier exposure to the SIGPlan Notices publication of the proposed Ada Language RM and Rationale, and a thin blue book introducing the language). Only to end up in an assignment that used FORTRAN-77... My next chance at Ada was 15 years later, when I encountered AdaGIDE and GNAT. So any contentious features in Ada-83 passed me by totally. It was nearly another 10 years before I actually got to use Ada at work (and that required getting laid-off, rehired for some VC++ [on a W98 laptop!], and a few bouts of Python while trying to avoid another lay-off). So whatever these "stt access types" are, they are not something I've encountered in my use of Python -- they sound a lot like a programming convention for subverting what the compiler was designed to handle. Modula-2's opaque exports, OTOH, are the compiler's requirement for handling data abstraction -- not something a programmer just uses in lieu of some other paradigm. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 3:26 ` Dennis Lee Bieber @ 2013-06-23 7:32 ` Niklas Holsti 2013-06-23 13:12 ` Robert A Duff 0 siblings, 1 reply; 54+ messages in thread From: Niklas Holsti @ 2013-06-23 7:32 UTC (permalink / raw) On 13-06-23 06:26 , Dennis Lee Bieber wrote: > On Sun, 23 Jun 2013 01:57:17 +0300, Niklas Holsti > <niklas.holsti@tidorum.invalid> declaimed the following: > >> >> Maybe my post was unclear: I tried to contradict Bob Duff's recollection >> that an opaque type in Modula-2 is more like an Ada private type than >> like an "stt access type". I think that a Modula-2 opaque type is very >> similar to an "stt access type". Do you agree with me? > > Having just refetched a few days of the thread to find out what "stt > access type" means, I can not comment on your assertion. The term was also unfamiliar to me, before Bob Duff's post. To make it clear, I think ( :-) ) we are discussing a structure of this form: package Pkg is type T is private; ... operations on T ... private type Object; -- Will be completed in the body of Pkg. type T is access Object; end Pkg; Here Pkg.T is the type used by the clients, and is the "stt access type", because it is an access to an incompletely declared type, Pkg.Object. The type Pkg.Object is completed in the package body: package body Pkg is type Object is ... whatever ... ... operation bodies ... end Pkg; Pkg.T corresponds to a Modula-2 opaque type (or opaque eport, if you prefer). Both the Ada compiler and the Modula-2 compiler know, based on the package declaration or the definition module, that Pkg.T is a pointer. Neither compiler knows anything about the type of the object to which Pkg.T points, until the package body or implementation module is compiled. As far as I can see, the main difference between Ada and Modula-2 is that the Ada package declaration has to name the underlying type (Pkg.Object), because it has to declare Pkg.T as "access Object". That is not necessary in the Modula-2 definition module, because the opaque type declaration in Modula-2 implies that the type is a pointer. (As I understand it, Modula-2 has no other concept of "private type".) > So whatever these "stt access types" are, they are not something I've > encountered in my use of Python -- they sound a lot like a programming > convention for subverting what the compiler was designed to handle. They provide further separation of the declaration and implementation o the type, just as the Modula-2 opaque types do, and with the same drawbacks (see below). > Modula-2's opaque exports, OTOH, are the compiler's requirement for > handling data abstraction -- not something a programmer just uses in lieu > of some other paradigm. Because Modula-2 has no other way to privatize types. In Ada, the "private type" feature lets you hide the structure of a type from clients, yet reveal it fully in the package declaration, for the compiler's benefit. You can then decide whether or not to use an access type, i.e. an "stt access type" such as Pkg.T above. If you use an access type, you can defer the full declaration of the underlying type (and the necessary "with" clauses) to the package body, but this usually requires heap allocation of the objects. I tend to use "stt access types" when the type in question (e.g. Pkg.T) needs reference semantics and heap allocation anyway. (Being rather conservative in my programming style, I haven't yet leapt fully into controlled types.) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 7:32 ` Niklas Holsti @ 2013-06-23 13:12 ` Robert A Duff 2013-06-23 14:06 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Robert A Duff @ 2013-06-23 13:12 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > Pkg.T corresponds to a Modula-2 opaque type (or opaque eport, if you > prefer). Both the Ada compiler and the Modula-2 compiler know, based on > the package declaration or the definition module, that Pkg.T is a > pointer. Neither compiler knows anything about the type of the object to > which Pkg.T points, until the package body or implementation module is > compiled. The compilation model is that when compiling something, the compiler looks at information coming from the specs of imported things, but not their bodies. Modula-2 compilers actually work that way, and this is the reason for the must-be-pointer (or must be the same size as a pointer, or smaller, as I had (mis?)remembered it). It is also the reason for the private part kludge: the compiler sees the size of the full type for a private type (assuming it is known at compile time). But this reasoning makes no sense to me, because that's not how Ada compilers work. Any reasonable implementation of generics and inlining needs to look at bodies. So full types should be in bodies, and compilers should look there (at least in optimizing mode) to find out their size. On the other hand, the private part kludge wouldn't be so bad if the syntax were different: The private part should be a separate syntactic compilation_unit, with its own with clauses, and should normally be stored in a separate source file from the visible part. There's an awful lot of horrible code duplication caused by the fact that the private part is in the same file as the visible part. Separating it out into a different file would not prevent the compiler from looking at it! - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 13:12 ` Robert A Duff @ 2013-06-23 14:06 ` Dmitry A. Kazakov 2013-06-23 15:15 ` Robert A Duff 2013-06-24 20:07 ` Randy Brukardt 2013-06-23 14:40 ` Shark8 2013-06-24 20:05 ` Randy Brukardt 2 siblings, 2 replies; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-23 14:06 UTC (permalink / raw) On Sun, 23 Jun 2013 09:12:53 -0400, Robert A Duff wrote: > It is also the reason for the private part kludge: the compiler sees > the size of the full type for a private type (assuming it is known > at compile time). But this reasoning makes no sense to me, because > that's not how Ada compilers work. Any reasonable implementation > of generics and inlining needs to look at bodies. So full types > should be in bodies, and compilers should look there (at least > in optimizing mode) to find out their size. ... or there should be no generics. The kludge here rather is generics and inlining, both basically are macro expansions. To have public and private parts of the specifications makes much sense to me, as well as to have bodies which are not allowed for looking into (e.g. for shared libraries, remote objects etc). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 14:06 ` Dmitry A. Kazakov @ 2013-06-23 15:15 ` Robert A Duff 2013-06-23 18:52 ` Dmitry A. Kazakov 2013-06-24 20:07 ` Randy Brukardt 1 sibling, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-23 15:15 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > ... or there should be no generics. > > The kludge here rather is generics and inlining, both basically are macro > expansions. Semantics defined by macro-expansion is confusing, and should be avoided. I'd prefer to have generic types rather than generic packages, and don't use macro-expansion semantics. Eiffel shows one way to do this. Inlining, on the other hand, has no semantics. Or should have none. And it can be turned off when you want faster recompiles but slower run time. And inlining is inherently a macro expansion. > To have public and private parts of the specifications makes much sense to > me, as well as to have bodies which are not allowed for looking into (e.g. > for shared libraries, remote objects etc). Well, yeah, you can't very well inline across shared libraries, but I don't see any need for that to be part of the language syntax. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 15:15 ` Robert A Duff @ 2013-06-23 18:52 ` Dmitry A. Kazakov 2013-06-23 23:38 ` Robert A Duff 0 siblings, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-23 18:52 UTC (permalink / raw) On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> ... or there should be no generics. >> >> The kludge here rather is generics and inlining, both basically are macro >> expansions. > > Semantics defined by macro-expansion is confusing, and should be > avoided. I'd prefer to have generic types rather than generic > packages, and don't use macro-expansion semantics. Still macro expansion it is (if meant as textual substitution). It is no matter how you reinterpret the expanded text: as a package, as a type, as a statement, identifier, declaration etc. Generic types would be no better than generic packages. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 18:52 ` Dmitry A. Kazakov @ 2013-06-23 23:38 ` Robert A Duff 2013-06-24 7:16 ` Dmitry A. Kazakov 0 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-23 23:38 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> ... or there should be no generics. >>> >>> The kludge here rather is generics and inlining, both basically are macro >>> expansions. >> >> Semantics defined by macro-expansion is confusing, and should be >> avoided. I'd prefer to have generic types rather than generic >> packages, and don't use macro-expansion semantics. > > Still macro expansion it is (if meant as textual substitution). No, as I said above, "don't use macro-expansion semantics"! One can have "Sequence of Integer" and "Sequence of Whatever" without any macro-expansion/textual-substitution semantics. And with full type safety (can't pluck a Mumble out of a "Sequence of Integer"). > It is no matter how you reinterpret the expanded text: as a package, as a > type, as a statement, identifier, declaration etc. Generic types would be > no better than generic packages. There should be no "expanded text" in my view. Maybe that's what you mean when you say "no generics", but then you should say "no Ada-style generics" (or C++-style templates). - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 23:38 ` Robert A Duff @ 2013-06-24 7:16 ` Dmitry A. Kazakov 2013-06-24 20:11 ` Randy Brukardt 0 siblings, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-24 7:16 UTC (permalink / raw) On Sun, 23 Jun 2013 19:38:47 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> ... or there should be no generics. >>>> >>>> The kludge here rather is generics and inlining, both basically are macro >>>> expansions. >>> >>> Semantics defined by macro-expansion is confusing, and should be >>> avoided. I'd prefer to have generic types rather than generic >>> packages, and don't use macro-expansion semantics. >> >> Still macro expansion it is (if meant as textual substitution). > > No, as I said above, "don't use macro-expansion semantics"! > One can have "Sequence of Integer" and "Sequence of Whatever" > without any macro-expansion/textual-substitution semantics. > And with full type safety (can't pluck a Mumble out of a > "Sequence of Integer"). > >> It is no matter how you reinterpret the expanded text: as a package, as a >> type, as a statement, identifier, declaration etc. Generic types would be >> no better than generic packages. > > There should be no "expanded text" in my view. Maybe that's what > you mean when you say "no generics", but then you should say > "no Ada-style generics" (or C++-style templates). OK, but if not "expansion" then Ada already has such types: discriminated subtypes and tagged types. Both are dynamically parametric types. Neither requires looking into the bodies. Maybe they could be augmented in order to deal with more complex kinds of parametrization, e.g. for container types (sequence of Integer indexed by String). But again, please, without opening up the bodies. You don't need the body unless you "expand". -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 7:16 ` Dmitry A. Kazakov @ 2013-06-24 20:11 ` Randy Brukardt 2013-06-25 7:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 54+ messages in thread From: Randy Brukardt @ 2013-06-24 20:11 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net... ... > Maybe they could be augmented in order to deal with more complex kinds of > parametrization, e.g. for container types (sequence of Integer indexed by > String). But again, please, without opening up the bodies. > > You don't need the body unless you "expand". You don't need the body even if you *do* "expand" (as Ada does). The Ada contract model is strict enough that universal code sharing works (and the contract model could be stronger still). I always thought it made more sense to code share first and then use inlining to eliminate the overhead later, because it's almost impossible to share code after generating it separately. (We never built the inlining part of the compiler, though, so we never quite proved that.) Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 20:11 ` Randy Brukardt @ 2013-06-25 7:21 ` Dmitry A. Kazakov 2013-06-25 19:06 ` Randy Brukardt 0 siblings, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-06-25 7:21 UTC (permalink / raw) On Mon, 24 Jun 2013 15:11:11 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net... > ... >> Maybe they could be augmented in order to deal with more complex kinds of >> parametrization, e.g. for container types (sequence of Integer indexed by >> String). But again, please, without opening up the bodies. >> >> You don't need the body unless you "expand". > > You don't need the body even if you *do* "expand" (as Ada does). The Ada > contract model is strict enough that universal code sharing works (and the > contract model could be stronger still). Here is a logical contradiction. If the model were that strong you would need no bodies to look into, the public part declaration should be enough for using the type. But the model is not enough strong and it is not enough precise. You can write type T is private; and there is no contract put on T'Size. Without that contract you cannot have type A is array (...) of T; etc. Either 1. The contract model should be much more precise and explicit, e.g. with interfaces: -- Not Ada type T is new Abstract_Fixed_Size_Type_Interface with private; overriding function "'Size" (Object : T) return Universal_Integer; or 2. You must have private part available for the compiler to deduce missing information. I prefer both. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-25 7:21 ` Dmitry A. Kazakov @ 2013-06-25 19:06 ` Randy Brukardt 0 siblings, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-25 19:06 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:12c0h7muc9ab1$.1rn058nrhw3m8.dlg@40tude.net... > On Mon, 24 Jun 2013 15:11:11 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net... >> ... >>> Maybe they could be augmented in order to deal with more complex kinds >>> of >>> parametrization, e.g. for container types (sequence of Integer indexed >>> by >>> String). But again, please, without opening up the bodies. >>> >>> You don't need the body unless you "expand". >> >> You don't need the body even if you *do* "expand" (as Ada does). The Ada >> contract model is strict enough that universal code sharing works (and >> the >> contract model could be stronger still). > > Here is a logical contradiction. If the model were that strong you would > need no bodies to look into, the public part declaration should be enough > for using the type. I'm not talking about the public part only; I'm definitely including the private part as well. > But the model is not enough strong and it is not enough precise. You can > write > > type T is private; > > and there is no contract put on T'Size. Without that contract you cannot > have > > type A is array (...) of T; Of course you can have that. Janus/Ada uses universal code sharing, so if T is a formal private type, you have precisely this situation -- and it works fine. The compiler simply has to insert a level of indirection; the programmer need not know that it is there -- the compiler can manage it for you (including all of the memory management). Just as with mutable discriminanted records, there is no reason that the complications have to be made visible to the programmer. This is not done more mostly because compiler writers don't want the extra work. They don't much care that not having these features makes more work for the programmer, and so long as programmers don't demand this support, they aren't going to get it. (The excuse for not providing it is that systems that have strong verification requirements can't have the implicit allocation and deallocation that is implied. I suppose that's true, but even then why should the support be denied to everyone else?). ... > 2. You must have private part available for the compiler to deduce missing > information. I was certainly assuming this in my original response. I'm not sure why you thought otherwise, as I was clearly talking about in current Ada and paying little attention to whatever Bob was talking about (it's misguided at best). Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 14:06 ` Dmitry A. Kazakov 2013-06-23 15:15 ` Robert A Duff @ 2013-06-24 20:07 ` Randy Brukardt 1 sibling, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-24 20:07 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1im71djlxwm94$.fbjv1si7kmvj$.dlg@40tude.net... > On Sun, 23 Jun 2013 09:12:53 -0400, Robert A Duff wrote: > >> It is also the reason for the private part kludge: the compiler sees >> the size of the full type for a private type (assuming it is known >> at compile time). But this reasoning makes no sense to me, because >> that's not how Ada compilers work. Any reasonable implementation >> of generics and inlining needs to look at bodies. So full types >> should be in bodies, and compilers should look there (at least >> in optimizing mode) to find out their size. > > ... or there should be no generics. > > The kludge here rather is generics and inlining, both basically are macro > expansions. Or better, they can be done at bind time without any impact on what compilers look at. Bob is just plain wrong in the above -- perhaps that is how GNAT and AdaMagic works, but there is no reason that an Ada compiler has to (or *ought* to) work that way. Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 13:12 ` Robert A Duff 2013-06-23 14:06 ` Dmitry A. Kazakov @ 2013-06-23 14:40 ` Shark8 2013-06-23 15:28 ` Robert A Duff 2013-06-24 20:05 ` Randy Brukardt 2 siblings, 1 reply; 54+ messages in thread From: Shark8 @ 2013-06-23 14:40 UTC (permalink / raw) On Sunday, June 23, 2013 7:12:53 AM UTC-6, Robert A Duff wrote: > > > On the other hand, the private part kludge wouldn't be so bad if > the syntax were different: Perhaps something like this? Package Example is Type Opaque is private; private Type Opaque is separate COMPLETE_NAME; -- This flags to the compiler that the full type appears in the -- package body (as COMPLETE_NAME) and the public 'Opaque' is -- actually a pointer/reference/(not null access) to COMPLETE_NAME, -- also any primitive ops for Opaque are transitively private ops -- of COMPLETE_NAME. end; > The private part should be a separate > syntactic compilation_unit, with its own with clauses, and should > normally be stored in a separate source file from the visible part. I don't know. Certainly for consistency's sake yes, but getting compiler writers to implement that as well might have been a death-knell for Ada 83. Moreover, we would need some way to flag there isn't a PRIVATE area, like PRIVATE IS NULL; (Or conversely have the private section optionally in the spec, as it is now, but with PRIVATE IS SEPARATE as the trigger for an external private section.) > There's an awful lot of horrible code duplication caused by the > fact that the private part is in the same file as the visible part. I'm not sure about that. Consider this: Type K; Type J is record Item : K; -- might need to be access K. end record; Type K is new Integer Range 0..100; Sure "Type K" appears twice, but that's required so that we have some name for the type of J.Item. The items (full declarations) in the PRIVATE section are likewise. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 14:40 ` Shark8 @ 2013-06-23 15:28 ` Robert A Duff 2013-06-23 18:14 ` Bill Findlay 2013-06-24 20:16 ` Randy Brukardt 0 siblings, 2 replies; 54+ messages in thread From: Robert A Duff @ 2013-06-23 15:28 UTC (permalink / raw) Shark8 <onewingedshark@gmail.com> writes: > On Sunday, June 23, 2013 7:12:53 AM UTC-6, Robert A Duff wrote: >> >> >> On the other hand, the private part kludge wouldn't be so bad if >> the syntax were different: > > Perhaps something like this? No, that's not at all what I meant. I meant that a package would come in three parts: package P is ... end P; package private P is -- Just making up syntax here. ... end P; package body P is ... end P; Normally stored in 3 separate source files. There would be no private part syntax like we currently have. I'm not suggesting this is the best idea -- I'm just suggesting that it would fit in with the compilation model the Ada 83 designers had in mind. I would ditch that model, thus making the above suggestion irrelevant. > Package Example is > Type Opaque is private; > private > Type Opaque is separate COMPLETE_NAME; > -- This flags to the compiler that the full type appears in the > -- package body (as COMPLETE_NAME) and the public 'Opaque' is > -- actually a pointer/reference/(not null access) to COMPLETE_NAME, > -- also any primitive ops for Opaque are transitively private ops > -- of COMPLETE_NAME. > end; No, it's a bad idea to force the explicit use of pointer/heap when it's not logically necessary. C does that a lot. Ada less, but it could be even less. >> The private part should be a separate >> syntactic compilation_unit, with its own with clauses, and should >> normally be stored in a separate source file from the visible part. > > I don't know. Certainly for consistency's sake yes, but getting > compiler writers to implement that as well might have been a > death-knell for Ada 83. My suggestion is trivial to implement. And it wouldn't be "as well", it would be "instead of". >...Moreover, we would need some way to flag > there isn't a PRIVATE area, like PRIVATE IS NULL; (Or conversely have > the private section optionally in the spec, as it is now, but with > PRIVATE IS SEPARATE as the trigger for an external private section.) No, my suggestion is that there is NEVER a "private area", so there's no need to indicate that there is none. I'm not suggesting this as a change to Ada -- I'm suggesting that it would have been a better way to design Ada 83. >> There's an awful lot of horrible code duplication caused by the >> fact that the private part is in the same file as the visible part. > > I'm not sure about that. Consider this: > Type K; > > Type J is record > Item : K; -- might need to be access K. > end record; > > Type K is new Integer Range 0..100; > > Sure "Type K" appears twice, but that's required so that we have some > name for the type of J.Item. The items (full declarations) in the > PRIVATE section are likewise. Sorry, I wasn't clear. That's not the duplication I'm talking about. I'm talking about the case where you have an abstraction with multiple implementations. This happens often in the GNAT runtimes, for example. Since the private part is part of the implementation, you need multiple copies of it for different platforms/environments. Given Ada as it is, that forces you to make multiple copies of the visible part, which is a violation of the DRY principle. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 15:28 ` Robert A Duff @ 2013-06-23 18:14 ` Bill Findlay 2013-06-23 23:43 ` Robert A Duff 2013-06-24 20:16 ` Randy Brukardt 1 sibling, 1 reply; 54+ messages in thread From: Bill Findlay @ 2013-06-23 18:14 UTC (permalink / raw) On 23/06/2013 16:28, in article wccppvc26ef.fsf@shell01.TheWorld.com, "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote: > No, that's not at all what I meant. I meant that a package would > come in three parts: > > package P is > ... > end P; > > package private P is -- Just making up syntax here. > ... > end P; > > package body P is > ... > end P; > > Normally stored in 3 separate source files. There would be no > private part syntax like we currently have. > > I'm not suggesting this is the best idea -- I'm just suggesting > that it would fit in with the compilation model the Ada 83 designers > had in mind. I would ditch that model, thus making the above > suggestion irrelevant. That is exactly what Ichbiah's previous language, LIS, had: IIRC interface, representation, and implementation parts as separate compilation units. -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 18:14 ` Bill Findlay @ 2013-06-23 23:43 ` Robert A Duff 2013-06-23 23:48 ` Bill Findlay 0 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-23 23:43 UTC (permalink / raw) Bill Findlay <yaldnif.w@blueyonder.co.uk> writes: > That is exactly what Ichbiah's previous language, LIS, had: > IIRC interface, representation, and implementation parts as separate > compilation units. Interesting. I think maybe I've given my rant before, and maybe you have replied with the above information before, but I've forgotten it. I don't know LIS at all, and I'm too lazy to google it right now -- maybe one of these days. But why, oh why, then, didn't Icbiah include that obvious idea in Ada 83?! - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 23:43 ` Robert A Duff @ 2013-06-23 23:48 ` Bill Findlay 0 siblings, 0 replies; 54+ messages in thread From: Bill Findlay @ 2013-06-23 23:48 UTC (permalink / raw) On 24/06/2013 00:43, in article wccmwqgmlzg.fsf@shell01.TheWorld.com, "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote: > Bill Findlay <yaldnif.w@blueyonder.co.uk> writes: > >> That is exactly what Ichbiah's previous language, LIS, had: >> IIRC interface, representation, and implementation parts as separate >> compilation units. > > Interesting. I think maybe I've given my rant before, and maybe you > have replied with the above information before, but I've forgotten > it. I don't know LIS at all, and I'm too lazy to google it right > now -- maybe one of these days. > > But why, oh why, then, didn't Icbiah include that obvious idea in > Ada 83?! 50% increase in compilation overheads? -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 15:28 ` Robert A Duff 2013-06-23 18:14 ` Bill Findlay @ 2013-06-24 20:16 ` Randy Brukardt 1 sibling, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-24 20:16 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccppvc26ef.fsf@shell01.TheWorld.com... ... > No, that's not at all what I meant. I meant that a package would > come in three parts: > > package P is > ... > end P; > > package private P is -- Just making up syntax here. > ... > end P; > > package body P is > ... > end P; > > Normally stored in 3 separate source files. There would be no > private part syntax like we currently have. ... > My suggestion is trivial to implement. And it wouldn't be "as well", > it would be "instead of". I don't buy this. The specification would not have enough information to be usable, so compilation of it would be worthless. But because of the separate sets of withs, you'd have to be able to separately compile the private part (it couldn't be required to compile at the same time), so the complications would be doubled (if not more). And compiling a specification is already painful (because of all of the stuff that has to be delayed and fixed up at the end), having to delay that stuff indefinitely would be much worse. I'm think your suggestion could be implemented with enough effort, but it isn't within a country mile of being trivial. Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 13:12 ` Robert A Duff 2013-06-23 14:06 ` Dmitry A. Kazakov 2013-06-23 14:40 ` Shark8 @ 2013-06-24 20:05 ` Randy Brukardt 2013-06-25 1:09 ` Robert A Duff 2 siblings, 1 reply; 54+ messages in thread From: Randy Brukardt @ 2013-06-24 20:05 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccmwqhkm22.fsf@shell01.TheWorld.com... ... > The compilation model is that when compiling something, the compiler > looks at information coming from the specs of imported things, but not > their bodies. Modula-2 compilers actually work that way, and this > is the reason for the must-be-pointer (or must be the same size as > a pointer, or smaller, as I had (mis?)remembered it). > > It is also the reason for the private part kludge: the compiler sees > the size of the full type for a private type (assuming it is known > at compile time). But this reasoning makes no sense to me, because > that's not how Ada compilers work. Any reasonable implementation > of generics and inlining needs to look at bodies. So full types > should be in bodies, and compilers should look there (at least > in optimizing mode) to find out their size. Baloney. Maybe *most* Ada compilers work this way, but certainly not all: Janus/Ada works exactly like your description of Modula-2 compilers. Generics are implemented with universal code sharing in Janus/Ada for precisely this reason -- our compiler never looks in a body other than to compile it. (We were fanatical about minimizing compilation dependencies, because when a single compilation took 2-4 minutes, building anything significant took hours.) Janus/Ada doesn't do inlining at all, other than of things visible in specifications (expression functions make a significant expansion of what can be inlined -- one of the reasons the idea was invented in the first place, many years ago). If it ever does do inlining of subprograms, it would do it at bind-time, (and mostly automatically). I think Ada's allowing of those extra compilation dependencies caused most compilers to have insanely long build cycles in the early days of Ada, and probably caused a lot of damage to Ada's reputation. As such, this was one of the worst decisions of Ada. (I have to agree it doesn't matter so much anymore, but no one is building Ada compilers from scratch.) > On the other hand, the private part kludge wouldn't be so bad if > the syntax were different: The private part should be a separate > syntactic compilation_unit, with its own with clauses, and should > normally be stored in a separate source file from the visible part. > There's an awful lot of horrible code duplication caused by the > fact that the private part is in the same file as the visible part. > Separating it out into a different file would not prevent the > compiler from looking at it! I still think this is a horrible idea; it certainly would be a complete earthquake for Janus/Ada, which only knows how to process one source file at a time. There would be no way to "look at" such a file when compiling the specification, and thus we'd end up having to create a "specification" file containing no useful information. It would be a total mess (especially as I can't imagine how compilation ordering could be made to work in such a scenario). And this doesn't make any sense when combined with child packages. Once one allows visibility into the private part in some other unit (like a child unit), it's no longer really separate in any way. Perhaps this would make sense in some Ada-like language, but not for Ada. Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 20:05 ` Randy Brukardt @ 2013-06-25 1:09 ` Robert A Duff 2013-06-25 19:37 ` Randy Brukardt 0 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-25 1:09 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wccmwqhkm22.fsf@shell01.TheWorld.com... > ... >> It is also the reason for the private part kludge: the compiler sees >> the size of the full type for a private type (assuming it is known >> at compile time). But this reasoning makes no sense to me, because >> that's not how Ada compilers work. Any reasonable implementation >> of generics and inlining needs to look at bodies. So full types >> should be in bodies, and compilers should look there (at least >> in optimizing mode) to find out their size. > > Baloney. Maybe *most* Ada compilers work this way, but certainly not all: > Janus/Ada works exactly like your description of Modula-2 compilers. > Generics are implemented with universal code sharing in Janus/Ada for > precisely this reason -- our compiler never looks in a body other than to > compile it. Perhaps I should have said "reasonably efficient implementation". You can't implement generics efficiently (I'm talking about run-time efficiency) without doing at least some macro expansion. >... (We were fanatical about minimizing compilation dependencies, > because when a single compilation took 2-4 minutes, building anything > significant took hours.) Yes, no-macro-expansion favors efficiency at compile time. But you're going against the grain there -- your compiler design should be dead easy, but it's quite complicated because the semantics are defined in terms of macro expansion. (Consider an exception declared in a generic package body -- each instance must have a different exception.) > Janus/Ada doesn't do inlining at all, ... Well, there goes (run-time) efficiency. Seriously, I don't see how "don't do inlining" is a reasonable implementation of inlining. >...other than of things visible in > specifications (expression functions make a significant expansion of what > can be inlined -- one of the reasons the idea was invented in the first > place, many years ago). If it ever does do inlining of subprograms, it would > do it at bind-time, (and mostly automatically). "mostly automatically" is good. But I don't see how bind time (i.e. link time) helps. It's a reasonable approach, but it takes just as long to generate code at link time as it does at compile time, for the same generated code. If you modify the procedure body being inlined, you have to regenerate code at all call sites, either way. > I still think this is a horrible idea; it certainly would be a complete > earthquake for Janus/Ada, which only knows how to process one source file at > a time. There would be no way to "look at" such a file when compiling the > specification, and thus we'd end up having to create a "specification" file > containing no useful information. It would be a total mess (especially as I > can't imagine how compilation ordering could be made to work in such a > scenario). I was suggesting that Ada 83 should have been different. (And in fact, somebody pointed out that Ichbiah's language LIS was in fact different in that way!) If that had been the case, you (and others) would have designed your compiler differently. It would not have been rocket surgery. (Yes, modifying a compiler after the fact could easily be rocket surgery. > And this doesn't make any sense when combined with child packages. Once one > allows visibility into the private part in some other unit (like a child > unit), it's no longer really separate in any way. Yes, Tucker made a virtue out of necessity. Private parts are a kludge. The fact that child units can see into parent private parts is useful, but it's not how I would design a language from scratch. > Perhaps this would make sense in some Ada-like language, but not for Ada. Right, an Ada-83-like language. Today, my suggestion makes no sense. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-25 1:09 ` Robert A Duff @ 2013-06-25 19:37 ` Randy Brukardt 0 siblings, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-25 19:37 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcctxknt2r7.fsf@shell01.TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: ... >> Janus/Ada doesn't do inlining at all, ... > > Well, there goes (run-time) efficiency. Seriously, I don't see how > "don't do inlining" is a reasonable implementation of inlining. It's unclear to me that inlining makes enough difference for the implementation earthquake that it would have represented in Janus/Ada (several man-years of work). Since Janus/Ada compiles statements directly from their syntax, the largest program structure that it can store is an expression tree (and that was a later change, necessitated by the requirements of Ada resolution - the original design was purely syntax-driven). That would allow inlining of expression functions (and functions that are similar to expression functions), but little larger. (One could imagine converting if statements into if expressions to allow a bit more inlining.) >>...other than of things visible in >> specifications (expression functions make a significant expansion of what >> can be inlined -- one of the reasons the idea was invented in the first >> place, many years ago). If it ever does do inlining of subprograms, it >> would >> do it at bind-time, (and mostly automatically). > > "mostly automatically" is good. > > But I don't see how bind time (i.e. link time) helps. It's a reasonable > approach, but it takes just as long to generate code at link time as it > does at compile time, for the same generated code. If you modify the > procedure body being inlined, you have to regenerate code at all call > sites, either way. Doing this at bind-time allows inlining stuff that neither the user nor the compiler really know might be inlined, and it also allows partial evaluation of calls based on what is actually present in the program (think about the second parameter to New_Line -- it's hardly ever used; code shared generics have a similar parameter for sharing information, of course). (It also allows other cross-procedural optimizations.) Final code generation obviously has to occur after those optimizations, so it would always be done at bind-time in that scenario. So there wouldn't be any incremental cost to inlining (other than the cost of actually doing it). This wasn't a practical implementation in 1995 (which is why we didn't do it then), but it was always the intended end-game for Janus/Ada. (That code generation can be parallelized, and much of the cost of binding disappears if the code generation is delayed, so on a modern multi-core I wouldn't expect the binding time to grow that much.) Anyway, if I spent less time writing about this implementation and more time creating it, we could see how well it works. ;-) Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-22 22:57 ` Niklas Holsti 2013-06-23 3:26 ` Dennis Lee Bieber @ 2013-06-23 12:28 ` Robert A Duff 2013-06-24 20:20 ` Randy Brukardt 1 sibling, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-23 12:28 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > Maybe my post was unclear: I tried to contradict Bob Duff's recollection > that an opaque type in Modula-2 is more like an Ada private type than > like an "stt access type". I think that a Modula-2 opaque type is very > similar to an "stt access type". Do you agree with me? Yes, given your quotes from Wirth, I agree that Modula-2 opaque types are much like stt access types. I had remembered the restriction differently: the type was required to fit in the size of a pointer, which included integers and enums and small records. Probably the Modula-2 compiler I used had a nonstandard extension -- or else I am misremembering. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-23 12:28 ` Robert A Duff @ 2013-06-24 20:20 ` Randy Brukardt 2013-06-24 21:40 ` Niklas Holsti 0 siblings, 1 reply; 54+ messages in thread From: Randy Brukardt @ 2013-06-24 20:20 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccr4ftko44.fsf@shell01.TheWorld.com... > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> Maybe my post was unclear: I tried to contradict Bob Duff's recollection >> that an opaque type in Modula-2 is more like an Ada private type than >> like an "stt access type". I think that a Modula-2 opaque type is very >> similar to an "stt access type". Do you agree with me? > > Yes, given your quotes from Wirth, I agree that Modula-2 opaque types > are much like stt access types. I had remembered the restriction > differently: the type was required to fit in the size of a pointer, > which included integers and enums and small records. Probably the > Modula-2 compiler I used had a nonstandard extension -- or else I am > misremembering. My recollection matches yours, Bob. Perhaps the rule was changed in later versions of the language. In any case, the Modula-2 obaque type is *not* a pointer type, so in that sense it is much more like an Ada private type than an access type of any sort. (I.e., I don't buy this analogy, especially as there isn't any such thing as an stt-access-type -- the operative thing is an stt-incomplete-type, which is nothing like a Modula-2 opaque type. The access type is completely normal, its the designated object that's special.) Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 20:20 ` Randy Brukardt @ 2013-06-24 21:40 ` Niklas Holsti 2013-06-25 0:43 ` Robert A Duff 2013-06-25 19:19 ` Randy Brukardt 0 siblings, 2 replies; 54+ messages in thread From: Niklas Holsti @ 2013-06-24 21:40 UTC (permalink / raw) On 13-06-24 23:20 , Randy Brukardt wrote: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wccr4ftko44.fsf@shell01.TheWorld.com... >> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >> >>> Maybe my post was unclear: I tried to contradict Bob Duff's recollection >>> that an opaque type in Modula-2 is more like an Ada private type than >>> like an "stt access type". I think that a Modula-2 opaque type is very >>> similar to an "stt access type". Do you agree with me? >> >> Yes, given your quotes from Wirth, I agree that Modula-2 opaque types >> are much like stt access types. Good (but I don't know if my quote is from Wirth; it was from the web page I cited). >> I had remembered the restriction >> differently: the type was required to fit in the size of a pointer, >> which included integers and enums and small records. That seems likely to create program-portability problems - on a 64-bit machine, a 64-bit record could be opaque, but it could not be opaque on a 32-bit machine (unless all pointers are artificially made 64 bits wide, too). >> Probably the >> Modula-2 compiler I used had a nonstandard extension -- or else I am >> misremembering. > > My recollection matches yours, Bob. Perhaps the rule was changed in later > versions of the language. The Wikipedia entry on Modula-2 refers to several dialects of Modula-2, of which the "PIM" dialect (from the book "Programming in Modula-2") is one. The rules for opaque types do seem to vary between dialects; for example, the site http://freepages.modula2.org/report4/modula-2.html#SEC43 says: "Opaque export is restricted to pointers and to subranges of standard types." > In any case, the Modula-2 obaque type is *not* a > pointer type, so in that sense it is much more like an Ada private type than > an access type of any sort. I can agree, if we consider only the user's point of view. Both opaque types and stt-access-types are declared as private -- the user (client) does not see their structure or nature. However, even for the more permissive Modula-2 dialects, for example the one quoted earlier in this post, I would guess that most cases of opaque types in practice use pointers, to avoid the size restrictions. The main difference is that in Ada, the unknown underlying type is named -- what you call the stt-incomplete type. This type is of course invisible to the users (clients) of the private type. Off hand, it does not seem to me that such named-but-incomplete types should cause hard problems for the compiler, but it appears that you have experienced such problems. Perhaps they did not exist in Ada 83, but came about because of other extensions such as controlled types? > (I.e., I don't buy this analogy, especially as > there isn't any such thing as an stt-access-type -- the operative thing is > an stt-incomplete-type, which is nothing like a Modula-2 opaque type. The > access type is completely normal, its the designated object that's special.) As I have understood it, the private definition of the stt-access-type as an access to the stt-incomplete-type is simply an idiom, or trick, to achieve the same effect as a Modula-2 opaque type, without introducing the new concept "opaque" into Ada. That it gives a name to the stt-incomplete-type is perhaps unfortunate, from the compiler-writer's point of view. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 21:40 ` Niklas Holsti @ 2013-06-25 0:43 ` Robert A Duff 2013-06-25 19:23 ` Randy Brukardt 2013-06-25 19:19 ` Randy Brukardt 1 sibling, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-06-25 0:43 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > That seems likely to create program-portability problems - on a 64-bit > machine, a 64-bit record could be opaque, but it could not be opaque on > a 32-bit machine (unless all pointers are artificially made 64 bits > wide, too). Yes. I was appalled by that feature for exactly that reason. I'm a big fan of portability. But given the time frame of Modula-2, I think your example should be 16-bit/32-bit not 32/64. ;-) In any case, in plain English, "opaque" doesn't have all these pointer/heap implications, so I suggest saying something like "Modula-2-style opaque types" rather than just "opaque types" if that's what you mean. > The main difference is that in Ada, the unknown underlying type is named > -- what you call the stt-incomplete type. This type is of course > invisible to the users (clients) of the private type. Off hand, it does > not seem to me that such named-but-incomplete types should cause hard > problems for the compiler, but it appears that you have experienced such > problems. Perhaps they did not exist in Ada 83, but came about because > of other extensions such as controlled types? The implementation problems existed in Ada 83. I'm not sure I remember all the issues, but the most obvious is that there's an implicit assumption that you can tell the size/representation of a pointer without knowing what it points at. There are various reasons that might not be true. In fact, it's not true in GNAT. Also, I think it was legal to do "X.all" on those things (in the package spec) in Ada 83. It would always raise Constraint_Error, but the "natural" implementation wants to know the size of X.all. I fixed that in Ada 95 by changing the freezing rules to make it illegal, IIRC. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-25 0:43 ` Robert A Duff @ 2013-06-25 19:23 ` Randy Brukardt 0 siblings, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-25 19:23 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccli5zqat1.fsf@shell01.TheWorld.com... > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> That seems likely to create program-portability problems - on a 64-bit >> machine, a 64-bit record could be opaque, but it could not be opaque on >> a 32-bit machine (unless all pointers are artificially made 64 bits >> wide, too). > > Yes. I was appalled by that feature for exactly that reason. > I'm a big fan of portability. > > But given the time frame of Modula-2, I think your example should be > 16-bit/32-bit not 32/64. ;-) > > In any case, in plain English, "opaque" doesn't have all these > pointer/heap implications, so I suggest saying something like > "Modula-2-style opaque types" rather than just "opaque types" > if that's what you mean. > >> The main difference is that in Ada, the unknown underlying type is named >> -- what you call the stt-incomplete type. This type is of course >> invisible to the users (clients) of the private type. Off hand, it does >> not seem to me that such named-but-incomplete types should cause hard >> problems for the compiler, but it appears that you have experienced such >> problems. Perhaps they did not exist in Ada 83, but came about because >> of other extensions such as controlled types? > > The implementation problems existed in Ada 83. I'm not sure I remember > all the issues, but the most obvious is that there's an implicit > assumption that you can tell the size/representation of a pointer > without knowing what it points at. There are various reasons that might > not be true. In fact, it's not true in GNAT. > > Also, I think it was legal to do "X.all" on those things (in the package > spec) in Ada 83. It would always raise Constraint_Error, but the > "natural" implementation wants to know the size of X.all. I fixed that > in Ada 95 by changing the freezing rules to make it illegal, IIRC. I think there was also an issue with constraints in Ada 83 that was fixed in Ada 95. Note that stt-incomplete types were the basis for the "limited with" feature in Ada 2007, so it's not like the language designers have neglected the feature. (We thought that if stt-incomplete already worked, implementers couldn't complain about limited with - that turned out not to be quite true.) Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-24 21:40 ` Niklas Holsti 2013-06-25 0:43 ` Robert A Duff @ 2013-06-25 19:19 ` Randy Brukardt 1 sibling, 0 replies; 54+ messages in thread From: Randy Brukardt @ 2013-06-25 19:19 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:b2rsmlFpmvmU1@mid.individual.net... > On 13-06-24 23:20 , Randy Brukardt wrote: ... >> In any case, the Modula-2 obaque type is *not* a >> pointer type, so in that sense it is much more like an Ada private type >> than >> an access type of any sort. > > I can agree, if we consider only the user's point of view. Both opaque > types and stt-access-types are declared as private -- the user (client) > does not see their structure or nature. Only the client's point of view matters for both private and opaque types, as inside the package the full views are available. There is nothing of interest to say about private types from inside the package. You're conflating the properties of full view (for opaque types, that's essentially an access-to-stt-incomplete, which of course is a possibility in Ada as well) with the properties of the partial view (which is what the client sees). These views can only be considered separately, as no one can see both. ... > The main difference is that in Ada, the unknown underlying type is named > -- what you call the stt-incomplete type. This type is of course > invisible to the users (clients) of the private type. Off hand, it does > not seem to me that such named-but-incomplete types should cause hard > problems for the compiler, but it appears that you have experienced such > problems. Perhaps they did not exist in Ada 83, but came about because > of other extensions such as controlled types? The real problem is that they're useless (at least for me), especially directly as the full type of a private type. Once you have an explicit access type somewhere, you also have to have explicit memory management. But there is no way to free objects when their objects go away unless the full object is controlled. Which means it is *not* an access type. You have to have a controlled record type in the private part to contain that access-to-stt-incomplete, or you are going to leak memory. And you need to know the size of that record type; ergo, you have to have a private part or something like it. I've tried many times over the years to use an stt-incomplete in the private part of a package (even as an access component of the private type, not the private type itself), but 90% of the time, some issue comes up that has forced me to move the declarations to the private part. I don't even bother to try anymore, it's simply not worth the hassle. Randy. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-06-21 18:36 ` Robert A Duff 2013-06-22 16:41 ` Niklas Holsti @ 2013-07-09 11:24 ` Martin 2013-07-09 14:39 ` Simon Wright ` (2 more replies) 1 sibling, 3 replies; 54+ messages in thread From: Martin @ 2013-07-09 11:24 UTC (permalink / raw) On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote: > Martin <martin@..........com> writes: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Not exactly. Ada "private" means clients can't see it, but child packages (which should be thought of as part of the same abstraction) can. It's a completely different visibility model than UML. I don't see any reason to be embarrassed about that. > Option 2: > type T is tagged record > null; > private > F : Float; > end record; > > > I prefer Option 2. > > Thoughts? I don't think making Ada more like UML is a worthwhile goal. If it were, I'd prefer your option 1. But I don't see the point: In Ada, packages are about visibility. That's different from languages that conflate the concept of "module" and "type" (which has both advantages and disadvantages). Overall, I prefer the Ada way. If you want derived types to see their parent types components, you put the derived types in a child package; if you don't, then you don't. Attempts to mimic UML in Ada lead to a mess, as you've shown. I share your disdain for what you called "opaque" types -- it forces you into heap management, which leads to extra trouble. But I object to calling them "opaque" types. Ada folks usually call them "stt access types" and "stt incomplete types", or "Taft amendment types", because they were invented by Tucker Taft and added to Ada 83 at the last minute when nobody realized all the headaches they cause for compiler writers. The term "opaque type" comes from Modula-2, IIRC, and is more like an Ada private type, with some annoying restrictions added. - Bob Back from holiday...I'll leave all the Modula-2 discussion well alone. I was just using "opaque" in the English dictionary definition sense - no implication of links to other languages implied...but thanks for the background! I hindsight, all the recent changes to Ada-syntax style probably does favour Option 1. Anyway, the keyword in the topic was "easy" - perhaps I should have written it in ALL-CAPS :-) There are current options of how to achieve UML-like private-ness but all are clunky and some are horrific and, given their access-types not available for safety-critical systems (where coding standard still often forbid such usage). As to making Ada more UML-like, that's not really my goal...but I'd certainly like to make common UML constructs easy to achieve in Ada. It's a topic I've raised at various conferences for 10 years or more. I had hoped a standard UML <-> Ada mapping could be agreed between the UML & Ada compiler tool vendors; certainly they all gave positive responses to such a move all those years ago. They all had company's developing their own Stereotype/Tag UML<->Ada solutions, so all saw this wheel being re-invented year after year, company after company. Sadly, I expect the companies who were re-inventing these wheels, saw their work as "IP" and not to be shared with the wider community. Opportunity lost. Interest has been raised in UML/Ada recently but sadly the current state-of-the-art is not as mature as the current UML/Java or UML/C++...and I live in a MDA focused s/w dept, where UML is a must and where auto-code generation is much used. NB: Lots of recent s/w grads seem to be literal in only in UML + Java...it have become, for better or for worse, a UML world. -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-09 11:24 ` Martin @ 2013-07-09 14:39 ` Simon Wright 2013-07-10 7:03 ` Martin 2013-07-09 21:43 ` Robert A Duff 2013-07-10 16:12 ` Simon Wright 2 siblings, 1 reply; 54+ messages in thread From: Simon Wright @ 2013-07-09 14:39 UTC (permalink / raw) Martin <martin@thedowies.com> writes: Hi Martin! > On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote: [stuff that Google Groups mangled even more horrifically than usual!] > There are current options of how to achieve UML-like private-ness but > all are clunky and some are horrific and, given their access-types not > available for safety-critical systems (where coding standard still > often forbid such usage). Given that the UML private/protected distinction is only relevant to inheritance, I'd have thought it would be irrelevant to safety-critical systems! Rational Rose used to have the additional visibility "implementation". I took this to mean the same as "private" (and "protected"). > As to making Ada more UML-like, that's not really my goal...but I'd > certainly like to make common UML constructs easy to achieve in Ada. I have to ask, why? We have profiles to state what UML constructs will have meaning in the translation, and what that meaning will be. Other constructs - well, I'd forbid them on the grounds that no two team members will have the same opinion as to what they mean, and they'll probably get translated (if at all) into something different again. > I had hoped a standard UML <-> Ada mapping could be agreed between the > UML & Ada compiler tool vendors; certainly they all gave positive > responses to such a move all those years ago. They all had company's > developing their own Stereotype/Tag UML<->Ada solutions, so all saw > this wheel being re-invented year after year, company after company. Always seemed to me that people went overboard with that; why did they feel the need to stereotype a class «Ada:Task» when it could just be marked _active_? (actually, there is a reason for using a stereotype, which is that tags are associated with stereotypes, and you'll need tags for {priority} and {stack}; but why not use plain «active»?). > Interest has been raised in UML/Ada recently Oh, where? ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-09 14:39 ` Simon Wright @ 2013-07-10 7:03 ` Martin 0 siblings, 0 replies; 54+ messages in thread From: Martin @ 2013-07-10 7:03 UTC (permalink / raw) On Tuesday, July 9, 2013 3:39:22 PM UTC+1, Simon Wright wrote: > [stuff that Google Groups mangled even more horrifically than usual!] It really is mangling stuff up...might be this PC... > Given that the UML private/protected distinction is only relevant to > inheritance, I'd have thought it would be irrelevant to safety-critical > systems! Depends on what you can agree with your IV&V. > I have to ask, why? We have profiles to state what UML constructs will > have meaning in the translation, and what that meaning will be. Other > constructs - well, I'd forbid them on the grounds that no two team > members will have the same opinion as to what they mean, and they'll > probably get translated (if at all) into something different again. But currently we have no *standard* profiles...but we do have various in-house company profiles that are *very* similar. > Always seemed to me that people went overboard with that; why did they > feel the need to stereotype a class «Ada:Task» when it could just be > marked _active_? (actually, there is a reason for using a stereotype, > which is that tags are associated with stereotypes, and you'll need > tags for {priority} and {stack}; but why not use plain «active»?). I see what you mean...everything single thing tended to have a stereotype. I think now we'll see a bit of that again (if we get UML tools to support Ada2012!), with everything having an "aspect" stereotype/tag!! :-) > Interest has been raised in UML/Ada recently Oh, where? Here! Old projects never die...they just get re-hosted...and updated! :-) -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-09 11:24 ` Martin 2013-07-09 14:39 ` Simon Wright @ 2013-07-09 21:43 ` Robert A Duff 2013-07-10 6:34 ` Martin 2013-07-10 16:12 ` Simon Wright 2 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 2013-07-09 21:43 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > NB: Lots of recent s/w grads seem to be literal in only in UML + Java... Whereas in Ada, they are figurative? ;-) ;-) - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-09 21:43 ` Robert A Duff @ 2013-07-10 6:34 ` Martin 2013-07-10 8:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 54+ messages in thread From: Martin @ 2013-07-10 6:34 UTC (permalink / raw) On Tuesday, July 9, 2013 10:43:34 PM UTC+1, Robert A Duff wrote: > Martin <martin@thedowies.com> writes: > NB: Lots of recent s/w grads seem to be literal in only in UML + Java... Whereas in Ada, they are figurative? ;-) ;-) - Bob Not even... ;-( ;-( -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-10 6:34 ` Martin @ 2013-07-10 8:24 ` Dmitry A. Kazakov 2013-07-10 13:06 ` Martin 0 siblings, 1 reply; 54+ messages in thread From: Dmitry A. Kazakov @ 2013-07-10 8:24 UTC (permalink / raw) On Tue, 9 Jul 2013 23:34:51 -0700 (PDT), Martin wrote: > On Tuesday, July 9, 2013 10:43:34 PM UTC+1, Robert A Duff wrote: >> Martin <martin@thedowies.com> writes: >> NB: Lots of recent s/w grads seem >> to be literal in only in UML + Java... Whereas in Ada, they are >> figurative? ;-) ;-) - Bob > > Not even... ;-( ;-( We are asking applicants to write a program that tests if a given bit in a byte is set. More than *half* of them fail. Quarter of the rest write a loop... P.S. It is not a joke, so there is no smiley. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-10 8:24 ` Dmitry A. Kazakov @ 2013-07-10 13:06 ` Martin 0 siblings, 0 replies; 54+ messages in thread From: Martin @ 2013-07-10 13:06 UTC (permalink / raw) On Wednesday, July 10, 2013 9:24:11 AM UTC+1, Dmitry A. Kazakov wrote: > We are asking applicants to write a program that tests if a given bit in a byte > is set. More than *half* of them fail. Quarter of the rest write a loop... And writing a loop to do it _isn't_ a fail?!?! :-O -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-09 11:24 ` Martin 2013-07-09 14:39 ` Simon Wright 2013-07-09 21:43 ` Robert A Duff @ 2013-07-10 16:12 ` Simon Wright 2013-07-10 18:22 ` Martin 2 siblings, 1 reply; 54+ messages in thread From: Simon Wright @ 2013-07-10 16:12 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > There are current options of how to achieve UML-like private-ness but > all are clunky and some are horrific and, given their access-types not > available for safety-critical systems (where coding standard still > often forbid such usage). If you were doing full translation you could implement UML private vs protected at the translation stage. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-10 16:12 ` Simon Wright @ 2013-07-10 18:22 ` Martin 2013-07-10 19:41 ` Simon Wright 0 siblings, 1 reply; 54+ messages in thread From: Martin @ 2013-07-10 18:22 UTC (permalink / raw) That's fine for one half the equation (implementing the "private" using one if the techniques mentioned before) but it still leaves using the "private" components...that's still a mess (my description!) isn't it? -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-10 18:22 ` Martin @ 2013-07-10 19:41 ` Simon Wright 2013-07-11 18:28 ` Martin 0 siblings, 1 reply; 54+ messages in thread From: Simon Wright @ 2013-07-10 19:41 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > That's fine for one half the equation (implementing the "private" > using one if the techniques mentioned before) but it still leaves > using the "private" components...that's still a mess (my description!) > isn't it? I was thinking that for full code gen the translator could say "this operation in the child class is trying to access a private attribute of the parent! No!" and report a translation error. Clearly not possible for framework-only generators. My ColdFrame[1] (a) declares the instance record in the private part of the class package, regardless of what you put in the model, (b) supports provision of «accessor» operations, and (c) implements inheritance using its own mechanisms rather than via tagged types; so "public" attributes are those given accessors by the modeller, all others are "private". I could automatically generate accessors for attributes marked "public", but I think that people should be made to work a bit to get access to instance variables of other classes! [1] https://sourceforge.net/projects/coldframe/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-10 19:41 ` Simon Wright @ 2013-07-11 18:28 ` Martin 2013-07-11 19:37 ` Simon Wright 0 siblings, 1 reply; 54+ messages in thread From: Martin @ 2013-07-11 18:28 UTC (permalink / raw) Sadly, our current UML tool comes with some strange defaults out-the-box, such that if you don't override the code-gen properties early (and preferably at top of model level) then all attributes are (C++) protected and not the visibly you selected for the attribute. And the visibility you selected for the attribute becomes the visibility of the set/get operations...ie what you see (on a Class Diagram) is _not_ what you get in the code!!! Horrific...and non-Do-178B (/C) compliant!! -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-11 18:28 ` Martin @ 2013-07-11 19:37 ` Simon Wright 2013-07-11 20:43 ` Martin 0 siblings, 1 reply; 54+ messages in thread From: Simon Wright @ 2013-07-11 19:37 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > Sadly, our current UML tool comes with some strange defaults > out-the-box, such that if you don't override the code-gen properties > early (and preferably at top of model level) then all attributes are > (C++) protected and not the visibly you selected for the > attribute. And the visibility you selected for the attribute becomes > the visibility of the set/get operations...ie what you see (on a Class > Diagram) is _not_ what you get in the code!!! Horrific...and > non-Do-178B (/C) compliant!! Do you mean that it generates setters/getters for all the instance variables? Evil! (and pointless, given what you say about the accessor visibilities; why not just generate the attributes as required?) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-11 19:37 ` Simon Wright @ 2013-07-11 20:43 ` Martin 2013-07-12 6:57 ` Simon Wright 0 siblings, 1 reply; 54+ messages in thread From: Martin @ 2013-07-11 20:43 UTC (permalink / raw) Yes, but I'd rather go through set/get - direct access to attributes is content coupling...that's evil!! :-) and they're useful for breakpoints etc to see which call stack is setting a particular value... ...the other big problem, is that what you see on a OMD or CD wrt visibilties is not what you get in the code. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-11 20:43 ` Martin @ 2013-07-12 6:57 ` Simon Wright 2013-07-12 8:05 ` Martin 0 siblings, 1 reply; 54+ messages in thread From: Simon Wright @ 2013-07-12 6:57 UTC (permalink / raw) Martin <martin@thedowies.com> writes: > Yes, but I'd rather go through set/get - direct access to attributes > is content coupling...that's evil!! :-) and they're useful for > breakpoints etc to see which call stack is setting a particular > value... > > ...the other big problem, is that what you see on a OMD or CD wrt > visibilties is not what you get in the code. I would have thought it'd make more sense to provide accessors for the public attributes (and not for the others) while keeping the public attributes themselves private (protected?), since derived(?) classes _should_ be able to see the protected attributes? But, that said, it doesn't seem unreasonable to map the model's attribute visibilities to accessor visibilities. What else should you do? ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Ada202X: Easy to use "UML private"-like components 2013-07-12 6:57 ` Simon Wright @ 2013-07-12 8:05 ` Martin 0 siblings, 0 replies; 54+ messages in thread From: Martin @ 2013-07-12 8:05 UTC (permalink / raw) On Friday, July 12, 2013 7:57:28 AM UTC+1, Simon Wright wrote: > I would have thought it'd make more sense to provide accessors for the > public attributes (and not for the others) while keeping the public > attributes themselves private (protected?), since derived(?) classes > _should_ be able to see the protected attributes? But, that said, it > doesn't seem unreasonable to map the model's attribute visibilities to > accessor visibilities. What else should you do? Exactly...esp as both attributes & their set/get can each have their own visibility...and you can see those on any OMD...why would you *not* reflect them as-is in the code?... My assumption is that the out-the-box behaviour is lost in the mists of time but they can't change it without being non-backwards compatible. I guess it's a little like having to remember "-gnato" ;-) -- Martin ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2013-07-12 8:05 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-21 8:43 Ada202X: Easy to use "UML private"-like components Martin 2013-06-21 9:23 ` Dmitry A. Kazakov 2013-06-21 9:33 ` Martin 2013-06-21 10:14 ` G.B. 2013-06-21 11:19 ` Martin 2013-06-21 14:51 ` Dmitry A. Kazakov 2013-06-22 11:16 ` Martin 2013-06-22 12:10 ` Dmitry A. Kazakov 2013-06-21 18:36 ` Robert A Duff 2013-06-22 16:41 ` Niklas Holsti 2013-06-22 19:05 ` Dennis Lee Bieber 2013-06-22 22:57 ` Niklas Holsti 2013-06-23 3:26 ` Dennis Lee Bieber 2013-06-23 7:32 ` Niklas Holsti 2013-06-23 13:12 ` Robert A Duff 2013-06-23 14:06 ` Dmitry A. Kazakov 2013-06-23 15:15 ` Robert A Duff 2013-06-23 18:52 ` Dmitry A. Kazakov 2013-06-23 23:38 ` Robert A Duff 2013-06-24 7:16 ` Dmitry A. Kazakov 2013-06-24 20:11 ` Randy Brukardt 2013-06-25 7:21 ` Dmitry A. Kazakov 2013-06-25 19:06 ` Randy Brukardt 2013-06-24 20:07 ` Randy Brukardt 2013-06-23 14:40 ` Shark8 2013-06-23 15:28 ` Robert A Duff 2013-06-23 18:14 ` Bill Findlay 2013-06-23 23:43 ` Robert A Duff 2013-06-23 23:48 ` Bill Findlay 2013-06-24 20:16 ` Randy Brukardt 2013-06-24 20:05 ` Randy Brukardt 2013-06-25 1:09 ` Robert A Duff 2013-06-25 19:37 ` Randy Brukardt 2013-06-23 12:28 ` Robert A Duff 2013-06-24 20:20 ` Randy Brukardt 2013-06-24 21:40 ` Niklas Holsti 2013-06-25 0:43 ` Robert A Duff 2013-06-25 19:23 ` Randy Brukardt 2013-06-25 19:19 ` Randy Brukardt 2013-07-09 11:24 ` Martin 2013-07-09 14:39 ` Simon Wright 2013-07-10 7:03 ` Martin 2013-07-09 21:43 ` Robert A Duff 2013-07-10 6:34 ` Martin 2013-07-10 8:24 ` Dmitry A. Kazakov 2013-07-10 13:06 ` Martin 2013-07-10 16:12 ` Simon Wright 2013-07-10 18:22 ` Martin 2013-07-10 19:41 ` Simon Wright 2013-07-11 18:28 ` Martin 2013-07-11 19:37 ` Simon Wright 2013-07-11 20:43 ` Martin 2013-07-12 6:57 ` Simon Wright 2013-07-12 8:05 ` Martin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox