Re: scope and/or parameters (beginner)

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <wcchfqkbddr.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> The rule in some other languages (eg Pascal and C) is
> different -- in those languages, a parameter acts just
> like a local variable, so you can modify it, and it
> doesn't affect the caller's copy.  That's error prone,
> which is why in Ada an 'in' mode parameter acts like a
> local *constant*.

To expand on Bob's point, there is a fundamental issue
here of binding. In Ada, a programmer knows that an IN
parameter is bound to the actual argument, so if you have
an IN parameter called Clunk, then throughout the code of
the procedure you know that Clunk is bound to this value.

In C or Pascal, if you see Clunk, it may or may not have
the value of the input parameter, you have to carefully
check the *dynamic* sequence of execution of the function
to see if there could have been any modifications.

Yes, it's slightly annoying to a writer who wishes to
minimize keystrokes to have to declare a variable where
a variable is needed, and initialize the variable with the
value of the parameter.

Too bad, we don't care about writers with slow fingers
in the Ada world. We are worried about the reader (e.g.
a maintenance programmer) coming to the program later,
and being able to make simple assumptions (in this case
that Clunk really is the input parameter) without
having to check.

For example, suppose we add a new rule to the interface.
It says, if all other verification tests pass, then the
parameter Clunk must be checked to make sure it does not
have the value 43, and if it does, then raise the
exception "End_Of_The_World".

This is a relatively easy modification, you just look
through the code to make sure you are past the validation
checks, and then you add:

    if Clunk = 43 then
       raise End_Of_The_World;
    end if;

You do nt have to worry about whether details of the
code you skipped reading carefully do or do not change
the value of Clunk.

A C programmer making the same choice would have two
approaches.

a) carefully check the code to see if clunk is modified.
This involves worrying about aliases (did someone do &
on clunk, and pass this to a routine that might use the
pointer to modify the value for example). Then if the
answer is no, put in the above code, with a big warning
message that no one must subsequently modify Clunk before
this point.

b) throw in an extra variable Clunk2, copy Clunk to Clunk2
at the start of the function. Put in a big warning that
Clunk2 should not be modified, and then check Clunk2 at
the appropriate point.

Which do you think would be chosen (I would guess neither,
C programmers (and programmers in general for that matter)
are not in the habit of putting big warnings in their code!

Robert Dewar


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own