Re: Circular dereference?

6 views
Skip to first unread message

Juerd

unread,
May 4, 2005, 9:20:47 AM5/4/05
to Juerd, Autrijus Tang, perl6-l...@perl.org
Juerd skribis 2005-05-04 15:18 (+0200):
> I'm still against any explict scalar dereferencing, so: fail,
> complaining about $x not being an arrayreference (not knowing how
> to handle &postcircumfix:<[ ]>).

Ehm :)

s/explicit/implicit/


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Juerd

unread,
May 4, 2005, 9:18:29 AM5/4/05
to Autrijus Tang, perl6-l...@perl.org
Autrijus Tang skribis 2005-05-04 21:13 (+0800):
> What should this do, if not infinite loop?
> my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;

I'm still against any explict scalar dereferencing, so: fail,
complaining about $x not being an arrayreference (not knowing how
to handle &postcircumfix:<[ ]>).

Autrijus Tang

unread,
May 4, 2005, 9:13:23 AM5/4/05
to perl6-l...@perl.org
What should this do, if not infinite loop?

my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;

Thanks,
/Autrijus/

Autrijus Tang

unread,
May 4, 2005, 9:38:58 AM5/4/05
to perl6-l...@perl.org
On Wed, May 04, 2005 at 06:24:34AM -0700, Larry Wall wrote:
> Yes, it doesn't immediately deref as an array, so it fails.

Oh. So autodereference is only one level? I got it all wrong
in Pugs, then. I wonder where I got that impression...

> Now @$x would infinite loop according to what I said a couple weeks
> ago, but maybe that's just the "go down one level" form that was
> requested at the time, and @$$x is the "go however many it takes" form.

Err, wait. So @$$x is different from @{${$x}}?

Thanks,
/Autrijus/

Larry Wall

unread,
May 4, 2005, 9:24:34 AM5/4/05
to perl6-l...@perl.org
On Wed, May 04, 2005 at 03:18:29PM +0200, Juerd wrote:
: Autrijus Tang skribis 2005-05-04 21:13 (+0800):

: > What should this do, if not infinite loop?
: > my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;
:
: I'm still against any explict scalar dereferencing, so: fail,
: complaining about $x not being an arrayreference (not knowing how
: to handle &postcircumfix:<[ ]>).

Yes, it doesn't immediately deref as an array, so it fails.

Now @$x would infinite loop according to what I said a couple weeks


ago, but maybe that's just the "go down one level" form that was
requested at the time, and @$$x is the "go however many it takes" form.

Larry

Larry Wall

unread,
May 4, 2005, 9:50:04 AM5/4/05
to perl6-l...@perl.org
On Wed, May 04, 2005 at 09:38:58PM +0800, Autrijus Tang wrote:

: On Wed, May 04, 2005 at 06:24:34AM -0700, Larry Wall wrote:
: > Yes, it doesn't immediately deref as an array, so it fails.
:
: Oh. So autodereference is only one level? I got it all wrong
: in Pugs, then. I wonder where I got that impression...

Oh, you probably got that impression from me. I probably even believe
it now and then. Maybe I'll believe it again tomorrow...

: > Now @$x would infinite loop according to what I said a couple weeks


: > ago, but maybe that's just the "go down one level" form that was
: > requested at the time, and @$$x is the "go however many it takes" form.
:
: Err, wait. So @$$x is different from @{${$x}}?

Nah, those should be equivalent, whatever sematics we come up with.

Larry

Thomas Sandlaß

unread,
May 4, 2005, 11:30:48 AM5/4/05
to perl6-l...@perl.org
Autrijus Tang wrote:
> What should this do, if not infinite loop?
>
> my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;

Hmm, after the my both $x and $y store an undef.
Then $x stores a ref to undef. Then $y stores
a ref to ref of undef. I see no circle.

