Re: Two ideas for the next Ada Standard

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

Richard A. O'Keefe wrote:
> 
> Jonas Nygren <jonas@joy.ericsson.se> writes:
> >Coming from a C/C++ background I have had a hard time to adjust to
> >many of the Ada features (geez, I have never casted so much before in
> >my programming life).
> 
> This puzzles me greatly.  I've been hacking Ada for about two years now,
> and *except when trying to interface to C code* find that I have very
> few conversions.  

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

In C/C++ there is only one pointer type for each object type. 
(if we disregard const, typedefs are just syntactical sugar). 

So in C/C++ you need not 'carry around' the pointer type for an
object - the one and only pointer type for that object is directly
available from the object type.

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.

> 
> >Still, there are some things I have a problem to adjust to. One is
> >P(X) instead of the popular X.P notation.
> 
> The Pop family of languages has always identified F(X) and X.F.
> Are you are happy to see x.sqrt.print instead of print(sqrt(x))?
> If not, _why_ not?  In Smalltalk, after all, sqrt _is_ a method in
> the floating point class...
> 
> Algol 68 and COBOL use "field OF record" instead of "record.field".
> Is that _really_ such a big deal?
> 
> Hmm.  It would be interesting to determine the preferences of
>  - people whose native language is SVO, like English
>     Prediction: subject.method(object) preferred.
> 
>  - people whose native language is VSO
>     Prediction:  method(subject, object) preferred
> 
>  - people whose native language is SOV (isn't Japanese like that?)
>     Prediction:  somewhere in between the others.
> 
> I suppose it won't do any good to point out that the Ada approach
> generalises nicely to overloaded operators, while the C++ approach
> requires some ad hack kluging?

And dispatching on return values from functions. But I still like
X.P better than P(X) because I immediately can see what object I am
operating on. With P(X,Y) one would have to go back to the definition
of P to know if it dispatches on X or Y. But this is something one
have to adopt to - Ada will never change to X.P notation.
 
> 
> >E.g. I can not understand why one cannot have an anonymous access
> >argument which refers to a constant, e.g P(X : access CONSTANT XT).
> >Why not? What ever could have been said against this? Premature?
> 
> What exactly does this buy you that an "in" argument doesn't buy you?
> It looks _awfully_ like a demand that Ada look like C++ (const ref).

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

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

> Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

/jonas