Re: The "()" operator revisited.

[Robert A Duff <bobduff@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.
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.)

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?

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

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

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.

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.

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

> 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