Now let's look at $x = 1. I think it goes down
to the ref and let's it reference the value 1.
This is actually necessary because the ref that $x
"contains" has got other referees---that is the one
stored in $y. Thereafter $y sees the same value 1
through a chain of two references.

"Graphically" this looks as follows:

$y -> ref
\
$x ------> ref -> 1

So I think even $x = \$x should just do the right thing.
And that is not in any way different from $x = $x + 5.
The RHS is evaluated and the resulting value is stored
in $x.
--
TSa (Thomas Sandlaß)

Autrijus Tang

unread,
May 4, 2005, 11:41:33 AM5/4/05
to Thomas Sandla�, perl6-l...@perl.org
On Wed, May 04, 2005 at 05:30:48PM +0200, Thomas Sandla� wrote:
> Autrijus Tang wrote:
> >What should this do, if not infinite loop?
> >
> > my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;
>
> Hmm, after the my both $x and $y store an undef.
> Then $x stores a ref to undef. Then $y stores
> a ref to ref of undef. I see no circle.

Note that your explanation is completely different
from the Perl 5 semantics, which my impression was
that the same model is followed by Perl 6. To wit:

# Perl 5 code
my ($x, $y); $x = \$y; $y = \$x; print $$$$$$$$$$$x;

If the reference semantics changed drastically, please
reflect it prominiently in the relevant Synopsis. :)

Thanks,
/Autrijus/

Thomas Sandlaß

unread,
May 4, 2005, 12:00:37 PM5/4/05
to perl6-l...@perl.org
Autrijus Tang wrote:
> If the reference semantics changed drastically, please
> reflect it prominiently in the relevant Synopsis. :)

Unfortunately I don't feel entitled to do so. I'm
just an interessted bystander, not a member of the
design team.

Sorry.
--
TSa (Thomas Sandlaß)


Aaron Sherman

unread,
May 4, 2005, 12:40:23 PM5/4/05
to Thomas Sandlaß, Perl6 Language List
On Wed, 2005-05-04 at 11:30, Thomas Sandlaß wrote:
> Autrijus Tang wrote:
> > What should this do, if not infinite loop?
> >
> > my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;
>
> Hmm, after the my both $x and $y store an undef.
> Then $x stores a ref to undef. Then $y stores
> a ref to ref of undef. I see no circle.

Squint harder ;-)

Your mistake was here: "Then $x stores a ref to undef."

It does not. It stores a ref to $y, and I can prove it:

my($x,$y);
$x = \$y;
$y = 7;
say $$x;
$y = \$x;
say $$y; # ?!

If we agree that the first say should print 7, then we must conclude
that either we've changed the value of undef to 7, or we've created a
circular reference.

If we do not agree that the first say prints 7, then we have more
fundamental differences of understanding about how P5 works to figure
out before we can agree on how P6 should work.


--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback


Juerd

unread,
May 4, 2005, 12:31:24 PM5/4/05
to Thomas Sandlaß, perl6-l...@perl.org
Thomas Sandlaß skribis 2005-05-04 17:30 (+0200):

> > my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1;
> Hmm, after the my both $x and $y store an undef.
> Then $x stores a ref to undef. Then $y stores
> a ref to ref of undef. I see no circle.

No, again, please do not make the mistake of thinking VALUES have
identity. VARIABLES (containers) do. A reference points to a container,
never to a value directly. The undef in question is the undef value, not
the undef variable (which exists too).

This is something that doesn't change from Perl 5 to Perl 6.

Try in perl (5) the following code:

my ($x, $y);
my ($xx, $yy) = \($x, $y);

They're both undef, but their references are different.

There are names, containers and values.

Declaration and := bind names to containers.

Assignment copies values.

Containers aren't copied.

A reference points to a container.

A name points to a container.

A reference is a value.

The reference isn't to $y's container's value, but to the container.
Regardless of its value. It is also not to the name $y.

> So I think even $x = \$x should just do the right thing.

"The right thing" is the most vague way to describe semantics.

