Re: scheme set list function

[David Kastrup]

Aaron Hill <address@hidden> writes:

> 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.

The object is not outside the local scope.  It has been passed to the
function.  You are confusing duration and scope.  Scheme objects have no
scope and no implied duration (they exist as long as you can reference
them), bindings have a scope.

>> 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.

Scheme passes by value.  It never copies.  The value of an object is its
identity.  The value of atoms is inherent and constant.  That makes
stuff like floating point numbers icky.  And since arbitrary precision
integers were implemented, they are also icky.  With "icky" meaning that
there might be some identity sticking to them or not, depending on
whether they happen to be atoms or not.

> 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.

Scheme has no pointer concept.  If you try conflating low-level
languages with high-level languages, you'll end up with non-sensical
statements comingling language features with implementation details.

> 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.

C is strictly call-by-value.  C++ has the reference concept that muddies
up things considerably because references (not in the original ARM C++
but in its subsequent evolution) have lots of separate semantics and
specific conversions and invariants.

> 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.

That's what you get by confusing the mechanisms of a low-level language
with the semantics you can achieve with them.

It's like saying a toolbox is able to turn a human into a hammer.

-- 
David Kastrup