Re: Call by reference vs. call by value

[Felaco <bcf@swlpts1.ssd.ray.com>]

bobduff@world.std.com (Robert A Duff) writes:
> Felaco wrote:
> >One possibility that hasn't been explored is this: define the rule as
> >call-by-value *by default*, and give me a pragma or something to get
> >the more efficient call-by-reference behavior.  Then I would be forced
> >to be aware of the pitfalls.  It's not the greatest solution, but it
> >least it gives the programmer more control.
> 
> Yes, that's one reasonable solution.  It shouldn't be a pragma, but
> should use some sensible syntax.  Some Pascal compilers do something
> like this -- there are by-value parameters, and CONST parameters (which
> are by-reference, but still in-mode), and VAR parameters (which are
> by-ref/in-out).  Maybe CONST parameters are part of standard Pascal now;
> I don't know.  Anyway, this solution has some problems (passing of
> components of packed things, forcing the programmer to specify something
> that *usually* doesn't matter, ..)

I disagree with changing the syntax.  I feel that the pragma is the
least intrusive way of giving the programmer some control, but not
forcing the programmer to care when they wouldn't otherwise.  Another
even simpler idea is to dictate that the compiler issue a warning when
a call is made to a subunit with the same actual parameter used as an
'in' and an 'out' (or 'in out').  How hard would this be?

> The SPARK subset of Ada solves the problem by making sure you can't
> write code that can tell the difference between by-copy and by-ref.  In
> particular, exception handling is not allowed, and aliasing of
> parameters is not allowed.  This leads to a pretty restricted version of
> the language, though.

I keep seeing SPARK mentioned in this thread.  Although I don't think
I like the sounds of it, where can I get more info about this?  (Feel
free to send direct e-mail rather than post a response.)

dewar@cs.nyu.edu (Robert Dewar) writes:
> If you want to think more about this issue, worry about packed arrays
> too. Requiring call by reference would mean that ALL packed arrays have
> to be passed using general bit pointers, which would be unacceptably
> inefficient in the normal case where slices are not passed. Same
> thing for records, all records would have to be passed by bit address,
> just in case the record you are passing is a field in a rcord with a
> record rep clause.

That's a good question - just how does the compiler determine how to
pass array parameters where rep specs or packing applies?  Does it use
bit pointers, or does it just make a properly aligned copy and pass it
along?  If the LRM dictated that all arrays were passed by reference,
then the compiler could decide to use bit pointers (if the
architecture provided efficient means to do so) or it could just
resort to making a copy and passing a reference to it.  In the latter
case, the programming pitfall I am trying to avoid is impossible, but
the programmer would still know to program defensively because the
rule says arrays are passed by reference.  This is not great, but
slightly better.

I still think there is some merit to my suggestion, but I won't defend
it beyond that.  It just seems strange to me that the language
designers went to such lengths to restrict the usage of access types,
but they failed to address this type of programming error which I feel
is even more insidious.

-- 
-------------------------------------------------------------------------------
Chris Felaco                               Phone: x4631 (Raynet 444, Local 842)
Raytheon Company                                         Email: bcf@ssd.ray.com
-------------------------------------------------------------------------------