> And that is not in any way different from $x = $x + 5.
> The RHS is evaluated and the resulting value is stored
> in $x.

"$x = $x + 5" overwrites the value of $x's container with the old value
plus five. \$x is the same before and after. The value isn't stored in
$x, but in its container, to which $x is merely a name (implicit
reference).

Thomas Sandlaß

unread,
May 4, 2005, 2:38:51 PM5/4/05
to Perl6 Language List
Aaron Sherman wrote:
> Squint harder ;-)

I'm trying!


> If we agree that the first say should print 7, then we must conclude
> that either we've changed the value of undef to 7, or we've created a
> circular reference.

In my view of refs 7 is printed, indeed. But I've difficulty to understand
what you mean with "the value of undef". Undefinedness to me is the absence
of value. But as Larry argues, actual values that are some kind of soft or
weak exception are very usefull because they just travel along the flow of
control instead of disrupting it. Both exception and undef carry information
of what could not be achieved. I like that view, too. In that sense I'm
speaking of undef values like I speak of an integer value.

I think we agree that references are a level of indirection.
We also agree that variables are names that allow us to get
at---and here I think our views diverge---a box, cell or container
for values. So after resolving a name, we always have one level of
indirection from the cell to the value. To me a referencial value
is just such a thing without an entry in a namespace or symbol table.

And yes, Juerd and I have fundamentally different opinions of what
has got identity. To me only values can be identical. Cells are an
implementation vehicle to handle values.


> If we do not agree that the first say prints 7, then we have more
> fundamental differences of understanding about how P5 works to figure
> out before we can agree on how P6 should work.

I'm not argueing how Perl 5 works. My concern is about defining pratical
and usefull semantics for Perl 6. But as I said, I don't consider myself
authoritative. And I'm sorry, that I said "the right thing" when I meant
"avoid circular refs".

Regards,
--
TSa (Thomas Sandlaß)

David Storrs

unread,
May 6, 2005, 11:39:32 PM5/6/05
to Thomas Sandlaß, Perl6 Language List

On May 4, 2005, at 2:38 PM, Thomas Sandlaß wrote:

> Aaron Sherman wrote:
>> If we agree that the first say should print 7, then we must conclude
>> that either we've changed the value of undef to 7, or we've created a
>> circular reference.
>
> In my view of refs 7 is printed, indeed. But I've difficulty to
> understand
> what you mean with "the value of undef". Undefinedness to me is the
> absence
> of value.

In Perl (5 and 6) there is actually a value, 'undef'. That value can
be stored in variables, just like any other value. There is no real
fundamental difference between '7', 'foo', and 'undef'...they are all
values (although each has a slightly different set of meaningful
operations). As a community, we have decided that 'undef' means
something like "I don't know what this value is" and the perl engine
enforces that, but there is nothing implicit about undef that requires
it to mean that.


> I think we agree that references are a level of indirection.
> We also agree that variables are names that allow us to get
> at---and here I think our views diverge---a box, cell or container
> for values. So after resolving a name, we always have one level of
> indirection from the cell to the value. To me a referencial value
> is just such a thing without an entry in a namespace or symbol table.

Not quite. *values* never have entries in a namespace or symbol
table...e.g., there is no symbol table that stores
1,2,3...100000000000000, etc. You don't say "$x + number::integer::7"
in order to add 7 to $x. A reference is a value, just like an integer
or a string. It does not have a symbol table entry. It is, instead,
stored in a container. Containers that have names are called
"variables", containers that do not have names are (surprisingly
enough) "anonymous". So, in Perl 5, "$x = [ 1 ];" creates a reference
(a value) to an anonymous array (a nameless container) containing the
literal number 1 (a value) and stores it in $x (a named container).

So, if you want, you can say that $x is a single level of indirection
to get to its value...but, in the example above, its value is [ 1 ],
not 1. Therefore, you have another layer of indirection. The name
doesn't tell you anything about how many layers of indirection you're
going to get.


