Re: Circular dereference?
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ß)
Re: Circular dereference?
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.
Re: Circular dereference?
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...100, 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
Circular dereference?
What should this do, if not infinite loop? my ($x, $y); $x = \$y; $y = \$x; $x[0] = 1; Thanks, /Autrijus/ pgplOdMgUykiv.pgp Description: PGP signature
Re: Circular dereference?
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:[ ]). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Circular dereference?
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
Re: Circular dereference?
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
Re: Circular dereference?
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
Re: Circular dereference?
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ß)
Re: Circular dereference?
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/ pgpZv1yGV5leC.pgp Description: PGP signature
Re: Circular dereference?
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ß)
Re: Circular dereference?
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). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Circular dereference?
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 [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Circular dereference?
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ß)
