Re: scheme set list function

[Aaron Hill]

On 2019-04-08 4:08 am, David Kastrup wrote:
> Aaron Hill <address@hidden> writes:
> > As such, procedures can have side effects where the objects that are
> > passed to such procedures may be modified.  Consider the 1+last!
> > procedure I showed that is not a macro itself, but it still has the
> > side effect of altering the list.
>
> It doesn't have "side effects".  It manipulates the given objects.

Yet that is the very definition of a side effect [1].

[1]: https://en.wikipedia.org/wiki/Side_effect_(computer_science)

To modify such an object which is outside your local scope falls into 
that category.  Remember a side effect is not automatically an 
"unintended" side effect which is quite dangerous.

To increment a value is to effect a change on the system.  And if that 
state affected is outside local scope, then it is by definition a side 
effect.  And such a procedure would *not* be a pure function.

> > However, if you were to (set! (car bar) ...) or (list-set! bar 0 ...),
> > then you could in fact alter the first element of the list that was
> > passed in.  (IIRC, you need SRFI-17 which defines setters for car and
> > its kin to be able to use the first form.)
>
> But that's not changing the passed value but changing the passed
> _object_, a cons cell.
>
> > That all said, I have often read that the idealistic functional
> > programmer should in general avoid procedures with side effects.  As
> > Harm pointed out, such side effects can be dangerous.  So in a way,
> > you could certainly be justified in pretending the system is
> > pass-by-value irrespective of the actual implementation.
>
> It is not a pretense.  Scheme is pass-by-value, period.  Some of those
> values may be mutable objects.  If you have an actual call-by-reference
> mechanism, it does not depend on the argument type whether or not you
> can change the argument.  And you'd be able to, say, change a cons cell
> to a vector instead of having to retain the original cons cell with its
> identity.

Okay, I think I see where I have gone wrong in my thinking.  I must be 
conflating pass-by-value and pass-by-copy.

In C, if you were to pass an integer to a function, that function gets a 
copy of the value on the stack.  You can of course modify it, but that 
would have no ability to effect a change to the original variable in the 
caller's scope.

Now let us pass a pointer to an integer to a function.  The function 
still gets a copy but this time it is of the memory address, not the 
data to which is points.  There is no means to effect any change to the 
original pointer passed in; but since both the caller's pointer and the 
function's pointer point to the same thing, they are able to collaborate 
and see each other's changes.

This seems to be a matter of semantics.  A pointer is itself just a 
number, a value in its own right.  And to pass a pointer is to 
pass-by-value.  But if our intention is that we want to pass an object 
via its memory address, then we are passing-by-reference.


-- Aaron Hill