> And yes, Juerd and I have fundamentally different opinions of what
> has got identity. To me only values can be identical. Cells are an
> implementation vehicle to handle values.
>

It depends on how you define "identity", I suppose.

--Dks

Thomas Sandlaß

unread,
May 10, 2005, 1:02:45 PM5/10/05
to Juerd, perl6-l...@perl.org
Juerd wrote:
> No, again, please do not make the mistake of thinking VALUES have
> identity. VARIABLES (containers) do. A reference points to a container,
> never to a value directly.

I don't consider it a mistake. So, you dany identity to "fat" values
like database connections or GUI objects?

> This is something that doesn't change from Perl 5 to Perl 6.

Why?

> Try in perl (5) the following code:
>
> my ($x, $y);
> my ($xx, $yy) = \($x, $y);

Actually I still wonder how equal or different assignment
with = of a ref produced by \ is from binding with :=.
The second line above e.g. should produce a ref to a list
value (undef, undef), right? Then this value shall be used to
initializes the content of whatever the names $xx and $yy
refer to. So, why don't the references not just vanish and
we get to independent undef values stored in $xx and $yy?
I.e. do you expect $x = 5 have an effect on the value of $xx?


> There are names, containers and values.

I agree.


> Declaration and := bind names to containers.

I disagree. Names are a compile time concept and access to
the namepace level is restricted after compilation. Some
languages like C++ and Java actually compile the namespace
almost completely away. So Declaration is mostly a way to
talk to the compiler while := is a runtime operator.


> Assignment copies values.

I agree.


> Containers aren't copied.

I agree. Their content is retrieved and copied to a new container.


> A reference points to a container.

Well, can we agree that a reference is a means to retrieve a value?


> A name points to a container.

Yes, but see above for compile time.


> A reference is a value.

I agree.


> The reference isn't to $y's container's value, but to the container.
> Regardless of its value. It is also not to the name $y.

I don't see much use in pointing to a container because the interest
is in the value unless to want to go in an explicit pointer arithmetic
scheme like C++. Does \$v + 1 mean something different than $v + 1?
To me it does at most create a level of indirection that is traced to
the value when the args for + are prepared.

How about the following idea to distinguish between read and write
refs? I would actually call the former View!

$x = 3;
$y = 5;

$rr = \$y; # read ref (or view)
$wr := $x; # write ref

say $rr; # prints 5
$rr = 7;
say $y; # prints 5 because $rr doesn't trace the view but discards it
# as any other non-referential value

say $wr; # prints 3
$wr = 9;
say $x; # prints 9 because $wr traces down to lowest container/ref and
# redirects it (my view) or exchanges the value (juerd's view)

Comments?
--
TSa (Thomas Sandlaß)

Juerd

unread,
May 10, 2005, 1:57:59 PM5/10/05
to Thomas Sandlaß, perl6-l...@perl.org
Thomas Sandlaß skribis 2005-05-10 19:02 (+0200):

> Juerd wrote:
> > No, again, please do not make the mistake of thinking VALUES have
> > identity. VARIABLES (containers) do. A reference points to a container,
> > never to a value directly.
> I don't consider it a mistake.

That is a problem.

> So, you dany identity to "fat" values like database connections or GUI
> objects?

Objects are references to containers. Primitive values, like strings and
numbers are not objects. They can be used as objects, though.

Assignment copies. When that is a reference, the reference is copied. It
still points to the same thing. Thus, $obj2 = $obj1 DOES NOT clone, even
though $str2 = $str1 DOES clone the string.

Containers have identity. Objects are references to containers. The
identity of an object is that of the referred container, not the
container that holds the reference.

Database connections and GUI objects are objects, and as such have their
own containers, which have identities.

> > Try in perl (5) the following code:

> > my ($xx, $yy) = \($x, $y);
> Actually I still wonder how equal or different assignment
> with = of a ref produced by \ is from binding with :=.

