Lang. Design Query (no practical value)

Lang. Design Query (no practical value)

[W. Wesley Groleau (Wes)]

The answer to this question will make no practical difference, but I'm
still curious.

I am trying to track down cases of abuse of access types and heap space.
I use a run-time call to get a stack trace, and then I start from the top
and work down looking for local variables that contain pointers but are
not cleaned up (Ada 83--no auto-finalize).  Since I didn't write the
code, I have to go to other files to check parameter modes when the items
in question are used for actuals.  I suppose the writer knew when he/she
wrote the call what the modes were, and had some idea of what the call
would do with the actuals.  Yet sometimes stuff both in and out of the
call makes me wonder.  (Like putting a non-null pointer on an out parameter,
or assigning null to the parameter within the call.)
More often than not, neither the formals nor the actuals were named in
a way that would provide a clue.

What do some of you experienced multi-language folks think would have been
the advantages or disadvantages of the following "alternate Ada" ?

procedure Do_Something ( This_Thing  : in     This_Type;
                         That_Thing  :    out That_Type;
                         Other_Thing : in out Other_Type );

Hypothetical call:

   A_Package.Do_Something ( This_Thing   => Voici,
                            That_Thing  <=  Voila,
                            Other_Thing <=> Aussi );
where the choice of [which kind of] arrow must match the parameter mode.

The writer of the call would not be able to avoid knowing the mode--but
is that necessarily a Good Thing?

The comparison operator would be "overloaded" but the context would make
it safe for the compiler, except when 'That_Thing' just happens to be
a local object, and a "<=" just happens to be defined to return the
expected type, and positional association is used.  Impossible in this
case--can't have That_Thing positional if This_Thing isn't.  But possible
in the following foolish code:

...

Formal : Boolean;
Actual : Boolean;

begin

  if "not" (Formal <= Actual) then ...

Anyway, the answer(s) won't change anything, but if things get slow on
comp.lang.ada and you don't have any work to do......

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Lang. Design Query (no practical value)

[Robert Dewar]

My taste is that it is not useful to indicate the parameter modes at
the call site. The names chosen and the abstraction, should make this
clear. I have never found it a problem. If you really wnat this kind
of information at the call site, you could adopt a convention of
encoding it into the names.

Note also that in the important case, which is the case of pointers,
you still do not know the "mode" of the thing you are pointing at (i.e.
whether the called procedure or functoin will simply read the designated
object, or whether it will modify it, so since you are not solving this
problem, I don't think the new syntax is worthwhile.

The reason this was dropped was that in general people agree with the
above point of view, no great mystery here!

Re: Lang. Design Query (no practical value)

[Robert A Duff]

In article <9608151648.AA07688@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>What do some of you experienced multi-language folks think would have been
>the advantages or disadvantages of the following "alternate Ada" ?
...
>   A_Package.Do_Something ( This_Thing   => Voici,
>                            That_Thing  <=  Voila,
>                            Other_Thing <=> Aussi );
>where the choice of [which kind of] arrow must match the parameter mode.

This feature was in an early version of Ada (or Green?) in 1980 or
thereabouts.  The symbols were ":=", "=:", and ":=:".  I thought it was
a good idea.  I don't know why it was dropped.

More recently, somebody suggest sticking "in" and/or "out" in the call
syntax, for the same purpose.

>The writer of the call would not be able to avoid knowing the mode--but
>is that necessarily a Good Thing?

It's a Good Thing, IMHO, for the reader to be able to tell this kind of
information syntactically, at the call site.

>The comparison operator would be "overloaded" but the context would make
>it safe for the compiler, ...

This is a kind of overloading that has never appeared in Ada, and should
not appear in Ada.  It introduces an unnecessary implementation
complexity.  Not to mention potential confusion for the user (who,
remember, might not have memorized all the types that have "<=" defines
for them!)  Your idea is a good one, but it should use different
symbols.

>Anyway, the answer(s) won't change anything, but if things get slow on
>comp.lang.ada and you don't have any work to do......

I always like discussing language design, even though I have work to do.
;-)

- Bob