Re: scheme memory address

[David Kastrup]

Gianmaria Lari <address@hidden> writes:

> On Tue, 9 Apr 2019 at 11:13, David Kastrup <address@hidden> wrote:
>
>> Gianmaria Lari <address@hidden> writes:
>>
>> > On Tue, 9 Apr 2019 at 10:45, David Kastrup <address@hidden> wrote:
>> >
>> >> Gianmaria Lari <address@hidden> writes:
>> >>
>> >> > Suppose I write
>> >> >
>> >> >
>> >> > #(define x '(1 2 3))
>> >> >
>> >> >
>> >> > is there any way in scheme to print the memory address where x is
>> >> pointing
>> >> > to? (where is allocated the first element of the list)
>> >>
>> >> What do you need it for?  If it is for identification, (hashq x
>> >> 1000000000) should usually do a reasonably good job.
>> >>
>> >
>> > I tried, it looks working. (Yes, it's for identification)
>> >
>> > And is there any way to print the memory address of x? (If I remember
>> > correctly was something like &x in c++).
>>
>> object-address maybe.  But it's not like you can use it for anything.
>
>
> If I didn't make any mistakes, this code print the "address" of the first
> element of the list x and the "address" of the first element pointed by the
> parameter "lst" of the "foo" function.

This is Scheme, not C.  1 would not have an address anyway since it is
an immediate value (self-represented).  And you are not printing the
address of the first element of the list but you are printing the
address of its cons cell.

> \version "2.21.0"
> #(define x '(1 2 3))
> #(define (foo lst) (display (hashq lst 1000000000)))
>
> #(display (hashq x 1000000000))#(newline)
> #(foo x)
>
>
> The two instructions
>
>
> #(display (hashq x 1000000000))#(newline)
> #(foo x)
>
>
> print the same value because foo is called with x as argument and x and lst
> refer to the same address.

This is mostly nonsense since it tries to assign some C specific meaning
to Scheme values.

> I wanted to print the address of the variable x and then the address
> of the parameter lst just to show that x and lst have different
> address (so x is passed by value. I could infer the same assigning to
> lst a new value and see that at the exit of the function x didn't get
> update).

And that's complete nonsense since it tries to infer internals like
function passing semantics from purported internals.  Scheme semantics
are not defined by machine-level C analogies but by the Scheme standard.
The whole data and memory model and its management is completely
different to that of C (even though Guile implements it using C and some
fairly weird stack and heap scanning techniques).

If you are trying to interpret Scheme-provided functions as authoritive
proof about the implementation, you are deluding yourself.

> I hope I didn't say nothing wrong.

It's more in the "not even wrong" category.  The behavior of a Scheme
interpreter is determined by the standard.  The kind of stuff you try to
infer is not up to the implementation, so trying to deduce anything from
what you think you can derive about the implementation is putting the
cart before the wrong horse.

-- 
David Kastrup