* Self pointer in limited record @ 2007-07-04 19:31 Maciej Sobczak 2007-07-05 8:22 ` Dmitry A. Kazakov 2007-08-31 16:47 ` amado.alves 0 siblings, 2 replies; 65+ messages in thread From: Maciej Sobczak @ 2007-07-04 19:31 UTC (permalink / raw) Consider: type T_Access is access all T; type T is new Ada.Finalization.Limited_Controlled with record Self : T_Access := T'Unchecked_Access; -- more components -- ... end record; I have seen this pattern repeatedly. What is the use for Self? And why is it Unchecked? -- Maciej Sobczak http://www.msobczak.com/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-04 19:31 Self pointer in limited record Maciej Sobczak @ 2007-07-05 8:22 ` Dmitry A. Kazakov 2007-07-05 10:35 ` Maciej Sobczak 2007-08-31 16:47 ` amado.alves 1 sibling, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-07-05 8:22 UTC (permalink / raw) On Wed, 04 Jul 2007 12:31:08 -0700, Maciej Sobczak wrote: > Consider: > > type T_Access is access all T; > type T is new Ada.Finalization.Limited_Controlled with record > Self : T_Access := T'Unchecked_Access; > -- more components > -- ... > end record; > > I have seen this pattern repeatedly. What is the use for Self? The pattern (also called Rosen trick) is used: 1. to having mutable arguments of functions: function Search (X : T; K : Key) return Value is Object : T renames X.Self.all; begin ... -- Modify the search cache associated with X via -- mutable Object view 2. to re-dispatch from primitive operations: type T_Access is access all T'Class; -- Note 'Class type T is new Ada.Finalization.Limited_Controlled with record Self : T_Access := T'Unchecked_Access; procedure Bar (X : T); -- Primitive procedure Foo (X : T); -- Primitive procedure Foo (X : T) is Object : T'Class renames X.Self.all; begin Bar (X); -- This does not dispatch! Bar (Object.Self.all); -- This dispatches Bar (T'Class (X)); -- This dispatches as well The later (view conversion) should better be removed from the language, so I always prefer Rosen trick for such purpose. Both defeat the type system in some sense and potentially indicate a design problem. > And why is it Unchecked? Because of accessibility rules. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-05 8:22 ` Dmitry A. Kazakov @ 2007-07-05 10:35 ` Maciej Sobczak 2007-07-05 11:01 ` Pascal Obry ` (2 more replies) 0 siblings, 3 replies; 65+ messages in thread From: Maciej Sobczak @ 2007-07-05 10:35 UTC (permalink / raw) On 5 Lip, 10:22, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > What is the use for Self? > > The pattern (also called Rosen trick) is used: That's cheating - I was told there are no tricks in Ada! ;-) > 1. to having mutable arguments of functions: > > function Search (X : T; K : Key) return Value is > Object : T renames X.Self.all; > begin > ... -- Modify the search cache associated with X via > -- mutable Object view OK, makes sense. I have seen it used with rendezvous and I guess the motivation was similar. > 2. to re-dispatch from primitive operations: > > type T_Access is access all T'Class; -- Note 'Class > type T is new Ada.Finalization.Limited_Controlled with record > Self : T_Access := T'Unchecked_Access; > > procedure Bar (X : T); -- Primitive > procedure Foo (X : T); -- Primitive > > procedure Foo (X : T) is > Object : T'Class renames X.Self.all; > begin > Bar (X); -- This does not dispatch! > Bar (Object.Self.all); -- This dispatches I guess Bar (Object) should be enough? Yes, it makes sense as well. > Both defeat the type system in some sense and potentially indicate a > design problem. I have seen it applied *regularly* in some Ada project, so it looked like "default" idiom for OO programming. > > And why is it Unchecked? > > Because of accessibility rules. You mean - the access type is defined in the same scope as the record and there is a potential danger that the access component in the record can point to some other record that may disappear leading to dangling pointer? Thank you for explanation. -- Maciej Sobczak http://www.msobczak.com/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-05 10:35 ` Maciej Sobczak @ 2007-07-05 11:01 ` Pascal Obry 2007-07-05 11:14 ` Georg Bauhaus 2007-07-05 12:36 ` Dmitry A. Kazakov 2 siblings, 0 replies; 65+ messages in thread From: Pascal Obry @ 2007-07-05 11:01 UTC (permalink / raw) To: Maciej Sobczak Maciej Sobczak a �crit : > You mean - the access type is defined in the same scope as the record > and there is a potential danger that the access component in the > record can point to some other record that may disappear leading to > dangling pointer? I have not tested but I would expect Ada 2005 anonymous access type to work nicely here (removing the need for Unchecked_Access): type T is new Ada.Finalization.Limited_Controlled with record Self : access T := T'Access; Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-05 10:35 ` Maciej Sobczak 2007-07-05 11:01 ` Pascal Obry @ 2007-07-05 11:14 ` Georg Bauhaus 2007-07-05 12:36 ` Dmitry A. Kazakov 2 siblings, 0 replies; 65+ messages in thread From: Georg Bauhaus @ 2007-07-05 11:14 UTC (permalink / raw) On Thu, 2007-07-05 at 03:35 -0700, Maciej Sobczak wrote: > On 5 Lip, 10:22, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > OK, makes sense. I have seen it used with rendezvous and I guess the > motivation was similar. > > > 2. to re-dispatch from primitive operations: > > > > type T_Access is access all T'Class; -- Note 'Class > > type T is new Ada.Finalization.Limited_Controlled with record > > Self : T_Access := T'Unchecked_Access; > > > > Both defeat the type system in some sense and potentially indicate a > > design problem. > > I have seen it applied *regularly* in some Ada project, so it looked > like "default" idiom for OO programming. Hm, is this because programmers have liked to be able to manipulate the object not via its interfaces and proper command/query separation, but instead via direct access provided by a this/self-pointer? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-05 10:35 ` Maciej Sobczak 2007-07-05 11:01 ` Pascal Obry 2007-07-05 11:14 ` Georg Bauhaus @ 2007-07-05 12:36 ` Dmitry A. Kazakov 2 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-07-05 12:36 UTC (permalink / raw) On Thu, 05 Jul 2007 03:35:54 -0700, Maciej Sobczak wrote: > On 5 Lip, 10:22, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >> 2. to re-dispatch from primitive operations: >> >> type T_Access is access all T'Class; -- Note 'Class >> type T is new Ada.Finalization.Limited_Controlled with record >> Self : T_Access := T'Unchecked_Access; >> >> procedure Bar (X : T); -- Primitive >> procedure Foo (X : T); -- Primitive >> >> procedure Foo (X : T) is >> Object : T'Class renames X.Self.all; >> begin >> Bar (X); -- This does not dispatch! >> Bar (Object.Self.all); -- This dispatches > > I guess Bar (Object) should be enough? Yes, of course. I was typing is faster than thinking... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-07-04 19:31 Self pointer in limited record Maciej Sobczak 2007-07-05 8:22 ` Dmitry A. Kazakov @ 2007-08-31 16:47 ` amado.alves 2007-08-31 17:09 ` Pascal Obry ` (3 more replies) 1 sibling, 4 replies; 65+ messages in thread From: amado.alves @ 2007-08-31 16:47 UTC (permalink / raw) On 4 Jul, 20:31, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > Consider: > > type T_Access is access all T; > type T is new Ada.Finalization.Limited_Controlled with record > Self: T_Access := T'Unchecked_Access; > -- more components > -- ... > end record; > > I have seen this pattern repeatedly. Then you have seen illegal Ada code repeatedly. I wish this were possible myself. Or more simply: type T is -- limited or not Self : access T := T'Unchecked_Access; ... end; But the compiler will remind you that Unchecked_Access is not available for types. (It seems Ada is like most women: unnecessarily complicated and difficult :-) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 16:47 ` amado.alves @ 2007-08-31 17:09 ` Pascal Obry 2007-08-31 17:37 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 0 replies; 65+ messages in thread From: Pascal Obry @ 2007-08-31 17:09 UTC (permalink / raw) To: amado.alves amado.alves@gmail.com a �crit : > On 4 Jul, 20:31, Maciej Sobczak <see.my.homep...@gmail.com> wrote: >> Consider: >> >> type T_Access is access all T; >> type T is new Ada.Finalization.Limited_Controlled with record >> Self: T_Access := T'Unchecked_Access; >> -- more components >> -- ... >> end record; >> >> I have seen this pattern repeatedly. > > Then you have seen illegal Ada code repeatedly. I wish this were > possible myself. Or more simply: No this is possible. It is called auto-pointer if I remember correctly and quite useful. See the corresponding thread. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 16:47 ` amado.alves 2007-08-31 17:09 ` Pascal Obry @ 2007-08-31 17:37 ` Adam Beneschan 2007-08-31 18:26 ` Jeffrey R. Carter 2007-08-31 19:33 ` Dmitry A. Kazakov 3 siblings, 0 replies; 65+ messages in thread From: Adam Beneschan @ 2007-08-31 17:37 UTC (permalink / raw) On Aug 31, 9:47 am, amado.al...@gmail.com wrote: > On 4 Jul, 20:31, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > > > Consider: > > > type T_Access is access all T; > > type T is new Ada.Finalization.Limited_Controlled with record > > Self: T_Access := T'Unchecked_Access; > > -- more components > > -- ... > > end record; > > > I have seen this pattern repeatedly. > > Then you have seen illegal Ada code repeatedly. I wish this were > possible myself. Or more simply: > > type T is -- limited or not > Self : access T := T'Unchecked_Access; > ... > end; > > But the compiler will remind you that Unchecked_Access is not > available for types. No, this can be legal. Normally, you can't apply 'Unchecked_Access to a type name. But within the definition of a type T, the use of T in a context like this refers to the "current instance"; that is, it will refer to whatever object is declared with that type. So if you later declare "X : T;", then the T in T'Unchecked_Access will be replaced by X for that declaration (and X.Self will thus point to X). See 8.6(17). However, it's only legal if T is limited (in Ada 2005, the rule is slightly more restrictive), because 'Unchecked_Access can only be applied to an aliased entity, and 3.10(9) says that the current instance of a *limited* type is defined to be aliased. -- Adam ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 16:47 ` amado.alves 2007-08-31 17:09 ` Pascal Obry 2007-08-31 17:37 ` Adam Beneschan @ 2007-08-31 18:26 ` Jeffrey R. Carter 2007-08-31 19:33 ` Dmitry A. Kazakov 3 siblings, 0 replies; 65+ messages in thread From: Jeffrey R. Carter @ 2007-08-31 18:26 UTC (permalink / raw) amado.alves@gmail.com wrote: > > type T is -- limited or not > Self : access T := T'Unchecked_Access; > ... > end; > > But the compiler will remind you that Unchecked_Access is not > available for types. > (It seems Ada is like most women: unnecessarily complicated and > difficult :-) What I have had occasion to use successfully is type R; task type TT (Parent : access R); type R is new Ada.Finalization.Limited_Controlled with record T : TT (Parent => R'access); ... end record; V : R; V.T.Parent designates V. Some points for this idiom: R must be limited, because it contains a limited component (the task). "The current instance of a limited tagged type, a protected type, a task type, or a type that has the reserved word limited in its full definition is also defined to be aliased." (ARM 3.10). This sort of thing may not work if R is not one of these cases (and so the current instance referred to by R in R'access is aliased); I haven't tried it. I usually have done this when revising others' existing code; there generally seem better designs when starting from scratch. -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 16:47 ` amado.alves ` (2 preceding siblings ...) 2007-08-31 18:26 ` Jeffrey R. Carter @ 2007-08-31 19:33 ` Dmitry A. Kazakov 2007-09-01 13:33 ` Georg Bauhaus 2007-09-08 1:16 ` Randy Brukardt 3 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-08-31 19:33 UTC (permalink / raw) On Fri, 31 Aug 2007 16:47:29 -0000, amado.alves@gmail.com wrote: > Then you have seen illegal Ada code repeatedly. I wish this were > possible myself. Or more simply: > > type T is -- limited or not > Self : access T := T'Unchecked_Access; > ... > end; T cannot be non-limited, because otherwise passing it by copy would make rubbish out of Self. In any case it would make little sense if not access T'Class. -------------- There is an interesting illegal case of objects bound to a specific storage pool: type T is tagged limited private; private type T_Ptr is access T'Class; for T_Ptr'Storage_Pool use ...; type T is tagged limited record Self : T_Ptr := T'Unchecked_Access; -- Illegal end record; The language requires T_Ptr to be a general access type no matter what. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 19:33 ` Dmitry A. Kazakov @ 2007-09-01 13:33 ` Georg Bauhaus 2007-09-01 13:46 ` Dmitry A. Kazakov 2007-09-08 1:16 ` Randy Brukardt 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-01 13:33 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Fri, 31 Aug 2007 16:47:29 -0000, amado.alves@gmail.com wrote: > >> Then you have seen illegal Ada code repeatedly. I wish this were >> possible myself. Or more simply: >> >> type T is -- limited or not >> Self : access T := T'Unchecked_Access; >> ... >> end; > > T cannot be non-limited, because otherwise passing it by copy would make > rubbish out of Self. In any case it would make little sense if not access > T'Class. I think there is an interesting use of a .Self pointer of simple limited records with state variables of packages. Say a procedure in a package P controls the state of some variable in the package's body. The state variable is of type access T, where T is a limited record type declared in P. The purpose of the state variable is to remember the object of type T that will be the target of subsequent package operations. A natural way to remember a particular object is to point to the object. But package clients should not have to worry about this pointing mechanism. So the package shouldn't declare a public access type used for internal mechanism only. Instead there is a procedure of one T argument that can be called by clients when they want to indicate the object to be used in subsequent P operations. This is where .Self can be used. We cannot take 'Access or 'Unchecked_Access of subprogram arguments unless they are aliased (such as those of type T'Class). But the .Self component of the subprogram's argument supplies the access value that is needed for storing a pointer to the argument in the package body. package P is type T is limited private; procedure Choose (Selected: in out T); -- sets target T for subsequent operations procedure Work; private type Bits is array(0 .. 15) of Boolean; type T_Access is access all T; type T is limited record Self: T_Access := T'unchecked_access; Slots: Bits; end record; end P; package body P is Current: T_Access; -- state variable, target object procedure Choose (Selected: in out T) is begin Current := Selected.Self; -- here end Choose; procedure Work is begin Current.Slots(3) := not Current.Slots(3); end Work; end P; (The true O-O programmer might suggest that we should simply pass an additional object-as-module parameter to every package subprogram... ) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 13:33 ` Georg Bauhaus @ 2007-09-01 13:46 ` Dmitry A. Kazakov 2007-09-01 14:15 ` Georg Bauhaus 2007-09-01 15:33 ` Markus E L 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-01 13:46 UTC (permalink / raw) On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: > (The true O-O programmer might suggest that we should simply > pass an additional object-as-module parameter to every > package subprogram... ) Yes, it is better to keep packages stateless. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 13:46 ` Dmitry A. Kazakov @ 2007-09-01 14:15 ` Georg Bauhaus 2007-09-01 16:03 ` Dmitry A. Kazakov 2007-09-01 15:33 ` Markus E L 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-01 14:15 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: > >> (The true O-O programmer might suggest that we should simply >> pass an additional object-as-module parameter to every >> package subprogram... ) > > Yes, it is better to keep packages stateless. Though by using tagged objects for a module and not a stateful package, you will dismiss a few properties of packages that can be helpful when modeling singleton modules: 1 - If there is just one object in the problem domain a package is a perfect match and will be straight forward, safe, and simple to implement. No need to worry about static and dynamic scopes of module-objects passed around because there is just this one named package for the problem domain object. 2 - Nesting packages is an option, a distinguishing feature of Ada IMO; a package nested inside a subprogram is a simple solution to the life cycle problem of module style objects. For example, when a singleton object is needed only while a subprogram S is executing, why not just create a simple package within S, that is, right where it is needed, and not anywhere else? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 14:15 ` Georg Bauhaus @ 2007-09-01 16:03 ` Dmitry A. Kazakov 2007-09-01 19:49 ` Georg Bauhaus 2007-09-03 7:54 ` Jean-Pierre Rosen 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-01 16:03 UTC (permalink / raw) On Sat, 01 Sep 2007 16:15:44 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: >> >>> (The true O-O programmer might suggest that we should simply >>> pass an additional object-as-module parameter to every >>> package subprogram... ) >> >> Yes, it is better to keep packages stateless. > > Though by using tagged objects for a module > and not a stateful package, you will dismiss a few > properties of packages that can be helpful when > modeling singleton modules: > > 1 - If there is just one object in the problem domain a > package is a perfect match and will be straight forward, safe, > and simple to implement. No need to worry about static and > dynamic scopes of module-objects passed around because > there is just this one named package for the problem > domain object. Yes, yes, but this is a different case. Dealing with singletons, I probably would use a [stateful] package instead of objects. Types presume multiple instances of. Singleton in OO breaks this concept. Ada offers a cleaner alternative. Why should we force it into a type? Let it be a package. I think the empiric rule could be: if a package is used to declare types, then it should have no mutable state. Otherwise it should not have type declarations. > 2 - Nesting packages is an option, a distinguishing feature > of Ada IMO; a package nested inside a subprogram is a > simple solution to the life cycle problem of module style > objects. Hmm, a subprogram has all properties of a package. So there is no obvious reason why nested package (except instances of generic packages, of course), might be useful there. BTW, I guess child and separate packages might probably replace nested packages. Excluding generics, I mean. Maybe if there were no generic packages we could drop them altogether. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 16:03 ` Dmitry A. Kazakov @ 2007-09-01 19:49 ` Georg Bauhaus 2007-09-01 20:09 ` Dmitry A. Kazakov 2007-09-03 7:54 ` Jean-Pierre Rosen 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-01 19:49 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> 2 - Nesting packages is an option, a distinguishing feature >> of Ada IMO; a package nested inside a subprogram is a >> simple solution to the life cycle problem of module style >> objects. > > Hmm, a subprogram has all properties of a package. So there is no obvious > reason why nested package (except instances of generic packages, of > course), might be useful there. You can have two nested packages, or more. :-) procedure run_a_farm is -- simplified type Sound is (Bow_Wow, Cock_A_Doodle_Doo, Moo, Dinner_is_Ready, Order); BARK : exception; package House is procedure Cook_Meal; procedure Eat; procedure Sleep; procedure Alarm; end House; package Barn is procedure Feed; procedure Milk; procedure Alarm; end Barn; task Events is entry Noise (Kind: Sound); private entry Call_Benjamin (Kind: Sound); end Events; package body House is separate; package body Barn is separate; -- Note: Both House and Barn can make Noise. -- Everyone can react to exceptional BARKing. task body Events is separate; begin Events.Noise (Cock_A_Doodle_Doo); end run_a_farm; ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 19:49 ` Georg Bauhaus @ 2007-09-01 20:09 ` Dmitry A. Kazakov 2007-09-02 21:37 ` Georg Bauhaus 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-01 20:09 UTC (permalink / raw) On Sat, 01 Sep 2007 21:49:52 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >>> 2 - Nesting packages is an option, a distinguishing feature >>> of Ada IMO; a package nested inside a subprogram is a >>> simple solution to the life cycle problem of module style >>> objects. >> >> Hmm, a subprogram has all properties of a package. So there is no obvious >> reason why nested package (except instances of generic packages, of >> course), might be useful there. > > You can have two nested packages, or more. :-) If you don't need a single, why would you two? Packages are to bind together coupled reusable things. A package within an implementation cannot serve this purpose. Your example with a farm should better be a container type with house and barn being objects. Farms can have two or more barns. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 20:09 ` Dmitry A. Kazakov @ 2007-09-02 21:37 ` Georg Bauhaus [not found] ` <re7ei5lc7dzf$.11qtcnh35jmzg$.dlg@40tude.net> 0 siblings, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-02 21:37 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Packages are to bind > together coupled reusable things. I agree with "bind together" as a use of packages. But reuse of a package is an optional feature of a package: Suppose every package is reusable. Then most of us will have lost their jobs as programmers because every problem domain object can be mapped to one of the available reusable packages. > A package within an implementation cannot > serve this purpose. Yes. It needn't. > Your example with a farm should better be a container > type with house and barn being objects. Farms can have two or more barns. You can make any program arbitrarily complex. A car has one steering wheel. Why is a simple module (i.e., a package, not a type) inadequate. ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <re7ei5lc7dzf$.11qtcnh35jmzg$.dlg@40tude.net>]
* Re: Self pointer in limited record [not found] ` <re7ei5lc7dzf$.11qtcnh35jmzg$.dlg@40tude.net> @ 2007-09-03 10:51 ` Georg Bauhaus 2007-09-03 14:17 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-03 10:51 UTC (permalink / raw) On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote: > On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote: > > > Suppose every package is reusable. > > That's the goal. Why? > > Then most of us will have > > lost their jobs as programmers because every problem domain > > object can be mapped to one of the available reusable packages. > > False implication. Reusing of every package does not imply that you have a > package for every other thing. To me, not forcing the reuse idea on every package is a much better alternative than having to declare unrelated things in the same declarative part with packages forbidden. Or, alternatively, being forced to construe some artificial types for reasons of formal preference only. The "abstract state machines" kind of package (as opposed to those packages framing an "abstract data type") do work well in Ada program without a type parameter; it doesn't carry any additional information of spectacular use. The idea: When a few very specific things are alive only while a subprogram is executing, then a local package for them is fine (I think you agreed with this singleton style use). They have an interface, the have an implementation, with or without a type declaration. So why add one? Why the heck do I have to defend nesting of packages in the first place? Is it because some popular languages and UML do not usually nest object abstractions inside procedural artifacts? Is it because you do not usually have nesting in C? Is it because GCC (hence GNAT to some extent) was not built knowing there would be locally defined things in languages such as Ada? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 10:51 ` Georg Bauhaus @ 2007-09-03 14:17 ` Dmitry A. Kazakov 2007-09-03 15:55 ` Jean-Pierre Rosen 2007-09-03 20:38 ` Georg Bauhaus 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-03 14:17 UTC (permalink / raw) On Mon, 03 Sep 2007 12:51:14 +0200, Georg Bauhaus wrote: > On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote: >> On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote: >> >>> Suppose every package is reusable. >> >> That's the goal. > > Why? In order to get a better understanding of the problem and solution. > The "abstract state machines" kind of package (as opposed > to those packages framing an "abstract data type") do work well > in Ada program without a type parameter; it doesn't carry > any additional information of spectacular use. It is difficult to see how an abstract state machine is not a type. The very word abstract assumes generalization, reuse and instances. It is types and generics, the tools to express the idea of instances. > Why the heck do I have to defend nesting of packages in the first > place? Is it because some popular languages and UML do not > usually nest object abstractions inside procedural artifacts? > Is it because you do not usually have nesting in C? Those are very low-level languages. UML is just typeless. > Is it because GCC (hence GNAT to some extent) was not built > knowing there would be locally defined things in languages > such as Ada? For dynamic scoping there exit blocks. We cannot replace blocks by packages. So let blocks rule. The only possible reason for nested packages is the language regularity: if a package can be nested in another package, then it should be allowed in any declarative scope. Probably even between "for" and "loop"! (:-)) But if you removed nested packages altogether you would probably notice no miss. Because it is only static nesting which is really needed, and that is covered by the child packages. It could be otherwise if packages were first-class objects, with abstract packages and the interfaces of. But that is a story for another day. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 14:17 ` Dmitry A. Kazakov @ 2007-09-03 15:55 ` Jean-Pierre Rosen 2007-09-03 19:17 ` Dmitry A. Kazakov 2007-10-31 23:59 ` adaworks 2007-09-03 20:38 ` Georg Bauhaus 1 sibling, 2 replies; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-03 15:55 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > It is difficult to see how an abstract state machine is not a type. The > very word abstract assumes generalization, reuse and instances. It is types > and generics, the tools to express the idea of instances. > Sorry, but I beg to disagree here. Abstraction is about the reduction of a real world objet to those elements that are relevant for a given point of view. A singleton is an abstraction of a single object, and does not need a type. I don't see anything in the word abstract that assumes generalization. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 15:55 ` Jean-Pierre Rosen @ 2007-09-03 19:17 ` Dmitry A. Kazakov 2007-09-03 19:32 ` Markus E L ` (2 more replies) 2007-10-31 23:59 ` adaworks 1 sibling, 3 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-03 19:17 UTC (permalink / raw) On Mon, 03 Sep 2007 17:55:33 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> It is difficult to see how an abstract state machine is not a type. The >> very word abstract assumes generalization, reuse and instances. It is types >> and generics, the tools to express the idea of instances. >> > Sorry, but I beg to disagree here. > > Abstraction is about the reduction of a real world objet to those > elements that are relevant for a given point of view. Of just one object? I think that an abstraction always apply to a set of things. What could be an abstraction of Spike, the dog? > A singleton is an abstraction of a single object, and does not need a > type. I don't see anything in the word abstract that assumes generalization. There is little abstraction in being alone. This is actually the reason why no type is need for a singleton: no abstraction, no instances, no type. In my view an abstract state machine has nothing to do with singletons. A state machine might be a singleton, per chance. But an *abstract* state machine is definitely a type that generalizes many concrete state machines. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 19:17 ` Dmitry A. Kazakov @ 2007-09-03 19:32 ` Markus E L 2007-09-03 20:14 ` Georg Bauhaus 2007-09-04 8:23 ` Jean-Pierre Rosen 2 siblings, 0 replies; 65+ messages in thread From: Markus E L @ 2007-09-03 19:32 UTC (permalink / raw) "Dmitry A. Kazakov" wrote: > In my view an abstract state machine has nothing to do with singletons. A > state machine might be a singleton, per chance. But an *abstract* state > machine is definitely a type that generalizes many concrete state machines. No. It's one where the implementation is hidden and only the interface/contract exposed. -- Markus ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 19:17 ` Dmitry A. Kazakov 2007-09-03 19:32 ` Markus E L @ 2007-09-03 20:14 ` Georg Bauhaus 2007-09-04 8:24 ` Dmitry A. Kazakov 2007-09-04 8:23 ` Jean-Pierre Rosen 2 siblings, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-03 20:14 UTC (permalink / raw) On Mon, 2007-09-03 at 21:17 +0200, Dmitry A. Kazakov wrote: > On Mon, 03 Sep 2007 17:55:33 +0200, Jean-Pierre Rosen wrote: > > > Dmitry A. Kazakov a écrit : > >> It is difficult to see how an abstract state machine is not a type. The > >> very word abstract assumes generalization, reuse and instances. It is types > >> and generics, the tools to express the idea of instances. > >> > > Sorry, but I beg to disagree here. > > > > Abstraction is about the reduction of a real world objet to those > > elements that are relevant for a given point of view. > > Of just one object? I think that an abstraction always apply to a set of > things. What could be an abstraction of Spike, the dog? (Hope you don't mind be stepping in here.) The abstraction could be: Those elements of Spike that are relevant for the given point of view on Spike? (Guiding the abstraction process.) If you insist that abstraction as a word can only have the meaning "common to many things" and that what a Spike package will really do is a reduction of informational detail, well, apparently there are different frames of reference for "abstraction". I wonder, though, why then we can still talk about abstract data type and abstract state machine. > > A singleton is an abstraction of a single object, and does not need a > > type. I don't see anything in the word abstract that assumes generalization. > > There is little abstraction in being alone. This is actually the reason why > no type is need for a singleton: no abstraction, no instances, no type. Is there little abstraction in being alone (hm, who said that being along is the source of the thing being an abstract?) or is there no abstraction? > In my view an abstract state machine has nothing to do with singletons. A > state machine might be a singleton, per chance. Could you say what you mean by "having nothing to do with"? (Sorry for being pedantic, but I think "nothing" and "per chance" (=something) differ.) > But an *abstract* state > machine is definitely a type that generalizes many concrete state machines. By what definition of type is an ASM a type that generalizes many concrete state machines (=what, in Ada terms?)? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 20:14 ` Georg Bauhaus @ 2007-09-04 8:24 ` Dmitry A. Kazakov 2007-09-04 9:36 ` Jean-Pierre Rosen 2007-09-05 10:49 ` Georg Bauhaus 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-04 8:24 UTC (permalink / raw) On Mon, 03 Sep 2007 22:14:09 +0200, Georg Bauhaus wrote: > On Mon, 2007-09-03 at 21:17 +0200, Dmitry A. Kazakov wrote: >> On Mon, 03 Sep 2007 17:55:33 +0200, Jean-Pierre Rosen wrote: >> >>> Dmitry A. Kazakov a �crit : >>>> It is difficult to see how an abstract state machine is not a type. The >>>> very word abstract assumes generalization, reuse and instances. It is types >>>> and generics, the tools to express the idea of instances. >>>> >>> Sorry, but I beg to disagree here. >>> >>> Abstraction is about the reduction of a real world objet to those >>> elements that are relevant for a given point of view. >> >> Of just one object? I think that an abstraction always apply to a set of >> things. What could be an abstraction of Spike, the dog? > > (Hope you don't mind be stepping in here.) > > The abstraction could be: Those elements of Spike that are relevant > for the given point of view on Spike? "Elements of Spike" is plural. Do you abstract Spike or its elements? > I wonder, though, why then we can still talk about abstract data > type and abstract state machine. Abstract data type is an abstraction of concrete data types. Abstract state machine is an abstraction of concrete state machines. >>> A singleton is an abstraction of a single object, and does not need a >>> type. I don't see anything in the word abstract that assumes generalization. >> >> There is little abstraction in being alone. This is actually the reason why >> no type is need for a singleton: no abstraction, no instances, no type. > > Is there little abstraction in being alone (hm, who said that being > along is the source of the thing being an abstract?) > or is there no abstraction? > >> In my view an abstract state machine has nothing to do with singletons. A >> state machine might be a singleton, per chance. > > Could you say what you mean by "having nothing to do with"? Let A, B be two concepts defined as subsets of some common domain set X. _def_ A has nothing to do with B = not (A in B or B in A) in = equal or subset of if � were a truth-valued set measure chosen on X, then having �A you could not deduce anything certain about �B and reverse: not (�A |= �B or �B |= �A) Neither implies another. Was that enough pedantic? (:-)) >> But an *abstract* state >> machine is definitely a type that generalizes many concrete state machines. > > By what definition of type is an ASM a type that generalizes many > concrete state machines (=what, in Ada terms?)? type State is (...); type Transition_Relation is array (State, State) of Boolean; type ASM is private; function Create (Initial : State; Wiring : Transition_Relation) return ASM; procedure Step (Machine : in out ASM; Input : State); This machine is abstract because its wiring is a parameter (abstracted). The set of states can also be abstracted, but I wished not to complicate otherwise obvious, I hope, things. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 8:24 ` Dmitry A. Kazakov @ 2007-09-04 9:36 ` Jean-Pierre Rosen 2007-09-04 10:14 ` Dmitry A. Kazakov 2007-09-05 10:49 ` Georg Bauhaus 1 sibling, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-04 9:36 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > Abstract data type is an abstraction of concrete data types. > > Abstract state machine is an abstraction of concrete state machines. > Maybe that's where our points of view differ. To me, an abstract data type is a data type that offers only an abstract interface, an interface which is an abstraction of a real-world domain, without (visible) references to the implementation. The concrete data type is the set of bits used to implement the abstract data type. (and similarly for the state machine). In short: I view the abstract data type as an abstraction of a real world object, not of a computer data type. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 9:36 ` Jean-Pierre Rosen @ 2007-09-04 10:14 ` Dmitry A. Kazakov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-04 10:14 UTC (permalink / raw) On Tue, 04 Sep 2007 11:36:37 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> Abstract data type is an abstraction of concrete data types. >> >> Abstract state machine is an abstraction of concrete state machines. > > Maybe that's where our points of view differ. > > To me, an abstract data type is a data type that offers only an abstract > interface, an interface which is an abstraction of a real-world domain, > without (visible) references to the implementation. The concrete data > type is the set of bits used to implement the abstract data type. (and > similarly for the state machine). > > In short: I view the abstract data type as an abstraction of a real > world object, not of a computer data type. I see, in your view abstraction = [abstract] model -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 8:24 ` Dmitry A. Kazakov 2007-09-04 9:36 ` Jean-Pierre Rosen @ 2007-09-05 10:49 ` Georg Bauhaus 2007-09-05 12:04 ` Dmitry A. Kazakov 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-05 10:49 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 03 Sep 2007 22:14:09 +0200, Georg Bauhaus wrote: > What could be an abstraction of Spike, the dog? >> (Hope you don't mind be stepping in here.) >> >> The abstraction could be: Those elements of Spike that are relevant >> for the given point of view on Spike? > > "Elements of Spike" is plural. Do you abstract Spike or its elements? The Abstraction and its (human) process will likely depend on the given point of view. The problem description might suggest a point of view. E.g., I might not care whether there is a knot in Spike's fur down one of its legs. I do care that this is Spike, the dog and not Odie or Lassie, so abstraction cannot just be "dog". Abstraction as a process can be fuzzy, I known you are familiar with that? >> I wonder, though, why then we can still talk about abstract data >> type and abstract state machine. > > Abstract data type is an abstraction of concrete data types. > > Abstract state machine is an abstraction of concrete state machines. OK, another interesting definition that refers us to the definition of a concrete state machine which I am certain is equally interesting, even though it is not given. However, there are other definition of ASM related to Ada. Let me drop some names to show why it might help communication if you find your own words for your own concepts. The following quotes can be merged into a view of packages as abstract state machines that is so common that any other implied meaning might unfortunately receive limited attention. Barnes, SPARK, 1997 describing an "abstract data type package" Stacks and then noting: "An Abstract State Machine (ASM) is a related concept and is implemented in much the same way. The major difference is that whereas an abstract data type package gives the ability to declare objects and then to operate upon them, an abstract state machine package declares just one object for us and the operations upon it. The package is then itself essentially the object and has internal `state' or `memory' containing the current value of the object." (p. 21) => ASM package is an object that has internal state The same author gives more hints in "Ada 2005", 2006: "... we introduce the concept of an Abstract State Machine (ASM) and ... extend this to Abstract Data Types (ADT). The general idea of abstraction is to distinguish the inner details of how something works from an external view of it. We can use a watch to look at the time without needing to know how it works. Indeed the case of the watch hides its inner workings from us. One of the major problems with simple languages, such as C and Pascal, is that they do not offer enough control of visibility." (p. 215) => external [public| view of hidden [body] inner workings, in a case [package] Cohen, in Ada as a Second Language, 1996, gives it the name "abstract data object". It is described as "use of packages ... to enclose a set of variables and a set of subprograms using those variables". (p 417) He describes a package that is declared in another package body and notes "complete control over the ways in which the variables are used" (p.417) => packages control use of the data object; can be declared local to other blocks; control visibility Not surprisingly, Booch in "Software Engineering with Ada", 1994 has written more than one section on Abstract Data Types and on Abstrace-State Machines. Note the hyphen (mentioned by J-P. Rosen I think). They are listed as two applications for Ada packages (p.227): "* Abstract data types Export objects and types Export other program units Do not maintain state information in the body * Abstract-state machines Do not export objects and types Export other program units Maintain state information in the body" He later describes generic units and "classical models for applying generic units". One application is "using generic units as state machine templates". A simple abstract-state machine package has a limitation in that "a program could include at most one .., since packages cannot be replicated like data type values can. By making the package [Furnace] into a generic unit, we can produce multiple furnaces." (pp. 255--256) => abstract-state machine packages can be generic There are other sources, not dealing with Ada specifically, but mentioning the use of Ada packages for this. >>> In my view an abstract state machine has nothing to do with singletons. A >>> state machine might be a singleton, per chance. >> Could you say what you mean by "having nothing to do with"? > > Let A, B be two concepts defined as subsets of some common domain set X. > > _def_ A has nothing to do with B = not (A in B or B in A) > > in = equal or subset of > > if � were a truth-valued set measure chosen on X, then having �A you could > not deduce anything certain about �B and reverse: > > not (�A |= �B or �B |= �A) > > Neither implies another. > > Was that enough pedantic? (:-)) Now tell us what the common domain set X for concept ASM and concept SINGLETON is, and the subsets ASM and SINGLETON. Then please explain why I cannot use packages for both ASM and SINGLETON in Ada, as they have nothing in common (or something per chance, only?). This is, then, what ASM has to do or not with SINGLETON when using Ada, at least if this is about Ada and mapping concepts from some commonly accepted X to Ada concepts. >>> But an *abstract* state >>> machine is definitely a type that generalizes many concrete state machines. >> By what definition of type is an ASM a type that generalizes many >> concrete state machines (=what, in Ada terms?)? > > type State is (...); > type Transition_Relation is array (State, State) of Boolean; > type ASM is private; > function Create (Initial : State; Wiring : Transition_Relation) > return ASM; > procedure Step (Machine : in out ASM; Input : State); > > This machine is abstract because its wiring is a parameter (abstracted). Hm. A singular parameter as a source of abstraction ... not a plural ... > The set of states can also be abstracted, but I wished not to complicate > otherwise obvious, I hope, things. This kind of word play leads nowhere, because it stipulates the one and only true meaning of the words abstract state machine (probably an ADT for abstract state-machine) and the one and only true way to implement it. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 10:49 ` Georg Bauhaus @ 2007-09-05 12:04 ` Dmitry A. Kazakov 2007-09-05 13:12 ` Jean-Pierre Rosen 2007-09-05 18:31 ` Georg Bauhaus 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-05 12:04 UTC (permalink / raw) On Wed, 05 Sep 2007 12:49:39 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> On Mon, 03 Sep 2007 22:14:09 +0200, Georg Bauhaus wrote: >> What could be an abstraction of Spike, the dog? >>> (Hope you don't mind be stepping in here.) >>> >>> The abstraction could be: Those elements of Spike that are relevant >>> for the given point of view on Spike? >> >> "Elements of Spike" is plural. Do you abstract Spike or its elements? > > The Abstraction and its (human) process will likely depend > on the given point of view. > The problem description might suggest a point of view. E.g., > I might not care whether there is a knot in Spike's fur down > one of its legs. I do care that this is Spike, the dog and not > Odie or Lassie, so abstraction cannot just be "dog". Yes, and you have to fix the point of view before you start to talk about *an* abstraction. The abstraction can be "dog" or it can be "named thing," but it cannot be Spike. > Abstraction as a process can be fuzzy, I known you are familiar > with that? If you want to refer to fuzziness and other measures of uncertainty, then carefully observe that these always brings multiple concurrent choices with. You simply cannot define either probability or possibility or whatever else measure on a singleton substrate without trivializing it to the crisp case. This is non-starter. >>> I wonder, though, why then we can still talk about abstract data >>> type and abstract state machine. >> >> Abstract data type is an abstraction of concrete data types. >> >> Abstract state machine is an abstraction of concrete state machines. > > OK, another interesting definition that refers us to > the definition of a concrete state machine which I am > certain is equally interesting, even though it is not given. See finite state machine. [...] > => ASM package is an object that has internal state Surely, FSM has states, the letter S stands for state. [...] > => external [public| view of hidden [body] inner workings, > in a case [package] Yep, packages have private and public parts. [...] > => packages control use of the data object; > can be declared local to other blocks; control visibility Packages encapsulate implementation. [...] > => abstract-state machine packages can be generic Packages can be generic. > There are other sources, not dealing with Ada specifically, > but mentioning the use of Ada packages for this. So what? I don't see any connection. How using ASM as an adjective to the word "package" could define either? Same for A in ASM and ADT. >>>> In my view an abstract state machine has nothing to do with singletons. A >>>> state machine might be a singleton, per chance. >>> Could you say what you mean by "having nothing to do with"? >> >> Let A, B be two concepts defined as subsets of some common domain set X. >> >> _def_ A has nothing to do with B = not (A in B or B in A) >> >> in = equal or subset of >> >> if � were a truth-valued set measure chosen on X, then having �A you could >> not deduce anything certain about �B and reverse: >> >> not (�A |= �B or �B |= �A) >> >> Neither implies another. >> >> Was that enough pedantic? (:-)) > > Now tell us what the common domain set X for concept ASM and > concept SINGLETON is, and the subsets ASM and SINGLETON. Easily X = the subject of CS > Then please explain why I cannot use packages for both ASM and SINGLETON You can, please, see the definition I gave - "not (A in B or B in A)" does not imply "A does not intersect B". The point was "to have one instance" and "to be a FSM" are unrelated. There exists FSM which are not singletons (example: instances of word.exe). There exist singletons which are not FSM (example: GUID). >>>> But an *abstract* state >>>> machine is definitely a type that generalizes many concrete state machines. >>> By what definition of type is an ASM a type that generalizes many >>> concrete state machines (=what, in Ada terms?)? >> >> type State is (...); >> type Transition_Relation is array (State, State) of Boolean; >> type ASM is private; >> function Create (Initial : State; Wiring : Transition_Relation) >> return ASM; >> procedure Step (Machine : in out ASM; Input : State); >> >> This machine is abstract because its wiring is a parameter (abstracted). > > Hm. A singular parameter as a source of abstraction ... not a plural ... Plural is addressed to the set of values of that type. >> The set of states can also be abstracted, but I wished not to complicate >> otherwise obvious, I hope, things. > > This kind of word play leads nowhere, This has a concrete and simple meaning: ASM has no free parameter for the set of states it would operate. One way to achieve that is to make it generic: generic type State is (<>); ... Another is to use an abstract type to describe the set: type State is abstract ...; type State_No is range 1..; function Pos (S: State) return State_No; function Val (No: State_No) return State; ... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 12:04 ` Dmitry A. Kazakov @ 2007-09-05 13:12 ` Jean-Pierre Rosen 2007-09-05 15:10 ` Dmitry A. Kazakov 2007-09-05 18:31 ` Georg Bauhaus 1 sibling, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-05 13:12 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > Yes, and you have to fix the point of view before you start to talk about > *an* abstraction. The abstraction can be "dog" or it can be "named thing," > but it cannot be Spike. > It seems that you really equate "abstraction" with "class". I agree that a class is a collection of objects, which is different from an instance (= a single object). But an abstraction (as I -and apparently others- understand it) is a reduced view of a real world *object*. You can have classes of abstractions, but an abstraction is not a class. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 13:12 ` Jean-Pierre Rosen @ 2007-09-05 15:10 ` Dmitry A. Kazakov 2007-09-05 16:25 ` Jean-Pierre Rosen 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-05 15:10 UTC (permalink / raw) On Wed, 05 Sep 2007 15:12:19 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> Yes, and you have to fix the point of view before you start to talk about >> *an* abstraction. The abstraction can be "dog" or it can be "named thing," >> but it cannot be Spike. >> > It seems that you really equate "abstraction" with "class". I agree that > a class is a collection of objects, which is different from an > instance (= a single object). No, I am using conventional meaning unspecific to programming. From http://www.thefreedictionary.com/dict.asp?Word=abstraction 1. a concept or idea not associated with any specific instance; "he loved her only in the abstract--not in person" 2. the act of withdrawing or removing something 3. the process of formulating general concepts by abstracting common properties of instances 4. an abstract painting 5. preoccupation with something to the exclusion of all else 6. a general concept formed by extracting common features from specific examples > But an abstraction (as I -and apparently others- understand it) is a > reduced view of a real world *object*. This is close the position 2. Mine is under 1 and 6 and Georg's is under 3. None of standard meanings 1-6 can be thought on the basis of single instance. The dictionary explicitly refers to "instances" and "examples." Even treating abstraction exclusively as modeling with removing something in order to model (though why couldn't we add something?), even when abstraction = moving from one substrate to another, one have to model not only the object, but the relations it participates with other objects. Actually, there is no objects only these relations. This were unthinkable to do on the basis of unique individual thing-in-itself. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 15:10 ` Dmitry A. Kazakov @ 2007-09-05 16:25 ` Jean-Pierre Rosen 2007-09-05 19:52 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-05 16:25 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > 1. a concept or idea not associated with any specific instance; "he loved > her only in the abstract--not in person" > > 2. the act of withdrawing or removing something > > 3. the process of formulating general concepts by abstracting common > properties of instances > > 4. an abstract painting > > 5. preoccupation with something to the exclusion of all else > > 6. a general concept formed by extracting common features from specific > examples Interesting... >> But an abstraction (as I -and apparently others- understand it) is a >> reduced view of a real world *object*. > > This is close the position 2. Mine is under 1 and 6 and Georg's is under 3. Yes. This is also the ethymological meaning: abs-tractare (latin) means "to withdraw from" > None of standard meanings 1-6 can be thought on the basis of single > instance. 2 certainly can. The idea is that you cannot put "Spike the dog" into your computer; what you can do is put some characteristics of it in the form of data that are of interest from the point of view of your program. You therefore abstract away all the uninteresting properties. > The dictionary explicitly refers to "instances" and "examples." > Even treating abstraction exclusively as modeling with removing something > in order to model (though why couldn't we add something?) How could you have something in the model that is not in what you are modelling? > , even when > abstraction = moving from one substrate to another, one have to model not > only the object, but the relations it participates with other objects. But you can have relations between instances, not necessarily between classes. If I walk Spike, it is a relation between an instance of a human being and an instance of a dogan being :-) -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 16:25 ` Jean-Pierre Rosen @ 2007-09-05 19:52 ` Dmitry A. Kazakov 2007-09-06 7:19 ` Jean-Pierre Rosen 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-05 19:52 UTC (permalink / raw) On Wed, 05 Sep 2007 18:25:29 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> None of standard meanings 1-6 can be thought on the basis of single >> instance. > 2 certainly can. The idea is that you cannot put "Spike the dog" into > your computer; what you can do is put some characteristics of it in the > form of data that are of interest from the point of view of your > program. You therefore abstract away all the uninteresting properties. Yes, but my point is that these characteristics would have qualitative or quantitative values from some sets. For example weight. Can I change it? Would it be Spike? If yes, then what does the weight characterize? If not, where is Spike? As long as I can construct (not Spike), it is not unique. Alone the word "characterize" bears in it to distinguish, to mark ... among some class of things. >> The dictionary explicitly refers to "instances" and "examples." >> Even treating abstraction exclusively as modeling with removing something >> in order to model (though why couldn't we add something?) > How could you have something in the model that is not in what you are > modelling? I can add some properties to make implementation simpler or possible. This happens quite often. For example, a telephone number modeled by a string, function "+" with Constraint_Error added to its contract, imaginary part or electric resistance. Some generalized problems are sufficiently simpler than their constrained variants. >> , even when >> abstraction = moving from one substrate to another, one have to model not >> only the object, but the relations it participates with other objects. > But you can have relations between instances, not necessarily between > classes. If I walk Spike, it is a relation between an instance of a > human being and an instance of a dogan being :-) Or an instance of a relation between human and dog. When you are designing AdaControl, who walks Spike? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 19:52 ` Dmitry A. Kazakov @ 2007-09-06 7:19 ` Jean-Pierre Rosen 2007-09-06 9:28 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-06 7:19 UTC (permalink / raw) Dmitry A. Kazakov a �crit : >> 2 certainly can. The idea is that you cannot put "Spike the dog" into >> your computer; what you can do is put some characteristics of it in the >> form of data that are of interest from the point of view of your >> program. You therefore abstract away all the uninteresting properties. > > Yes, but my point is that these characteristics would have qualitative or > quantitative values from some sets. For example weight. Can I change it? > Would it be Spike? If yes, then what does the weight characterize? Of course, if I feed Spike too much, its weight will change - and it is still Spike. I don't see the problem here. > If not, > where is Spike? As long as I can construct (not Spike), it is not unique. But if, *for my problem*, I am interested only in Spike, (not Spike) makes no sense. I'm not arguing that there cannot be a class of dogs, but that if in my problem domain I am interested in the properties of a single object, I can represent that single object in a computer, and that the representation of this single object, because it omits all the details that are not relevant to my problem, is an *abstraction*. >> How could you have something in the model that is not in what you are >> modelling? > > I can add some properties to make implementation simpler or possible. Ha! You said "implementation". To me, that's the concrete view. The abstract view is there to hide implementation details. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 7:19 ` Jean-Pierre Rosen @ 2007-09-06 9:28 ` Dmitry A. Kazakov 2007-09-06 11:53 ` Jean-Pierre Rosen 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 9:28 UTC (permalink / raw) On Thu, 06 Sep 2007 09:19:54 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >>> 2 certainly can. The idea is that you cannot put "Spike the dog" into >>> your computer; what you can do is put some characteristics of it in the >>> form of data that are of interest from the point of view of your >>> program. You therefore abstract away all the uninteresting properties. >> >> Yes, but my point is that these characteristics would have qualitative or >> quantitative values from some sets. For example weight. Can I change it? >> Would it be Spike? If yes, then what does the weight characterize? > Of course, if I feed Spike too much, its weight will change - and it is > still Spike. I don't see the problem here. You don't need to model Spike's weight in your system because changing the weight should have no effect. Spike cannot communicate its weight to other components of the system, because it is not *a* thing with mass. No, it is just Spike, the One. Its weight has been abstracted away. >> If not, >> where is Spike? As long as I can construct (not Spike), it is not unique. > But if, *for my problem*, I am interested only in Spike, (not Spike) > makes no sense. It might make no [immediate] use, but it does sense in the context of your abstract model. Some properties of Spike cannot be abstracted away even if they might happen to be constant/uninteresting. So your model is capable to deal with objects of different weight. It would certain generalization power. This can be used in order to verify consistency or ease implementation. Weight is a number with all properties of real values + ones of mass, acceleration etc. But Spike's weight (tm) is not a number. It is another singleton specific to Spike and unrelated to anything else = nothing. > I'm not arguing that there cannot be a class of dogs, > but that if in my problem domain I am interested in the properties of a > single object, I can represent that single object in a computer, and > that the representation of this single object, because it omits all the > details that are not relevant to my problem, is an *abstraction*. That's OK. I don't argue that there shall be multiple instances. However this too might potentially be quite useful in order to allow the compiler to pass Spike by value, to put it in a register or cache, to marshal over the network. Why should I care? In most [not all] cases I need not. Then to me, property/attribute/characteristic = a primitive operation yielding a value of some [other] type. How something without a type can have a primitive operation in a typed language like Ada? >>> How could you have something in the model that is not in what you are >>> modelling? >> >> I can add some properties to make implementation simpler or possible. > Ha! You said "implementation". To me, that's the concrete view. The > abstract view is there to hide implementation details. I meant implementation in a broader sense than "private constructs." Public declarations is an implementation too. Maybe, "realization" or "spelling" would be better. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 9:28 ` Dmitry A. Kazakov @ 2007-09-06 11:53 ` Jean-Pierre Rosen 2007-09-06 15:35 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-06 11:53 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > You don't need to model Spike's weight in your system because changing the > weight should have no effect. Spike cannot communicate its weight to other > components of the system, because it is not *a* thing with mass. No, it is > just Spike, the One. Its weight has been abstracted away. Sorry, but I'm really puzzled at this point. What do you know about *my* system? You seem to be of the kind of people who classify everything (no attack intended: just an observation). In my experience, about half of the people (but only half) think this way: if it has a weight, it must belong to the class of massive things. The rest of the world (to whom I belong) view things as having properties without the need of classifying. Maybe it is a matter of being left- or right-brained... > Weight is a number with all properties of real values + ones of mass, > acceleration etc. But Spike's weight (tm) is not a number. It is another > singleton specific to Spike and unrelated to anything else = nothing. Spike's weight is a physical property, but its abstraction (i.e. what I need from weight in my application) is its value in measurement unit. BTW, I would not say it is a singleton. Weight is not an object at all, it is a simple value. Remember: not everything is an object (I hope Michel Gauthier reads this) -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 11:53 ` Jean-Pierre Rosen @ 2007-09-06 15:35 ` Dmitry A. Kazakov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 15:35 UTC (permalink / raw) On Thu, 06 Sep 2007 13:53:50 +0200, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> You don't need to model Spike's weight in your system because changing the >> weight should have no effect. Spike cannot communicate its weight to other >> components of the system, because it is not *a* thing with mass. No, it is >> just Spike, the One. Its weight has been abstracted away. > Sorry, but I'm really puzzled at this point. > What do you know about *my* system? > > You seem to be of the kind of people who classify everything (no attack > intended: just an observation). In my experience, about half of the > people (but only half) think this way: if it has a weight, it must > belong to the class of massive things. The rest of the world (to whom I > belong) view things as having properties without the need of > classifying. Maybe it is a matter of being left- or right-brained... Hmm, I think you mean here constructive vs. non-constructive sets, like {x | P(x)}, where P is some predicate, like "has weight." But in finite case and a properly typed system everything is constructive anyway. I can always determine if the given object has mass. No difference. >> Weight is a number with all properties of real values + ones of mass, >> acceleration etc. But Spike's weight (tm) is not a number. It is another >> singleton specific to Spike and unrelated to anything else = nothing. > Spike's weight is a physical property, but its abstraction (i.e. what I > need from weight in my application) is its value in measurement unit. Yes, this is what I meant. Weight here is abstracted from Spike. When you get its value, that does not remember Spike. You have an operation that acts on Spike and yields weight. It is X.Weight or X'Weight or Weight(X), whatever, where X is Spike. But X here can be something different from Spike. You can measure something *else*. Spike is not a singleton for this operation. > BTW, I would not say it is a singleton. Weight is not an object at all, > it is a simple value. Remember: not everything is an object (I hope > Michel Gauthier reads this) I called it singleton in order to distinguish the case when weight were not abstracted from Spike. In that case you would not need to model it, Spike and Spike's weight were just equivalent. P.S. Yes, value is not an object, it is a state of. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 12:04 ` Dmitry A. Kazakov 2007-09-05 13:12 ` Jean-Pierre Rosen @ 2007-09-05 18:31 ` Georg Bauhaus 2007-09-05 19:52 ` Dmitry A. Kazakov 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-05 18:31 UTC (permalink / raw) On Wed, 2007-09-05 at 14:04 +0200, Dmitry A. Kazakov wrote: > and you have to fix the point of view before you start to talk about > *an* abstraction. The abstraction can be "dog" or it can be "named thing," > but it cannot be Spike. I fail to see why Spike the dog cannot become an abstract entity of a program. My perception of Spike can be that of a "named thing" with some details abstracted away as I see fit. Assuming a name doesn't turn a thing into atomic information without properties and without behavior. > > Abstraction as a process can be fuzzy, I known you are familiar > > with that? > > If you want to refer to fuzziness and other measures of uncertainty, then > carefully observe that these always brings multiple concurrent choices > with. For example the programmer's choice could include alternative points of view, suggested by the problem description. Each viewpoint can yield a slightly different abstraction when the resulting interfaces, say, are a consequence of more or less emphasis on some of the dog's characteristics. > You simply cannot define either probability or possibility or > whatever else measure on a singleton substrate without trivializing it to > the crisp case. This is non-starter. I have to ask whether by singleton substrate you mean something in the problem description that states one and only one possible quality of a thing. That'll beg the question, of course. > >>> I wonder, though, why then we can still talk about abstract data > >>> type and abstract state machine. > >> > >> Abstract data type is an abstraction of concrete data types. > >> > >> Abstract state machine is an abstraction of concrete state machines. > > > > OK, another interesting definition that refers us to > > the definition of a concrete state machine which I am > > certain is equally interesting, even though it is not given. > > See finite state machine. A finite state machine using packages, being implicit in some subprogram, the formal thing known as a tuple (...) where ..., the UML thing? There isn't just one definition/view/concept of finite state machine... > > There are other sources, not dealing with Ada specifically, > > but mentioning the use of Ada packages for this. > > So what? I don't see any connection. How using ASM as an adjective to the > word "package" could define either? Why define Ada packages in terms of ASMs or vice versa? I'm lost. > The point was "to have one instance" and "to be a FSM" are unrelated. There is a point of view from which the concept "to have one instance" and "to be a FSM" are unrelated. When writing an Ada program, you may have a point of view from which the concept "to have one instance" and "to be a FSM" coincide on a suitable conceptual level. It is the level on which an abstract state machine package is explained. > >>>> But an *abstract* state > >>>> machine is definitely a type that generalizes many concrete state machines. > >>> By what definition of type is an ASM a type that generalizes many > >>> concrete state machines (=what, in Ada terms?)? > >> > >> type State is (...); > >> type Transition_Relation is array (State, State) of Boolean; > >> type ASM is private; > >> function Create (Initial : State; Wiring : Transition_Relation) > >> return ASM; > >> procedure Step (Machine : in out ASM; Input : State); > >> > >> This machine is abstract because its wiring is a parameter (abstracted). > > > > Hm. A singular parameter as a source of abstraction ... not a plural ... > > Plural is addressed to the set of values of that type. So abstraction is all about starting at some type and then saying the thing using parameters of the type is abstract because each parameter will be of a yet unknown concrete kind? Seems like a narrowed view of abstraction. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 18:31 ` Georg Bauhaus @ 2007-09-05 19:52 ` Dmitry A. Kazakov 2007-09-05 21:38 ` Georg Bauhaus 2007-09-06 9:14 ` Markus E L 0 siblings, 2 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-05 19:52 UTC (permalink / raw) On Wed, 05 Sep 2007 20:31:11 +0200, Georg Bauhaus wrote: > On Wed, 2007-09-05 at 14:04 +0200, Dmitry A. Kazakov wrote: >> and you have to fix the point of view before you start to talk about >> *an* abstraction. The abstraction can be "dog" or it can be "named thing," >> but it cannot be Spike. > > I fail to see why Spike the dog cannot become an abstract entity > of a program. > My perception of Spike can be that of a "named thing" > with some details abstracted away as I see fit. > Assuming a name doesn't turn a thing into atomic information > without properties and without behavior. There exist no information without "behavior." Information is meaningless in absence of receivers. If Spike barks there is at least a tree here to be barked at. Barking in vacuum does not work. >>> Abstraction as a process can be fuzzy, I known you are familiar >>> with that? >> >> If you want to refer to fuzziness and other measures of uncertainty, then >> carefully observe that these always brings multiple concurrent choices >> with. > > For example the programmer's choice could include alternative > points of view, suggested by the problem description. Each viewpoint > can yield a slightly different abstraction when the resulting > interfaces, say, are a consequence of more or less emphasis on > some of the dog's characteristics. Yes you can have a set of abstractions and some confidence measure attached to each. The idea of probability et all theories is that all these outcomes, events, "focal elements" etc coexist. You cannot prefer any of them for certain, as you cannot say odd or even before the coin falls. This cannot be trivialized to certainty. So any model and whatever it predicts, always boils down to a distribution of confidences and stops there. >> You simply cannot define either probability or possibility or >> whatever else measure on a singleton substrate without trivializing it to >> the crisp case. This is non-starter. > > I have to ask whether by singleton substrate you mean > something in the problem description that states one and only > one possible quality of a thing. That'll beg the question, of course. If you have only one elementary outcome then its probability is trivially 1. You need a surface to smear uncertainty on... (:-)) >>> There are other sources, not dealing with Ada specifically, >>> but mentioning the use of Ada packages for this. >> >> So what? I don't see any connection. How using ASM as an adjective to the >> word "package" could define either? > > Why define Ada packages in terms of ASMs or vice versa? I didn't do that, not my idea. >> The point was "to have one instance" and "to be a FSM" are unrelated. > > There is a point of view from which the concept "to have one instance" > and "to be a FSM" are unrelated. When writing an Ada program, you may > have a point of view from which the concept "to have one instance" and > "to be a FSM" coincide on a suitable conceptual level. It is the level > on which an abstract state machine package is explained. Can I take a protected object or a task to implement either? (I have no respect to singletons. They might have some sacral meaning for some OO proponents, but that was always beyond my understanding.) >>>>>> But an *abstract* state >>>>>> machine is definitely a type that generalizes many concrete state machines. >>>>> By what definition of type is an ASM a type that generalizes many >>>>> concrete state machines (=what, in Ada terms?)? >>>> >>>> type State is (...); >>>> type Transition_Relation is array (State, State) of Boolean; >>>> type ASM is private; >>>> function Create (Initial : State; Wiring : Transition_Relation) >>>> return ASM; >>>> procedure Step (Machine : in out ASM; Input : State); >>>> >>>> This machine is abstract because its wiring is a parameter (abstracted). >>> >>> Hm. A singular parameter as a source of abstraction ... not a plural ... >> >> Plural is addressed to the set of values of that type. > > So abstraction is all about starting at some type and then > saying the thing using parameters of the type is abstract > because each parameter will be of a yet unknown concrete kind? > Seems like a narrowed view of abstraction. It is not the whole view, just a necessary component of: "one for many." You can have it with variable vs. values, type vs. values+operations, sets of types vs. types (classes/generics). I don't object when "many" is in the problem domain and "one" is in the solution one. It is an abstraction too, but not so interesting as others. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 19:52 ` Dmitry A. Kazakov @ 2007-09-05 21:38 ` Georg Bauhaus 2007-09-06 7:37 ` Dmitry A. Kazakov 2007-09-06 9:14 ` Markus E L 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-05 21:38 UTC (permalink / raw) Dmitry A. Kazakov wrote: [snip all kinds of buzz words :-] >>> The point was "to have one instance" and "to be a FSM" are unrelated. >> There is a point of view from which the concept "to have one instance" >> and "to be a FSM" are unrelated. When writing an Ada program, you may >> have a point of view from which the concept "to have one instance" and >> "to be a FSM" coincide on a suitable conceptual level. It is the level >> on which an abstract state machine package is explained. > > Can I take a protected object or a task to implement either? You can take a package and implement either. > (I have no respect to singletons. They might have some sacral meaning for > some OO proponents, but that was always beyond my understanding.) They can avoid surprises and nasty issues because they enforce body visibility of data objects. Example: <start of declarative part> package S is type T is limited private; procedure op(x: in out T); private type T is limited record null; end record; end S; package body S is separate; -- ... a different programmer has a clever idea -- ... and adds another ad hoc procedure for -- ... debugging porposes procedure bar(x: S.T) is begin raise Program_Error; end bar; use S; item: T; begin bar(item); end; This is of course an artificial example. However, it serves to demonstrate a few effects. Once the object type T is visible outside the package (being declared in the public part of S), objects can be declared outside of S. Adding a subprogram like Bar will in a sense break grouping (where to look for bar which takes a T). If the author of S had intended an upper bound on instances of T, say one instance, then enforcing this limit will require more work. These issues go away with a simple abstract state machine style package. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 21:38 ` Georg Bauhaus @ 2007-09-06 7:37 ` Dmitry A. Kazakov 2007-09-06 10:26 ` Georg Bauhaus 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 7:37 UTC (permalink / raw) On Wed, 05 Sep 2007 23:38:34 +0200, Georg Bauhaus wrote: > They can avoid surprises and nasty issues because they enforce body > visibility of data objects. Example: > > <start of declarative part> > > package S is > type T is limited private; > procedure op(x: in out T); > private > type T is limited record > null; > end record; > end S; This is IMO bad design, it should be: package S is -- Stateless type T is limited private; ... end S; package Data is -- Stateful ... -- Operations having an instance of T as a hidden parameter end Data; with S; package body Data is Singleton : S.T; ... end Data; There is no need to "with" S for anybody else, provided that Singleton as an object indeed has no public interface. Otherwise it has to be typed anyway. You can also move T to the private part of Data or to its body, but you should never expose it. ----------------- I don't know if "true" typeless singletons exist. It is difficult to find one. Clock is *a* Time-valued function, current thread is *a* task, Gravitational constant is *a* floating-point number. Theological dispute. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 7:37 ` Dmitry A. Kazakov @ 2007-09-06 10:26 ` Georg Bauhaus 2007-09-06 12:25 ` Dmitry A. Kazakov 2007-09-08 1:27 ` Randy Brukardt 0 siblings, 2 replies; 65+ messages in thread From: Georg Bauhaus @ 2007-09-06 10:26 UTC (permalink / raw) On Thu, 2007-09-06 at 09:37 +0200, Dmitry A. Kazakov wrote: > On Wed, 05 Sep 2007 23:38:34 +0200, Georg Bauhaus wrote: > > > They can avoid surprises and nasty issues because they enforce body > > visibility of data objects. Example: > > > > <start of declarative part> > > > > package S is > > type T is limited private; > > procedure op(x: in out T); > > private > > type T is limited record > > null; > > end record; > > end S; > > This is IMO bad design, it should be: > > package S is -- Stateless > type T is limited private; > ... > end S; IIUC, this will still allow referencing S.T elsewhere. And even when S has only subprograms, they are visible to other parts of the program. But S was intended to be used by some procedure, and only by the procedure. > package Data is -- Stateful > ... -- Operations having an instance of T as a hidden parameter > end Data; > > with S; > package body Data is > Singleton : S.T; > ... > end Data; > > There is no need to "with" S for anybody else, Do you think that "No need to with S" will convince programmers to not touch it? When I need to make sure that S is not going to be used elsewhere, it needs to be hidden. What are the options? Either build some fairly complicated hierarchy with visibility in private parts or simply declare S where it is needed: in the declarative part of the enclosing subprogram. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 10:26 ` Georg Bauhaus @ 2007-09-06 12:25 ` Dmitry A. Kazakov 2007-09-08 1:27 ` Randy Brukardt 1 sibling, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 12:25 UTC (permalink / raw) On Thu, 06 Sep 2007 12:26:45 +0200, Georg Bauhaus wrote: > On Thu, 2007-09-06 at 09:37 +0200, Dmitry A. Kazakov wrote: >> On Wed, 05 Sep 2007 23:38:34 +0200, Georg Bauhaus wrote: >> >>> They can avoid surprises and nasty issues because they enforce body >>> visibility of data objects. Example: >>> >>> <start of declarative part> >>> >>> package S is >>> type T is limited private; >>> procedure op(x: in out T); >>> private >>> type T is limited record >>> null; >>> end record; >>> end S; >> >> This is IMO bad design, it should be: >> >> package S is -- Stateless >> type T is limited private; >> ... >> end S; > > IIUC, this will still allow referencing S.T elsewhere. > And even when S has only subprograms, they are visible to > other parts of the program. > But S was intended to be used by some procedure, > and only by the procedure. If you are paranoid about treacherous intentions of your colleges, then make S a private child: private package Data.S is type T(<>) is limited private; ... end Data.S; >> package Data is -- Stateful >> ... -- Operations having an instance of T as a hidden parameter >> end Data; >> >> with S; >> package body Data is >> Singleton : S.T; >> ... >> end Data; >> >> There is no need to "with" S for anybody else, > > Do you think that "No need to with S" will convince programmers > to not touch it? Yes, I do hope they would not do it if I'd ask them, as well as many other things one could do being inspired by the things declared in System, Ada.Unchecked_xxx etc. > When I need to make sure that S is not going > to be used elsewhere, it needs to be hidden. What are the options? Safe and consistent design. Consider what is T in your model? Why there has to be only one instance of? Which meaning has this in terms of the operations on T? Who knows, you might come to a conclusion that this constraint is not really necessary or maybe that it is enforced automatically when T is properly used. In real-life designs there are usually far more access levels than just public/private/body with fuzzy boundaries between them. You have to rely on your design and good will of people working with you. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 10:26 ` Georg Bauhaus 2007-09-06 12:25 ` Dmitry A. Kazakov @ 2007-09-08 1:27 ` Randy Brukardt 1 sibling, 0 replies; 65+ messages in thread From: Randy Brukardt @ 2007-09-08 1:27 UTC (permalink / raw) "Georg Bauhaus" <rm.tsoh+bauhaus@maps.futureapps.de> wrote in message news:1189074405.2630.257.camel@kartoffel.vocalweb.de... ... > Do you think that "No need to with S" will convince programmers > to not touch it? When I need to make sure that S is not going > to be used elsewhere, it needs to be hidden. What are the options? > Either build some fairly complicated hierarchy with visibility in > private parts or simply declare S where it is needed: in the > declarative part of the enclosing subprogram. Declare it a private child package, and other units *can't* with it. Ada has this covered (and yes, it seems to come up fairly often). Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-05 19:52 ` Dmitry A. Kazakov 2007-09-05 21:38 ` Georg Bauhaus @ 2007-09-06 9:14 ` Markus E L 2007-09-06 9:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 65+ messages in thread From: Markus E L @ 2007-09-06 9:14 UTC (permalink / raw) "Dmitry A. Kazakov" wrote: > (I have no respect to singletons. They might have some sacral meaning for > some OO proponents, but that was always beyond my understanding.) What about your filesystem? You pass around a filesystem object to all functions that use a filesystem? And a console object to all those that use a console? - Markus ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-06 9:14 ` Markus E L @ 2007-09-06 9:48 ` Dmitry A. Kazakov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 9:48 UTC (permalink / raw) On Thu, 06 Sep 2007 11:14:43 +0200, Markus E L wrote: > "Dmitry A. Kazakov" wrote: > >> (I have no respect to singletons. They might have some sacral meaning for >> some OO proponents, but that was always beyond my understanding.) > > What about your filesystem? You pass around a filesystem object to all > functions that use a filesystem? I do File_Type. > And a console object to all those that use a console? Is it Standard_Error or Standard_Output today? (:-)) Though, if I correctly understand the idea beyond your examples, they refer to the computational environment. If so, then it is not an object and it cannot be an object. It does not belong to the solution space, it is where that space exists = another language, outside. The part of computational environment which can be expressed in the language immediately looses it magical singleton properties. (DRM guys have a problem... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 19:17 ` Dmitry A. Kazakov 2007-09-03 19:32 ` Markus E L 2007-09-03 20:14 ` Georg Bauhaus @ 2007-09-04 8:23 ` Jean-Pierre Rosen 2 siblings, 0 replies; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-04 8:23 UTC (permalink / raw) Dmitry A. Kazakov a �crit : >> Abstraction is about the reduction of a real world objet to those >> elements that are relevant for a given point of view. > > Of just one object? I think that an abstraction always apply to a set of > things. What could be an abstraction of Spike, the dog? A computer abstraction of Spike-the-dog is the reduction to a computer data structure of those elements that characterize the state of Spike-the-dog and are useful for the purpose of the computer program. > In my view an abstract state machine has nothing to do with singletons. A > state machine might be a singleton, per chance. But an *abstract* state > machine is definitely a type that generalizes many concrete state machines. > There is an ambiguity in English: from what you say, I assume you parse it as an abstract (state machine); but it can also be understood as an (abstract state) machine. With the latter, you just have one machine (a singleton) whose states are abstraction of real world states. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 15:55 ` Jean-Pierre Rosen 2007-09-03 19:17 ` Dmitry A. Kazakov @ 2007-10-31 23:59 ` adaworks 1 sibling, 0 replies; 65+ messages in thread From: adaworks @ 2007-10-31 23:59 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1494 bytes --] "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:qpahbf.s76.ln@hunter.axlog.fr... > Dmitry A. Kazakov a �crit : >> It is difficult to see how an abstract state machine is not a type. The >> very word abstract assumes generalization, reuse and instances. It is types >> and generics, the tools to express the idea of instances. >> > Sorry, but I beg to disagree here. > > Abstraction is about the reduction of a real world objet to those elements > that are relevant for a given point of view. > > A singleton is an abstraction of a single object, and does not need a type. I > don't see anything in the word abstract that assumes generalization. > -- I usually think of this, package Integer_Stack is -- no exported type procedure Push(Data : Integer); -- more operations end Integer_Stack; as a kind of ASM (an object package), where, package Stacker is type Integer_Stack is limited private; procedure Push ... private -- full type definition end Stacker; supports an ADT. In the both cases, there is internal state. In the first, no instances are possible except by putting the package in scope (with Integer_Stack). In the second, the existence of the package simply wraps the ADT, and multiple instances can be declared of the exported type. Perhaps this is an oversimplification, but it works in practice. Richard Riehle ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 14:17 ` Dmitry A. Kazakov 2007-09-03 15:55 ` Jean-Pierre Rosen @ 2007-09-03 20:38 ` Georg Bauhaus 2007-09-04 8:24 ` Dmitry A. Kazakov 1 sibling, 1 reply; 65+ messages in thread From: Georg Bauhaus @ 2007-09-03 20:38 UTC (permalink / raw) On Mon, 2007-09-03 at 16:17 +0200, Dmitry A. Kazakov wrote: > On Mon, 03 Sep 2007 12:51:14 +0200, Georg Bauhaus wrote: > > > On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote: > >> On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote: > >> > >>> Suppose every package is reusable. > >> > >> That's the goal. > > > > Why? > > In order to get a better understanding of the problem and solution. What, exactly, is the improvement in understanding a given problem that involves one House and one Barn? The fact that by way of scholastic sophistication we can think of all kinds of combinations of many Barns, or Houses? What is the gain in coming up with types summarizing things that just are not present in the problem domain? Should we have to rewrite the descriptions of our models until the goal of achieving all-package-reusability can be reached? (I know that programming just a little more than what is necessary for solving the given problem can be beneficial. The solution may gradually become much less simple, though. Difficult to understand, that is!) > > The "abstract state machines" kind of package (as opposed > > to those packages framing an "abstract data type") do work well > > in Ada program without a type parameter; it doesn't carry > > any additional information of spectacular use. > > It is difficult to see how an abstract state machine is not a type. Ada type or DK type? Certainly packages can have seen to have "qualities" that Ada types happen to have as well, e.g. exposing an "interface" in the non-Ada sense of the word. A singleton will have this kind of interface. A type defined in the corresponding package changes little in this regard. > For dynamic scoping there exit blocks. We cannot replace blocks by > packages. So let blocks rule. The only possible reason for nested packages > is the language regularity: if a package can be nested in another package, > then it should be allowed in any declarative scope. Probably even between > "for" and "loop"! (:-)) But if you removed nested packages altogether you > would probably notice no miss. Because it is only static nesting which is > really needed, and that is covered by the child packages. Well, so what? Can I use a package declared within a procedure as a match for a problem domain object? It seems quite reasonable to me to do so when a local package is an easy way to deal with lifetime, modularization, and visibility at the same time. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-03 20:38 ` Georg Bauhaus @ 2007-09-04 8:24 ` Dmitry A. Kazakov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-04 8:24 UTC (permalink / raw) On Mon, 03 Sep 2007 22:38:49 +0200, Georg Bauhaus wrote: > On Mon, 2007-09-03 at 16:17 +0200, Dmitry A. Kazakov wrote: >> On Mon, 03 Sep 2007 12:51:14 +0200, Georg Bauhaus wrote: >> >>> On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote: >>>> On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote: >>>> >>>>> Suppose every package is reusable. >>>> >>>> That's the goal. >>> >>> Why? >> >> In order to get a better understanding of the problem and solution. > > What, exactly, is the improvement in understanding > a given problem that involves one House and one Barn? The fact > that by way of scholastic sophistication we can think > of all kinds of combinations of many Barns, or Houses? > What is the gain in coming up with types summarizing > things that just are not present in the problem domain? Wow, are you arguing against understanding or just against reuse and refactoring (used in order to achieve it)? > Should we have to rewrite the descriptions of our models > until the goal of achieving all-package-reusability > can be reached? Yes, this is a part of normal software developing / evolving cycle. Or do you have write-once applications in mind? > (I know that programming just a little more than what is > necessary for solving the given problem can be beneficial. > The solution may gradually become much less simple, though. > Difficult to understand, that is!) Abstraction, normally reduces, complexity, provided that a better understanding was indeed achieved... >>> The "abstract state machines" kind of package (as opposed >>> to those packages framing an "abstract data type") do work well >>> in Ada program without a type parameter; it doesn't carry >>> any additional information of spectacular use. >> >> It is difficult to see how an abstract state machine is not a type. > > Ada type or DK type? > Certainly packages can have seen to have "qualities" that Ada > types happen to have as well, e.g. exposing an "interface" in > the non-Ada sense of the word. A singleton will have this kind of > interface. A type defined in the corresponding package changes > little in this regard. I don't follow you. There are five things, all different: 1. Abstract data type 2. Package 3. Singleton 4. State machine 5. Abstract state machine I don't see why you take for granted that 2 = 4 or 5. Package is not a state machine, at least if you don't want to reduce everything to machine code. Even less is it an abstract state machine. > Can I use a package declared within a procedure as a match for a > problem domain object? Packages are not for modeling individual objects. > It seems quite reasonable to me to do so > when a local package is an easy way to deal with lifetime, > modularization, and visibility at the same time. Nonsense. When you want to use a package as a model of something, then all your words about lifetime, modularization, being local etc become meaningless. These are solution-specific properties irrelevant to the thing being modeled. You have to talk about the domain problem properties. Which properties of the domain are modeled by a package? Solve at least one *domain* problem using a package, only package and nothing but package. See? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 16:03 ` Dmitry A. Kazakov 2007-09-01 19:49 ` Georg Bauhaus @ 2007-09-03 7:54 ` Jean-Pierre Rosen 1 sibling, 0 replies; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-03 7:54 UTC (permalink / raw) Dmitry A. Kazakov a �crit : > I think the empiric rule could be: if a package is used to declare types, > then it should have no mutable state. Otherwise it should not have type > declarations. > Long time ago, Booch classified packages as "abstract data types" or "abstract state machines" (and a couple of others). That was before he turned to the dark side of the source... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 13:46 ` Dmitry A. Kazakov 2007-09-01 14:15 ` Georg Bauhaus @ 2007-09-01 15:33 ` Markus E L 2007-09-04 14:55 ` Adam Beneschan 1 sibling, 1 reply; 65+ messages in thread From: Markus E L @ 2007-09-01 15:33 UTC (permalink / raw) "Dmitry A. Kazakov" wrote: > On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: > >> (The true O-O programmer might suggest that we should simply >> pass an additional object-as-module parameter to every >> package subprogram... ) > > Yes, it is better to keep packages stateless. Not if they are singletons, i.e. objects of which only one instance can occur in the program. Then they are better modeled as packages. Regards -- Markus ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-01 15:33 ` Markus E L @ 2007-09-04 14:55 ` Adam Beneschan 2007-09-04 15:09 ` Jean-Pierre Rosen 2007-09-04 17:31 ` Georg Bauhaus 0 siblings, 2 replies; 65+ messages in thread From: Adam Beneschan @ 2007-09-04 14:55 UTC (permalink / raw) On Sep 1, 8:33 am, Markus E L <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote: > "Dmitry A. Kazakov" wrote: > > On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: > > >> (The true O-O programmer might suggest that we should simply > >> pass an additional object-as-module parameter to every > >> package subprogram... ) > > > Yes, it is better to keep packages stateless. > > Not if they are singletons, i.e. objects of which only one instance > can occur in the program. Then they are better modeled as packages. The trouble is, I can think of several occasions in which I assumed an object could only have one instance---and then later found reason to wish I had written it so that there could be two. No, this doesn't happen in all cases. But it seems to me it happens often enough that one should carefully examine any assumption that there can be only one instance. Or be prepared to go back and make some major changes later. -- Adam ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 14:55 ` Adam Beneschan @ 2007-09-04 15:09 ` Jean-Pierre Rosen 2007-09-08 1:36 ` Randy Brukardt 2007-09-04 17:31 ` Georg Bauhaus 1 sibling, 1 reply; 65+ messages in thread From: Jean-Pierre Rosen @ 2007-09-04 15:09 UTC (permalink / raw) Adam Beneschan a �crit : > The trouble is, I can think of several occasions in which I assumed an > object could only have one instance---and then later found reason to > wish I had written it so that there could be two. > > No, this doesn't happen in all cases. But it seems to me it happens > often enough that one should carefully examine any assumption that > there can be only one instance. Or be prepared to go back and make > some major changes later. > If you implemented your singleton as a package, it is quite an automatic transformation: - Add a (normally private) type to the specification - Implement it as a record whose components are all the global (state) variables of the package - Add a parameter of this type to every subprogram provided by the package, and in the bodies, change the references to the global variables to the corresponding field of the new parameter. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 15:09 ` Jean-Pierre Rosen @ 2007-09-08 1:36 ` Randy Brukardt 0 siblings, 0 replies; 65+ messages in thread From: Randy Brukardt @ 2007-09-08 1:36 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1740 bytes --] "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:jfsjbf.smp.ln@hunter.axlog.fr... > Adam Beneschan a �crit : > > > The trouble is, I can think of several occasions in which I assumed an > > object could only have one instance---and then later found reason to > > wish I had written it so that there could be two. > > > > No, this doesn't happen in all cases. But it seems to me it happens > > often enough that one should carefully examine any assumption that > > there can be only one instance. Or be prepared to go back and make > > some major changes later. > > > If you implemented your singleton as a package, it is quite an automatic > transformation: > > - Add a (normally private) type to the specification > - Implement it as a record whose components are all the global (state) > variables of the package > - Add a parameter of this type to every subprogram provided by the > package, and in the bodies, change the references to the global > variables to the corresponding field of the new parameter. I'd call it rote perhaps, but it is nowhere near automatic. Changing the references of the globals alone can take hours (there is no prefix to change with an automatic tool, and the names typically conflict with other entities). Moreover, you also have to change the comments to match, and especially the error handling (which often will need more detailed exception information in order to be able to tell which instances are involved). If you think it is so easy, I have a number of packages (and the programs that use them) that need such an update. Where should I send the source?? ;-) After all, most programming is rote, but very little can really be automated. Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-04 14:55 ` Adam Beneschan 2007-09-04 15:09 ` Jean-Pierre Rosen @ 2007-09-04 17:31 ` Georg Bauhaus 1 sibling, 0 replies; 65+ messages in thread From: Georg Bauhaus @ 2007-09-04 17:31 UTC (permalink / raw) On Tue, 2007-09-04 at 07:55 -0700, Adam Beneschan wrote: > On Sep 1, 8:33 am, Markus E L > <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote: > > "Dmitry A. Kazakov" wrote: > > > On Sat, 01 Sep 2007 15:33:09 +0200, Georg Bauhaus wrote: > > > > >> (The true O-O programmer might suggest that we should simply > > >> pass an additional object-as-module parameter to every > > >> package subprogram... ) > > > > > Yes, it is better to keep packages stateless. > > > > Not if they are singletons, i.e. objects of which only one instance > > can occur in the program. Then they are better modeled as packages. > > The trouble is, I can think of several occasions in which I assumed an > object could only have one instance---and then later found reason to > wish I had written it so that there could be two. After careful consideration, when I have only two objects, they are almost identical, they are used locally and they don't need to be passed around, I could use generic instances much the same way I could use object instances and distinguished receiver notation. The "almost identical" part of the sentence can turn into a tiny generic formal part or into a Create procedure of the package. (And rewriting can always be done as described by J-P. Rosen in this thread.) Didn't this work reasonably well in Ada 83 for singletons? For me, multiplicity(!) is by default more than 2, like in some natural languages that have special forms for a "multiplicity" of 2. When I can say, 'Many!', it is time to change from single objects to typed instances of the lot. I understand that for a mathematician, multiplicity starts at 0. So the question is, what is the best Ada construct for modeling no object? Packages with or without a type? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-08-31 19:33 ` Dmitry A. Kazakov 2007-09-01 13:33 ` Georg Bauhaus @ 2007-09-08 1:16 ` Randy Brukardt 2007-09-10 16:27 ` amado.alves 1 sibling, 1 reply; 65+ messages in thread From: Randy Brukardt @ 2007-09-08 1:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:9fy1xoukz1e3$.h574sqmiauri$.dlg@40tude.net... > On Fri, 31 Aug 2007 16:47:29 -0000, amado.alves@gmail.com wrote: > > > Then you have seen illegal Ada code repeatedly. I wish this were > > possible myself. Or more simply: > > > > type T is -- limited or not > > Self : access T := T'Unchecked_Access; > > ... > > end; > > T cannot be non-limited, because otherwise passing it by copy would make > rubbish out of Self. In any case it would make little sense if not access > T'Class. Sure it can, just not written this way. The original question used Limited_Controlled, and thus you can initialize the pointer in the Initialize routine: procedure Initialize (Obj : in out T) is begin Self := Obj'Unchecked_Access; end Initialize; If the type is non-limited, you have to "fix" the self-pointer in Adjust. That's essentially how Claw does it. I personally prefer putting the code in Initialize (it's not so tricky that way, and you have more flexibility), but YMMV. Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-08 1:16 ` Randy Brukardt @ 2007-09-10 16:27 ` amado.alves 2007-09-10 17:13 ` Adam Beneschan 2007-09-10 19:00 ` Dmitry A. Kazakov 0 siblings, 2 replies; 65+ messages in thread From: amado.alves @ 2007-09-10 16:27 UTC (permalink / raw) > > > ... I wish this were > > > possible myself. Or more simply: > > > > type T is -- limited or not > > > Self : access T := T'Unchecked_Access; > > > ... > > > end; (Marius) > > > T cannot be non-limited, because otherwise passing it by copy would make > > rubbish out of Self. In any case it would make little sense if not access > > T'Class. (Kasakov) > > Sure it can... (Randy) Yes, now the compiler is accepting this (and letting me copy objects, and, yes, getting rubbish in Self). I have no idea why it was not compiling before. It just wasn't. And the messages indicated trouble in the type. So, and because I know that Ada is a very sensitive lady, I jumped to the (wrong) conclusion that the thing was illegal. /* FWIW, the problem was the following. I am writing a library. I wanted to provide a function to the user to allow him to specify the parent of an object in a simple way e.g. Parent_Object : Object := Lookup (Name = "foo foo"); Object : Object := Create (Name => "bla bla", Parent => Parent_Object); The idea was to have a clean profile like Create (Name : String; Parent : Object); instead of Create (Name : String; Parent : access Object); Inside the function there is code like New_Object.Parent := Parent.Self; -- (clean profile) or New_Object.Parent := Parent; -- ('dirty' profile) I am kind of redesigning the library now so these issues are yet in flux. */ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-10 16:27 ` amado.alves @ 2007-09-10 17:13 ` Adam Beneschan 2007-09-10 19:00 ` Dmitry A. Kazakov 1 sibling, 0 replies; 65+ messages in thread From: Adam Beneschan @ 2007-09-10 17:13 UTC (permalink / raw) On Sep 10, 9:27 am, amado.al...@gmail.com wrote: > > > > ... I wish this were > > > > possible myself. Or more simply: > > > > > type T is -- limited or not > > > > Self : access T := T'Unchecked_Access; > > > > ... > > > > end; (Marius) > > > > T cannot be non-limited, because otherwise passing it by copy would make > > > rubbish out of Self. In any case it would make little sense if not access > > > T'Class. (Kasakov) > > > Sure it can... (Randy) > > Yes, now the compiler is accepting this (and letting me copy objects, > and, yes, getting rubbish in Self). I have no idea why it was not > compiling before. It just wasn't. And the messages indicated trouble > in the type. So, and because I know that Ada is a very sensitive lady, > I jumped to the (wrong) conclusion that the thing was illegal. If the compiler is letting you compile this: type T is record Self : access T := T'Unchecked_Access; end record; then the compiler is wrong, because this is illegal. The prefix of 'Unchecked_Access must be aliased, and the current instance of a non- limited record is not aliased. (Using 'Unchecked_Access instead of 'Access eliminates accessibility level checks, but the other rules that apply to 'Access, including the rule that it may apply only to an aliased view. See 3.10.2(23), 3.10(9) (and AARM 3.10(9.b)), 13.10(2-3). Using 'Unrestricted_Access may be OK, though; it's not part of the language, and GNAT gets to make whatever rules they like about whether it's legal. -- Adam ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-10 16:27 ` amado.alves 2007-09-10 17:13 ` Adam Beneschan @ 2007-09-10 19:00 ` Dmitry A. Kazakov 2007-09-11 3:12 ` Randy Brukardt 1 sibling, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-10 19:00 UTC (permalink / raw) On Mon, 10 Sep 2007 16:27:50 -0000, amado.alves@gmail.com wrote: > FWIW, the problem was the following. I am writing a library. I wanted > to provide a function to the user to allow him to specify the parent > of an object in a simple way e.g. > Parent_Object : Object := Lookup (Name = "foo foo"); > Object : Object := Create (Name => "bla bla", Parent => > Parent_Object); What happens when the parent gets finalized before its child? The point is that if you have a reference semantics, then probably Object must be a reference. So access Obkect'Class were a better design. If you want to hide references, then you should use smart pointers instead. > The idea was to have a clean profile like > Create (Name : String; Parent : Object); > instead of > Create (Name : String; Parent : access Object); > > Inside the function there is code like > New_Object.Parent := Parent.Self; -- (clean profile) > or > New_Object.Parent := Parent; -- ('dirty' profile) > > I am kind of redesigning the library now so these issues are yet in > flux. I why don't you use Ada.Finalization.Limited_Controlled? Copying linked objects is suspicious anyway. When you copy a parent what happens with its children? Limited_Controlled is always aliased and by-reference. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-10 19:00 ` Dmitry A. Kazakov @ 2007-09-11 3:12 ` Randy Brukardt 2007-09-11 9:38 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Randy Brukardt @ 2007-09-11 3:12 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:h9v0j8x5uuf3.puwqdmssdfn6$.dlg@40tude.net... > On Mon, 10 Sep 2007 16:27:50 -0000, amado.alves@gmail.com wrote: > > > FWIW, the problem was the following. I am writing a library. I wanted > > to provide a function to the user to allow him to specify the parent > > of an object in a simple way e.g. > > Parent_Object : Object := Lookup (Name = "foo foo"); > > Object : Object := Create (Name => "bla bla", Parent => > > Parent_Object); > > What happens when the parent gets finalized before its child? The point is > that if you have a reference semantics, then probably Object must be a > reference. So access Obkect'Class were a better design. If you want to hide > references, then you should use smart pointers instead. I disagree. Claw uses a design rather like the one proposed here. All of the needed references are created inside of the Claw library, and managed there (with Finalization and Adjust). For instance, if the parent object is finalized, the child object is finalized first (that's necessary because destroying a parent window also destroys any children). If a child window is finalized, it is unlinked from any lists that it is in. Keep in mind that a tagged parameter is always considered aliased. So there is no problem creating any references you need inside the library (assuming that yyour basic types are tagged -- which they usually will be in order to have them Controlled). I strongly believe that having explicit access types in a specification is wrong. Because of limitations in Ada, they can't quite all be eliminated (no "in out" parameters for functions, for instance), but I think they should only be used if there is no viable alternative. (This opinion is not universal.) > > The idea was to have a clean profile like > > Create (Name : String; Parent : Object); > > instead of > > Create (Name : String; Parent : access Object); Yes, except the first probably ought to be Create (Name : String; Parent : Object'Class); (tagged subroutines either should be primitive operations or have class-wide parameters, otherwise there is something suspicious going on. And surely Create is not a primitive of the parent object's type!) > > Inside the function there is code like > > New_Object.Parent := Parent.Self; -- (clean profile) Don't even need that. Just use: New_Object.Parent := Parent'Unchecked_Access; since tagged parameters are always considered aliased. (You do need to keep a list of children in Parent as well so that it can be unlinked from the child if it is finalized first). I personally think self pointers are overrated in Ada; you only really need them to work around language bugs ("in out" parameters for functions again); for everything else, just use the object directly. Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-11 3:12 ` Randy Brukardt @ 2007-09-11 9:38 ` Dmitry A. Kazakov 2007-09-12 21:57 ` Randy Brukardt 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-11 9:38 UTC (permalink / raw) On Mon, 10 Sep 2007 22:12:47 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:h9v0j8x5uuf3.puwqdmssdfn6$.dlg@40tude.net... >> On Mon, 10 Sep 2007 16:27:50 -0000, amado.alves@gmail.com wrote: >> >>> FWIW, the problem was the following. I am writing a library. I wanted >>> to provide a function to the user to allow him to specify the parent >>> of an object in a simple way e.g. >>> Parent_Object : Object := Lookup (Name = "foo foo"); >>> Object : Object := Create (Name => "bla bla", Parent => >>> Parent_Object); >> >> What happens when the parent gets finalized before its child? The point is >> that if you have a reference semantics, then probably Object must be a >> reference. So access Obkect'Class were a better design. If you want to hide >> references, then you should use smart pointers instead. > > I disagree. Claw uses a design rather like the one proposed here. All of the > needed references are created inside of the Claw library, and managed there > (with Finalization and Adjust). For instance, if the parent object is > finalized, the child object is finalized first (that's necessary because > destroying a parent window also destroys any children). If a child window is > finalized, it is unlinked from any lists that it is in. What happens when somebody would create some of these objects on the stack? You argue for automatic collection, that is my point too. But I would go further and hide target objects behind handles to. That would eliminate "access." The language problem is though that there is no simple way to delegate operations from handle to the target object. It requires a lot of work. > I strongly believe that having explicit access types in a specification is > wrong. Because of limitations in Ada, they can't quite all be eliminated (no > "in out" parameters for functions, for instance), but I think they should > only be used if there is no viable alternative. (This opinion is not > universal.) Agreed. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-11 9:38 ` Dmitry A. Kazakov @ 2007-09-12 21:57 ` Randy Brukardt 2007-09-13 8:03 ` Dmitry A. Kazakov 0 siblings, 1 reply; 65+ messages in thread From: Randy Brukardt @ 2007-09-12 21:57 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:uffdiv96c9bc.6mn4qaig7owe.dlg@40tude.net... > On Mon, 10 Sep 2007 22:12:47 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > > news:h9v0j8x5uuf3.puwqdmssdfn6$.dlg@40tude.net... > >> On Mon, 10 Sep 2007 16:27:50 -0000, amado.alves@gmail.com wrote: > >> > >>> FWIW, the problem was the following. I am writing a library. I wanted > >>> to provide a function to the user to allow him to specify the parent > >>> of an object in a simple way e.g. > >>> Parent_Object : Object := Lookup (Name = "foo foo"); > >>> Object : Object := Create (Name => "bla bla", Parent => > >>> Parent_Object); > >> > >> What happens when the parent gets finalized before its child? The point is > >> that if you have a reference semantics, then probably Object must be a > >> reference. So access Obkect'Class were a better design. If you want to hide > >> references, then you should use smart pointers instead. > > > > I disagree. Claw uses a design rather like the one proposed here. All of the > > needed references are created inside of the Claw library, and managed there > > (with Finalization and Adjust). For instance, if the parent object is > > finalized, the child object is finalized first (that's necessary because > > destroying a parent window also destroys any children). If a child window is > > finalized, it is unlinked from any lists that it is in. > > What happens when somebody would create some of these objects on the stack? Works fine -- that's the whole point of this design. When the objects get finalized, the Claw code for Finalize unlinks them from their parent's list of children (after destroying any children that they might have). No fuss, no muss, quite cheap to do, and no dangling pointers. > You argue for automatic collection, that is my point too. But I would go > further and hide target objects behind handles to. That would eliminate > "access." The language problem is though that there is no simple way to > delegate operations from handle to the target object. It requires a lot of > work. Not worth it, because you either lose extension or gain a second level of tagged types for no real benefit. The Claw design would be a bit more complex if you wanted the children to survive the destruction of the parent, but even that wouldn't be very hard or expensive to accomplish. You don't even need a list of root objects in order to implement this design (Claw has one for other reasons, but it is only involved in finalization to remove units from it.) The biggest annoyance in the Claw design is handling copies, and that really occurs because the Claw objects probably ought to have been limited, but we didn't want to give up aggregates and functions (and now we don't have to). Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-12 21:57 ` Randy Brukardt @ 2007-09-13 8:03 ` Dmitry A. Kazakov 2007-09-13 21:37 ` Randy Brukardt 0 siblings, 1 reply; 65+ messages in thread From: Dmitry A. Kazakov @ 2007-09-13 8:03 UTC (permalink / raw) On Wed, 12 Sep 2007 16:57:05 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:uffdiv96c9bc.6mn4qaig7owe.dlg@40tude.net... >> What happens when somebody would create some of these objects on the stack? > > Works fine -- that's the whole point of this design. When the objects get > finalized, the Claw code for Finalize unlinks them from their parent's list > of children (after destroying any children that they might have). No fuss, > no muss, quite cheap to do, and no dangling pointers. But then storage management should be made elsewhere, I mean, if children are only finalized but not deallocated. >> You argue for automatic collection, that is my point too. But I would go >> further and hide target objects behind handles to. That would eliminate >> "access." The language problem is though that there is no simple way to >> delegate operations from handle to the target object. It requires a lot of >> work. > > Not worth it, because you either lose extension or gain a second level of > tagged types for no real benefit. One benefit is GC (thought reference counting, for example), another is an ability to share object implementations (aliasing). Both add their problems too, of course. (:-)) BTW, are you going to port Claw to X11 anytime? (In the recent time I worked much with GTK+, what a mess!) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Self pointer in limited record 2007-09-13 8:03 ` Dmitry A. Kazakov @ 2007-09-13 21:37 ` Randy Brukardt 0 siblings, 0 replies; 65+ messages in thread From: Randy Brukardt @ 2007-09-13 21:37 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:16dbv6ehzvw3q.1ccv5mc0b5a2m.dlg@40tude.net... > On Wed, 12 Sep 2007 16:57:05 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > > news:uffdiv96c9bc.6mn4qaig7owe.dlg@40tude.net... > > >> What happens when somebody would create some of these objects on the stack? > > > > Works fine -- that's the whole point of this design. When the objects get > > finalized, the Claw code for Finalize unlinks them from their parent's list > > of children (after destroying any children that they might have). No fuss, > > no muss, quite cheap to do, and no dangling pointers. > > But then storage management should be made elsewhere, I mean, if children > are only finalized but not deallocated. True. But it is best to let the user decide how to do storage management (it should be a separate choice from the ADT). If stack management will work for their application (as is does for most Claw programs), then why make them (or the runtime, for that matter) mess with something more complicated? And if they do need dynamic allocation, they're much more likely to have knowledge of how it should be accomplished than any generic ADT designer. (And, of course, the ADT can easily be combined with any one of the containers packages; we shouldn't be deciding that they need a list when they might really need a map.) > >> You argue for automatic collection, that is my point too. But I would go > >> further and hide target objects behind handles to. That would eliminate > >> "access." The language problem is though that there is no simple way to > >> delegate operations from handle to the target object. It requires a lot of > >> work. > > > > Not worth it, because you either lose extension or gain a second level of > > tagged types for no real benefit. > > One benefit is GC (thought reference counting, for example), another is an > ability to share object implementations (aliasing). Both add their problems > too, of course. (:-)) True enough. As noted above, I generally prefer to separate memory management/data structures from the ADT itself. Of course, the ADT has to do its own internal memory management as needed. > BTW, are you going to port Claw to X11 anytime? (In the recent time I > worked much with GTK+, what a mess!) We've thought about it some, but haven't had the customer that really wanted it. OTOH, I'm seriously looking at moving a lot of my work to Linux (have gotten disgusted with Microsoft DRM in the OS), so that could force some level of porting. (We've done a few pieces, like the sockets library, but that isn't really what needs to be done.) Randy. ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2007-10-31 23:59 UTC | newest] Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-07-04 19:31 Self pointer in limited record Maciej Sobczak 2007-07-05 8:22 ` Dmitry A. Kazakov 2007-07-05 10:35 ` Maciej Sobczak 2007-07-05 11:01 ` Pascal Obry 2007-07-05 11:14 ` Georg Bauhaus 2007-07-05 12:36 ` Dmitry A. Kazakov 2007-08-31 16:47 ` amado.alves 2007-08-31 17:09 ` Pascal Obry 2007-08-31 17:37 ` Adam Beneschan 2007-08-31 18:26 ` Jeffrey R. Carter 2007-08-31 19:33 ` Dmitry A. Kazakov 2007-09-01 13:33 ` Georg Bauhaus 2007-09-01 13:46 ` Dmitry A. Kazakov 2007-09-01 14:15 ` Georg Bauhaus 2007-09-01 16:03 ` Dmitry A. Kazakov 2007-09-01 19:49 ` Georg Bauhaus 2007-09-01 20:09 ` Dmitry A. Kazakov 2007-09-02 21:37 ` Georg Bauhaus [not found] ` <re7ei5lc7dzf$.11qtcnh35jmzg$.dlg@40tude.net> 2007-09-03 10:51 ` Georg Bauhaus 2007-09-03 14:17 ` Dmitry A. Kazakov 2007-09-03 15:55 ` Jean-Pierre Rosen 2007-09-03 19:17 ` Dmitry A. Kazakov 2007-09-03 19:32 ` Markus E L 2007-09-03 20:14 ` Georg Bauhaus 2007-09-04 8:24 ` Dmitry A. Kazakov 2007-09-04 9:36 ` Jean-Pierre Rosen 2007-09-04 10:14 ` Dmitry A. Kazakov 2007-09-05 10:49 ` Georg Bauhaus 2007-09-05 12:04 ` Dmitry A. Kazakov 2007-09-05 13:12 ` Jean-Pierre Rosen 2007-09-05 15:10 ` Dmitry A. Kazakov 2007-09-05 16:25 ` Jean-Pierre Rosen 2007-09-05 19:52 ` Dmitry A. Kazakov 2007-09-06 7:19 ` Jean-Pierre Rosen 2007-09-06 9:28 ` Dmitry A. Kazakov 2007-09-06 11:53 ` Jean-Pierre Rosen 2007-09-06 15:35 ` Dmitry A. Kazakov 2007-09-05 18:31 ` Georg Bauhaus 2007-09-05 19:52 ` Dmitry A. Kazakov 2007-09-05 21:38 ` Georg Bauhaus 2007-09-06 7:37 ` Dmitry A. Kazakov 2007-09-06 10:26 ` Georg Bauhaus 2007-09-06 12:25 ` Dmitry A. Kazakov 2007-09-08 1:27 ` Randy Brukardt 2007-09-06 9:14 ` Markus E L 2007-09-06 9:48 ` Dmitry A. Kazakov 2007-09-04 8:23 ` Jean-Pierre Rosen 2007-10-31 23:59 ` adaworks 2007-09-03 20:38 ` Georg Bauhaus 2007-09-04 8:24 ` Dmitry A. Kazakov 2007-09-03 7:54 ` Jean-Pierre Rosen 2007-09-01 15:33 ` Markus E L 2007-09-04 14:55 ` Adam Beneschan 2007-09-04 15:09 ` Jean-Pierre Rosen 2007-09-08 1:36 ` Randy Brukardt 2007-09-04 17:31 ` Georg Bauhaus 2007-09-08 1:16 ` Randy Brukardt 2007-09-10 16:27 ` amado.alves 2007-09-10 17:13 ` Adam Beneschan 2007-09-10 19:00 ` Dmitry A. Kazakov 2007-09-11 3:12 ` Randy Brukardt 2007-09-11 9:38 ` Dmitry A. Kazakov 2007-09-12 21:57 ` Randy Brukardt 2007-09-13 8:03 ` Dmitry A. Kazakov 2007-09-13 21:37 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox