Re: Call by reference vs. call by value

["Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>]

Peter Amey <pna@ERLANG.PRAXIS.CO.UK> writes:
>This is another Ada feature well covered by the SPARK subset.  The rules
>of SPARK (which are checked by the SPARK Examiner) prohibit all cases
>of aliasing where program meaning might be affected by the parameter
>passing mechanism used. A SPARK program has copy-in, copy-out semantics
>regardless of the compiler used to compile it.
>
    While I understand the interest in making language mechanisms
    secure and predictable, I sometimes wonder about things like this
    reference/value debate. It seems like a solution desparately
    seeking a problem.

    My experience with software bugs (especially in Ada) is that the
    overwhelming bulk of them are some version of the computer doing
    what you told it to do, not what you meant for it to do. (The
    implementer got the logic wrong) Most forms of semanitc induced
    errors are the kinds of things caught by the compiler (assigning
    reals to integers without explicit conversion, uninitialized
    variables, etc.) Those few weird "corner-case" bugs that fall into
    the category of "the LRM said it was 'implementation dependent'
    and my implementation bit me on the butt" happen so infrequently
    (although are annoyingly difficult to find!) as to not be worth
    the speed penalties imposed by "absolutely provable secure"
    implementations.

    I'd favor passing parameters by reference (for speed) over copy
    mechanisms because in the practical world of "the way programmers
    *really* program", my experience is thus: 1) You almost never see
    code (in the real world) where parameter passing mechanisms cause
    the problems (id est, where compiler "A" would have got it right
    and compiler "B" got it wrong) 2) Most (Ada) compilers are pretty
    good at finding the bulk of the parameter-passing problems no
    matter what the implementation mechanism is through forms of
    static analysis. (They're also pretty smart about figuring out
    what's the *optimal* way to pass the parameters, depending on data
    types.)

    I think we've learned by now that it doesn't help a language to be
    syntactically/semantically "perfect" (curing all the "Language
    Lawyer" problems) at the expense of being slow, cumbersome and
    late to market.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Government is not reason. It is not eloquence. It is a force.
    Like fire, a dangerous servant and a fearful master."

        --  George Washington
===============================================================================