Re: The "()" operator revisited.

["Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcck73w9536.fsf@shell01.TheWorld.com...
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>
> > Last June, I proposed that in order to provide an abstract array
capability,
> > Ada 0y should support  user-defined "()" and "():="operators. Since this
> > issue has come up again, I would like to summarize and expand on this
> > proposal.
>
> This is a good idea.  As you note below, it's got a long way to go
> before you've got a list of wording changes to the RM.  For example, the
> notion of operator-named *procedures* does not currently exist in Ada.

First, I'm glad you like the idea. Granted, Ada does not have operator-named
procedures, but there has been discussions about making ":=" an operator.

> But before bothering with that, I think there are some important
> issues to work out:
>
> You seem to be saying that components of arrays (or just abstract
> arrays?) are always passed by copy.  That seems like a real problem,
> since for efficiency, most compilers pass large things by reference.
> (I'm talking about the case of array-of-large-array or
> array-of-large-record.)

I did not mean to imply anything about the parameter passing convention
used. Clearly, we need to support all parameter passing conventions, since
any type can be used as an array component.

The confusion probably arose from the discussion of passing an array
component as a parameter of mode "in out". Now if the array component is
aliased, passing the component by reference is easy: simply pass the address
of the component. If the component is not aliased, as is often the case,
this method would not work. The way many compilers (including GNAT) handle
passing a packed component to a subprogram is:

- Create a temporary variable of the given component type;
- If the parameter is of mode "in" or "in out", unpack the array component
into the temporary variable;
- Pass this temporary variable to the subprogram; and
- If the parameter is of mode "out" or "in out", pack the temporary variable
value into the  array component.

Note that although this requires a temporary copy, it does NOT require that
the subprogram parameter use pass by copy.

Given that this is done currently for packed arrays, there is no good reason
why this cannot be done for the proposed abstract

> Furthermore, if the component type is limited, it is *required* to be
> passed by reference.  This raises the question: can "():=" be declared
> for limited types?

The idea of assigning a limited component to an array component is tricky,
given that there is never to be more than one copy of an object of a limited
type. We can, however, take advantage of the fact that limited objects are
always aliased, and implement such an array as a collection of access values
to the limited objects. For this to work, however, the Value parameter of
"():=" would need to be "in out" mode in order to get a non-constant
reference, so I propose that we also allow "():=" to be declared as

    procedure "():=" ( Source  : in out Abstract_Array_Type;
                       Index_1 : in     Index_Type_1;
                       Index_2 : in     Index_Type_2;
                       ...
                       Index_N : in     Index_Type_N;
                       Value   : in out Component_Type );

I have prototyped this with a limited type.

> What does A(I)'Access mean in this scheme?

Abstract array components, in general, are not aliased, so that expression
would not be legal. In some abstract arrays, however, the components would
be aliased, so we should probably allow the user to specify the access value
to be returned in such cases.

> Are there interactions with Adjust, which is normally called for
> assignment of nonlimited controlled types?

The "()" and "():=" are regular subprograms, so Adjust would be called
whenever the subprogram code requires it.

> You seem to treat 'out' parameters as copy-out only.  But for composite
> types, 'out' means pretty much the same thing as 'in out' -- at least
> *some* parts of the object are copied *in* (see RM for details).
> Likewise, if the component type is an access type, you can't allow
> undefined values to be created -- all access objects have to be
> initialized to 'null' if they aren't initialized to something else
> meaningful.

This type of initialization could easily be done before calling the
subprogram, so I don't see how this is a barrier for abstract arrays.

> You seemed to be hoping that this new notation could underly the
> definition of the *existing* array indexing semantics.  That would be
> elegant.  However, some of the above issues mean it doesn't work -- at
> least as you've defined it so far.

Is there an issue other than parameter passing?

> > Note: the following discussion probably has an insufficient amount of
> > legalese to satisfy language lawyers. Once we've thrashed out these
ideas,
> > I'll be happy to work with anyone with formalizing this proposal.
>
> I hate to be discouraging, but my guess is that a proposal like this is
> *not* going to be accepted by the ARG, even if were written up as proper
> RM wording changes.

That is quite possibly true. I have never done a submission to the ARG
before, so I'm not really up on the procedure. The first step, however, is
to have a solid idea for submission, which is why we're discussing it here.

> > Similar declarations can be added to Ada.Strings.Bounded. This would
permit
> > the higher-level Ada string types to use the same notation as the
low-level
> > standard String type.
>
> Well, it allows that for the particular notation of array indexing,
> and that would be a good thing.  But it doesn't completely solve
> the problem.  It doesn't support slice notation (but I don't think
> slices are all that important).  And it doesn't support string literal
> notation -- I think that *is* important -- it's really annoying that you
> can't have a string literal of type uunbounded string.  Similarly, it
> doesn't support aggregate notation.
>
> If I were designing a language from scratch, I would allow user-defined
> meanings for all of the above notations.  But as I said, unfortunately,
> I don't see this happening for Ada 0X.
>
> - Bob