Self pointer in limited record

Self pointer in limited record

[Maciej Sobczak]

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/

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Maciej Sobczak]

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/

Re: Self pointer in limited record

[Pascal Obry]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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?

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[amado.alves]

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 :-)

Re: Self pointer in limited record

[Pascal Obry]

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

Re: Self pointer in limited record

[Adam Beneschan]

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

Re: Self pointer in limited record

[Jeffrey R. Carter]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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... )

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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?

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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;

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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.

Re: Self pointer in limited record

[Georg Bauhaus]

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? 

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Markus E L]

"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

Re: Self pointer in limited record

[Georg Bauhaus]

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?)?

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Georg Bauhaus]

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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Randy Brukardt]

"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.

Re: Self pointer in limited record

[Markus E L]

"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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[adaworks]

[-- 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 

Re: Self pointer in limited record

[Georg Bauhaus]

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. 

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Markus E L]

"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

Re: Self pointer in limited record

[Adam Beneschan]

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

Re: Self pointer in limited record

[Jean-Pierre Rosen]

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

Re: Self pointer in limited record

[Randy Brukardt]

[-- 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.

Re: Self pointer in limited record

[Georg Bauhaus]

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?

Re: Self pointer in limited record

[Randy Brukardt]

"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.

Re: Self pointer in limited record

[amado.alves]

> > > ... 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.
*/

Re: Self pointer in limited record

[Adam Beneschan]

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

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Randy Brukardt]

"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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Randy Brukardt]

"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.

Re: Self pointer in limited record

[Dmitry A. Kazakov]

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

Re: Self pointer in limited record

[Randy Brukardt]

"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.