Re: Syntax question

[kst@thomsoft.com (Keith Thompson)]

In <3jrt1m$9rk@erinews.ericsson.se> etlghh@garbo.ericsson.se (Geoffrey Hollingworth) writes:
> I am currently researching into real time languages and hope
> you ada experts can explain something to me.  I apologise for
> my lack of knowledge in ada.
> When binding formal parameters with actual parameters the '=>'
> operator is used, irrespective of whether the formal parameter
> is declared as IN, INOUT or OUT.  Is there a reason for this ?
> If I proposed an alternative syntax where "=>" indicated the FP
> was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
> to indicate an INOUT.
> Then the caller of the procedure/function would have explicitly
> had to understand to direction of the parameters and at the same
> time increased the readability of his/her code.

Some versions of preliminary Ada (1979, possibly 1980) used ":=", "=:",
and ":=:" for named associations for in, out, and in out parameters,
respectively.  This was changed to "=>" for all three modes.  As others
have mentioned, this applies only to named notation; in positional
notation you just write the actual expressions or names separated
by commas.

As part of the Ada 9X revision process, I proposed a revision to allow
the parameter mode to be (optionally) specified for actual parameters by
using "in", "out", or "in out".  The compiler would check that the mode
is consistent with the declaration.  For example, given the declaration

    procedure Foo(X: in Integer; Y: out Integer);

, and given that A and B are Integer objects, any of the following calls
would be legal, along with numerous other combinations:

    Foo(A, B);                  -- existing syntax
    Foo(X => A, Y => B);        -- existing syntax
    Foo(in A, out B);           -- new syntax
    Foo(in X => A, out Y => B); -- new syntax

and the following would be illegal:

    Foo(in X => A, in out Y => B); -- inconsistent mode specified for Y => B

This change would have been entirely upward compatible, straightforward
to implement, and (IMHO) could have dramatically improved readability
in many cases, but it didn't make it into the language.

Maybe for Ada 200X?

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.