Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
Newsgroups: comp.lang.icon
Subject: Re: var params
Message-ID: <1989Sep22.120000.13561@rpi.edu>
Date: 22 Sep 89 12:00:00 GMT
References: <1027@m3.mfci.UUCP> <10746@dasys1.UUCP>
Distribution: comp
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 36

In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes:
> Passing by reference is considered by most language feature as dangerous. It
> allows a function to change the value of a variable without the user
> realizing. If you came back to your program years later, will you remember
> all the side effects?

One must program ones procedures which use pass by reference such that side
effects will be obvious.

> The problem is that you can end up with p(a)+a <> a+p(a). If p's
> parameter is passed by reference, and p changes the value of a,
> it makes a difference which gets done first.

One of my personal styles is to avoid using a procedure which returns a
value (other than some kind of return code) in combination with pass by
reference parameters. The result is that the construct p(a) + a should not
occur.

> If you want to return a bunch of values from one function, why not return a
> list?

This might in general be fine, but there have been comments about the int86()
function for MS-DOS Icon which returns a list. It is a little slower because
of this, also in certain programs (which are probably using int86() to speed
things up) there is heavy use of int86() which then causes needless garbage
collections.

Of course in this instance one doesn't need special pass by reference since
Icon structures are always passed by reference.



Frank Filz
Center For Integrated Electronics
Rensselaer Polytechnic Institute
vicc@unix.cie.rpi.edu