Re: Adding "()" operator to Ada 200X

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

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1ec946d1.0306021542.58714996@posting.google.com...
> But all you've done is change the syntax.  None of your suggestions
> allow you to do more than is already provided by the library.

But isn't the same thing true of all operators? Instead of defining "+" for
my types, I could define a function named Sum. It would have the same
functionality as the "+", it would just read differently.

OTOH, how an expression reads is very important! One of Ada's strengths is
its readability, and I would consider

    D := B * B - 4 * A * C;

to be more readable than

    D := Difference( Product( B, B ), Product( Product( 4, A ), C ) );

Part of why the former expression is clearer is that it uses the standard
arithmetic notation that one uses for numeric types. Thus, even if A, B, C
and D are not a numberic type (they could be matrices, for example), we
understand the author's intentions here.

From the very beginning, Ada has allowed programmers to define operators
such as "+", "*", "and", etc. for user defined types, so that the user types
can use the same notation as the predefined types. By analogy, why not do
the same for a user type that is analgous to an array? Isn't

    B( I ) := A( P( I ) ) + C( I );

clearer than

    Replace_Element( B, I, Element( A, Element( P, I ) ) + Element( C,
I ) );

> If you're going to make a change in the syntax of the language, then
> it has be because it allows you to do something you can't do already.
> For example, there's no way to declare an access subtype right now
> that means "all the access values except null."  A useful language
> change would be to allow the declaration:
>
>   type Element_Access_Base is access all Element_Type;
>
>   subtype Element_Access is Element_Access_Base range not null;

This is an interesting idea, and we should probably pursue it further in
another. Constraint checking has always been tremendously helpful. There is
one potential (but not insurmountable) problem with this proposal: in the
absence of explicit initializations, an access variable is initialized to
null.