Re: Two ideas for the next Ada Standard

[Jonas Nygren <ehsjony@ehs.ericsson.se>]

Jon S Anthony wrote:
> 
> In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
> 
> > I just state a fact of my own Ada code, it could be that I have
> > not yet learnt how to write good Ada code.
> 
> I think that is getting at it.
> 
> > In Ada, pointers are
> > distinct types which differs from C/C++,  eg:
> >
> > type X1A is access X;
> > type X2A is access X;
> > X1P : X1A;
> > X2P : X2A;
> > To use X1P and X2P together often requires conversions.
> >
> > X *x1p, *x2p;
> 
> Well, why would you declare TWO access types to the same designated
> type, unless you really DID want tow DIFFERENT types that were in fact
> distinct????  If you just want to rename for some reason then use
> the renaming for types - subtype:
> 
> subtype X2A is X1A;
> 
> X1P : X1A := ...
> X2P : X2A := X1P; -- No problem or conversion...
> 
> > In C/C++ there is only one pointer type for each object type.
> > (if we disregard const, typedefs are just syntactical sugar).
> 
> Well, if this is what you want - just do it.  Nothing prevents you
> from either A) only declaring the ONE access type or B) using subtype
> renamings.  The C/C++ case is just a simple subset of what you can do.
> 
> > In Ada you have to carry around both object and pointer type
> > everywhere you might want to use it - if you don't you will
> > often need to do some conversion.
> 
> Not if you just do what you really seem to want.

the following type of code is often found in Ada:

generic
   type T is private;
   type TA is access all T;   -- this is what I mean with carrying
package P is....              -- with you
                              
Suppose that we after the instantiation of this package
need to do some conversion to the access type passed to P,
when e g extending an existing application, using:

(2)
       generic
           type Object(<>) is limited private;
       package System.Address_To_Access_Conversions is
          pragma Preelaborate(Address_To_Access_Conversions);
(3)
          type Object_Pointer is access all Object;
          function To_Pointer(Value : Address) return Object_Pointer;
          function To_Address(Value : Object_Pointer) return Address;
(4)
          pragma Convention(Intrinsic, To_Pointer);
          pragma Convention(Intrinsic, To_Address);
       end System.Address_To_Access_Conversions;

How do we use Object_Pointer together with our existing access type
without conversion. Of course we could reorganise all our code
so that we instantiated the conversion package first. This is perhaps
not acceptable if we already have proven and tested code.

Further how do one end up with one and only one access type
if one have to instantiate multiple packages that declare their
own access types.

And no, renaming via subtypes don't help you.
> 
> > If you write code using tagged types you often want to use dynamically
> > allocated objects and hence use access values in function/procedure
> > calls. When one pass 'the object' as an access argument the 'object'
> > will always have mode 'in out' , it is not possible to pass the
> > object with only 'in' mode.
> 
> If you are really this concerned about this why not just make the type
> limited private?  Clients can't access the state (except through the
> interface) and they can't assign the things.  For _clients_, it is
> strictly _in_ mode.

This is too crude, an either-or approach. I want to be able to control 
the accessability for each call. 

> 
> In the body of the primitive operations defined in the interface, you
> can update the individual fields (if they are not limited) of the
> object designated by the parameter, but you can't assign it.  This is
> rather more secure than the analog C++ where you get a small piece of
> this with const T* arguments.

Well, I suppose you have missed the 'const T* const'. 

What I want is similar to C++'s:

struct T {
	void p1() const; // the object cannot be modified inside P1
	void p2();       // the object can be modified inside P2
...
};

calling: obj.p1(), obj.p2()
> 
> > So if you want to provide functions or procedures which restricts
> > the update of 'the object' then you have to provide an interface
> > with a mix of 'access' and 'in' modes with the following confusion
> > for the user of the interaface who will need to use a mix of P1(XA)
> > and P2(XA.all). It is very ugly and confusing to use such
> > interfaces.
> 
> I don't understand this at all.  You're correct - it is very
> confusing...

Yes, I guess so. The C++ example above but in Ada with access types:

type T is tagged....

procedure P1 (Obj : in T);     -- Obj cannot be modified inside P1
procedure P2 (Obj : access T); -- Obj can be modified inside P2

calling:  P1(Obj.all);
          P2(Obj);

Perhaps not a big deal, but the asymmetry of the solution is
very ugly in my eyes. 

If we could have written:

procedure P1 (Obj : access constant T);

We could then call P1(Obj). Everything would then have been
symmetrical and beautiful (again in my eyes).

And I can't see that it would have been too difficult to implement
in a compiler.

> 
> > (one could ask why one ever would use 'access constant' and I
> > would reply: for the very same reasons as we have for the 'in' mode)
> >
> > I want the 'access constant' feature for practical reasons, not out of
> > C++ notsalgia.
> 
> That sounds correct as you never had what you really seem to want in
> in C++ either.

In this case C++ have what I want. There are many other aspects 
of C++ which I do not like and when I add up pros and cons for Ada 
and C++ then Ada wins (again this is as seen with my eyes). That's
why I bother about Ada at all - I want Ada to become 'better'.

A side note: perhaps all these years in the shadow of C and C++
have resulted in that Ada proponents automatically takes a
defensive stand as soon as Ada and C/C++ are mentioned in the
same context. I don't believe Ada need to be defended - it can hold
its own ground. But no language is perfect - I don't believe anybody
would claim that Ada is the final and ultimate programming language.
I believe for e.g. that Ada would benefit by the 'access const'
construct. Perhaps Gnat could serve as a test environment for new
language concepts much as gcc does for C.

> 
> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178
> 
> 617.484.3383
> jsa@organon.com