t is because you lack understanding of the system of names,
containers and values that Perl uses. As long as you think values have
identity and containers are always implicit, you cannot understand the
difference between aliasing and referencing. Or the difference between 4
and $foo = 4, for that matter.

> The second line above e.g. should produce a ref to a list value
> (undef, undef), right?

List references do not exist (array references do, but that is entirely
besides the point). \($x, $y) in Perl 5 returns the same as (\$x, \$y).

I'm sorry I assumed you knew Perl 5, I'll try to explain my code next
time.

> Then this value shall be used to initializes the content of whatever
> the names $xx and $yy refer to. So, why don't the references not just
> vanish and we get to independent undef values stored in $xx and $yy?

Why should references "just vanish"? That's not a likely course of
action a reference will take. A reference only vanishes when something
else replaces it, or it is garbage collected.

> I.e. do you expect $x = 5 have an effect on the value of $xx?

No. $xx's value still points to the same container, the container that
$x also points to.

name : container : value
......:.............:..........
: :
$xx ----> SCALAR ----> (REF)
: : |
: +-------------+
: V :
$x ----> SCALAR ----> 5
: :
: :

Or, using the boxes metaphor, where each box is a container, and in it
is drawn its value, and names are outside of boxes

+- $xx +- $x
| |
V V
+-------------+ +---+
| reference -----> | 5 |
+-------------+ +---+

Now, if you do either $x-- or $$xx--, only the value of the container
previously holding 5 changes:

name : container : value
......:.............:..........
: :
$xx ----> SCALAR ----> (REF)
: : |
: +-------------+
: V :
$x ----> SCALAR ----> 4
: :
: :

boxes:

+- $xx +- $x
| |
V V
+-------------+ +---+
| reference -----> | 4 |
+-------------+ +---+

If $xx was an alias for $x, thus "$xx := $x" instead of "$xx = \$x", it
would be like this:

name : container : value
......:.............:..........
: :
$xx --------+ :
: | :
: V :
: SCALAR ----> 123
: ^ :
: | :
$x --------+ :
: :
: :

(I moved $x to another line to show that $x and $xx are both equal in
"rank": none is the "real" name, they're both real.)

boxes:

+- $x +- $xx
| |
V V
+---------+
| 123 |
+---------+



> > Declaration and := bind names to containers.
> I disagree.

Do you disagree that they do, or that they should?

Because they do do.

> Names are a compile time concept

Well, not strictly.

> and access to the namepace level is restricted after compilation.

Not at all, in Perl.

> Some languages like C++ and Java actually compile the namespace almost
> completely away.

Perl is not "some languages", and certainly not C++ or Java.

> So Declaration is mostly a way to talk to the compiler while := is a
> runtime operator.

Perl knows many runtimes, of which some are often called compile time.

> > A reference points to a container.
> Well, can we agree that a reference is a means to retrieve a value?

No. It's a means of pointing to a container. To get that container's
*value*, you need to dereference. Dereferencing can happen implicitly,
in Perl 6.

> >The reference isn't to $y's container's value, but to the container.
> >Regardless of its value. It is also not to the name $y.
>
> I don't see much use in pointing to a container because the interest
> is in the value unless to want to go in an explicit pointer arithmetic
> scheme like C++.

First of all, even if you do not see much use in it, stop ignoring the
simple fact that this is how Perl has always been.

If you're trying to change the way Perl handles these things, propose
the change. Don't continually mess up discussions in which current
semantics are assumed.

> Does \$v + 1 mean something different than $v + 1?

Certainly in Perl 5. In Perl 6, $v there may auto-dereference, which
effectively would mean they're the same. I am very strongly against
autodereferencing of scalars, though.

> $rr = \$y; # read ref (or view)

Reference. ($r --> [ reference-]-> [ $y's container ])

> $wr := $x; # write ref

Not a reference. ($wr --> [ $x's container ] <-- $x)

Reply all
Reply to author
Forward
0 new messages