Re: identity tests and comparing two references [PATCH for S06 and A06]
On Tue, Apr 12, 2005 at 06:22:13PM +0200, Thomas Sandlaß wrote: I've edited the above syntax into S06 and A06. The two patches are attached but I don't know if you are the right one to sent them to. Whom should I sent such patches? I just saw you applying other patches as well. Applied, many thanks! Best is probably to send patches to perl6-language or perl6-compiler. Pm
Re: identity tests and comparing two references
Austin Hastings wrote: So if $$ref gives the 'all the way down' behavior, how do I get just one layer down dereferencing? How about: my XMLnode $x = parseXML( file.xml ); do_something( $x.down.down.down.item[17].up.up.body.down.down ); Details of class XMLnode and friends left as an excercise ;) BTW, with Parrot doing COW, value semantics is as efficient as explicit referencing while reading and with GC you don't have to care while writing. So go ahead and think about what your algorithm shall do instead of struggling with low level details. Only if the creation of new values and eventual GC of orphaned ones is really too expensive you need to add methods that handle in-place modification, or actually hand it down to COW/GC of more lightweight elements of your Sumo object :) -- TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Larry Wall wrote:
: Is a closure return type indicated with this siglet syntax, too?
:
: sub foo :(Str,Int) of :(Any) {...}
You would need :() only to group multiple siglets into a single type.
So an Any can stand on its own.
Ohh, interessting! I wanted to express a return value type that
is a sub that takes an Any as parameter. For you the syntax :()
is escaping into type specs like ::() is escaping into namespace.
I like this notion as well :)
So we have:
( term )
:( type )
::( name )
My intended declaration of foo could read:
sub foo :(Str,Int) returns :(Any) {...}
I also used returns not of for clarity. But of is a synomym for returns
and I find it's more in line with other---ahm---types of types! Actually
for type theorists, Ada and Pascal programmers and similar folk the : as
type indicator is not too far fetched. It even gives them:
my $x :( Int ); # var x : Int;
But how is the return type of the return type of foo specified?
Is that :(Any returns Int) and :(Any of Int)?
Or :(Any):(Int)?
Or inside :( Any of :(Int) )?
We are making progress, but not there yet, I think.
--
TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Larry Wall wrote: Yes. It should complain that = is not a valid type signature. Any foo (or foo:...) followed by ... should be parsed as a single term selecting the function that MMD would dispatch to given that type signature. And I guess it's not allowed to have interspersed whitespace unless one uses the dot forms? And my interpretation as operator = needs the whitespace OTOH. infix = some words # my interpretation of the typo foo .signature # OK? infix: .operator .signature # OK? infix:operator .signature # or at least this? Whitespace before the : is also not allowed, or is it? infix : .operator .signature The dot forms would allow alignment when dumping a complete multi with every sig on a seperate line. Or for all infix operators, etc. Is foo$bar a symbolic access or a syntax error? How about foo$bar = sub ... # ... here means appropriate def, not the yada op or just with foo$bar := sub ...? Regards, -- TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Thomas Sandla writes: Larry Wall wrote: Yes. It should complain that = is not a valid type signature. Any foo (or foo:...) followed by ... should be parsed as a single term selecting the function that MMD would dispatch to given that type signature. And I guess it's not allowed to have interspersed whitespace unless one uses the dot forms? And my interpretation as operator = needs the whitespace OTOH. infix = some words # my interpretation of the typo foo .signature # OK? I'm beginning to think that angle brackets are too overloaded here. The qw angles are really growing on me, and now whenever I see angles I see a quoting construct. Putting something that's not quoted inside them seems like it will be visually confusing (and just thing what vim will have to do to tell the difference). We could make it one, so that it's: infix:+.Complex Complex Instead of with commas, but then you can't attach anything special to the types, so I think it's best if we just ditch altogether for this purpose. But then what replaces it?The first thing that came to me was just to use a method: infix:+.variant(Complex, Complex); The method approach has some other advantages, like the ability to add another method: my $code = infix:+.dispatch($a, $b); # what code would we call # with $a and $b? Or we could use square brackets, since square bracketing types just selects a type, but doesn't do anything to it. But especially because this only applies to multimethods, I like the method approach the best. Luke
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 04:31:08PM +0200, Thomas Sandlaß wrote: : Larry Wall wrote: : Yes. It should complain that = is not a valid type signature. : Any foo (or foo:...) followed by ... should be parsed as a single : term selecting the function that MMD would dispatch to given that : type signature. : : And I guess it's not allowed to have interspersed whitespace unless : one uses the dot forms? And my interpretation as operator = needs : the whitespace OTOH. : : infix = some words # my interpretation of the typo Yes. : foo .signature # OK? Yes, unless we take Luke's suggestion. : infix: .operator .signature # OK? Yes, UWTLS. : infix:operator .signature # or at least this? Yes, UWTLS. : Whitespace before the : is also not allowed, or is it? : : infix : .operator .signature Not allowed, EIWTLS. :-) : The dot forms would allow alignment when dumping a complete multi : with every sig on a seperate line. Or for all infix operators, etc. Indeed, EIWTLS. : Is foo$bar a symbolic access or a syntax error? How about Neither, it would be a siglet that declares a scalar variable where a simple Scalar would do, I think. : foo$bar = sub ... # ... here means appropriate def, not the yada op : : or just with : : foo$bar := sub ...? I think we should just say no at that point. Larry
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 10:07:33AM -0600, Luke Palmer wrote:
: Thomas Sandlaß writes:
: Larry Wall wrote:
: Yes. It should complain that = is not a valid type signature.
: Any foo (or foo:...) followed by ... should be parsed as a single
: term selecting the function that MMD would dispatch to given that
: type signature.
:
: And I guess it's not allowed to have interspersed whitespace unless
: one uses the dot forms? And my interpretation as operator = needs
: the whitespace OTOH.
:
: infix = some words # my interpretation of the typo
:
: foo .signature # OK?
:
: I'm beginning to think that angle brackets are too overloaded here. The
: qw angles are really growing on me, and now whenever I see angles I see
: a quoting construct. Putting something that's not quoted inside them
: seems like it will be visually confusing (and just thing what vim will
: have to do to tell the difference).
Yes, same here. But it's not an expression either. It's a signature,
and the only other delimiter we have prior art for is (Str $s, Int $i)
in sub declarations. But we can't use bare parens for obvious reasons
that were not obvious enough to keep me from falling into the trap
in at least one Apocalypse. :-)
: We could make it one, so that it's:
:
: infix:+.Complex Complex
:
: Instead of with commas, but then you can't attach anything special to
: the types, so I think it's best if we just ditch altogether for this
: purpose.
:
: But then what replaces it?The first thing that came to me was just
: to use a method:
:
: infix:+.variant(Complex, Complex);
:
: The method approach has some other advantages, like the ability to add
: another method:
:
: my $code = infix:+.dispatch($a, $b); # what code would we call
: # with $a and $b?
:
: Or we could use square brackets, since square bracketing types just
: selects a type, but doesn't do anything to it. But especially because
: this only applies to multimethods, I like the method approach the best.
But a method *evaluates* its arguments, which you generally don't want
in this case. Sometimes you do, so it's fine to have a method behind
whatever syntax we choose, but it can't very well be the default
without some kind of sig quoting. I think it's time to break out
the colon again and use something like:
infix:+:(Complex, Complex);
or
foo:(Str,Int)
for ordinary functions. If it gets really popular people might
even start writing:
sub foo :(Str,Int) {...}
Larry
Re: identity tests and comparing two references
HaloO Larry,
you wrote:
for ordinary functions. If it gets really popular people might
even start writing:
sub foo :(Str,Int) {...}
I like it, but that could mean it will not become popular :))
And this is also nice:
sub foo :(Str,Int) of Str {...}
Is a closure return type indicated with this siglet syntax, too?
sub foo :(Str,Int) of :(Any) {...}
Will there be an announcement if this syntax becomes official?
BTW, would it be a good idea that you make such decisions known on p6a?
--
TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
On Mon, Apr 04, 2005 at 06:50:11PM +0200, Thomas Sandlaß wrote: : Juerd wrote: : And will Perl 6 reference values rather than their containers, that is: : will \$foo differ when $foo gets a new value, just as in Python id(foo) : changes after foo += 1? : : Depends on the definition of the semantics of 'Ref of Scalar of Any' : versus 'Scalar of Any' versus 'Ref of Any' versus 'Scalar of Ref of Any'. : My question was actually about the language level definition of *chains : of references*! : : 1) Is the referene creation done with \, := and implicit in scalar context? :Or do \ and := differ? And what's different with ::=? Taking the questions in reverse order, ::= differs from := only in forcing immediate evaluation and binding at compile time. I don't think \ and := differ very much--in fact, at one time aliasing was going to be done with: \$foo = \$bar; But as in many other areas, we've chosen to differentiate operators rather than overload existing ones. That's why we have =:= as well. I don't quite understand your first question. The left side of := implies reference context, but the right side only implies scalar context, so @foo and %bar automatically assume \, while $foo does not, but is assumed to already contain a reference. At least that's how I'm thinking of it this week. : 2) Is derefencing still done with $ chains where you have to know how far :to go? I think the common case with chains of references is that you either want the beginning of the chain or the end. So I think we'll probably go with ref coalescing behavior. : Is $$$foo still valid Perl 6 syntax? Sure, it's just the extra $'s are no-ops. :-) Basically, we have $$ref follow the ref list to the actual object. $refignore the fact that this is a ref unless context forces it. Ordinary scalar and list context never force a deref. Numeric and string contexts do force a deref, unlike in Perl 5. Also, boolean context! That's why we say that refs are no longer guaranteed to be true in Perl 6. : 3) How are Refs dispatched in comparison to Scalars, Arrays and Hashes? $ref.foo() is one of those contexts that forces a deref. The only way to call methods on the Ref itself is through var($ref), or whatever it's called today. : Here is another attempt to pose my question with - depicting an : indirection. : After the declarations with my we have two chains: : : $four - $three - $two - $one - 1 : $five - 5 : : Now what does $four = 4 mean? Dump the chain from $three downwards : and end up with : : $four - 4 : $five - 5 Yes. : or go all the way down and just rebind $one and dumping the value 1 : : $four - $three - $two - $one - 4 : $five - 5 No. : The next question was about how far down $$four goes and how rebinding : at that level works. If it goes one down and rebinds there we get: : : $two - $one - 4 : $four - $three - $five - 5 $$four goes all the way down to something that is not a ref. : BTW, Parrot could collapse chains of reference in a GC run : or as side effect of identity checks. That would be convenient. : I certainly hope we still have mutable values by design and : : In my head mutable value and constant variable sound funny. : : : Is your view of the world like Python or like Perl 5? : : More like an any-junction of all languages supported by Parrot :) My view is that the current lexical scope is allowed to impose any view on reality that it chooses. If you want a lexical scope that always forces != to coerce both sides with +, that's fine. It's just probably not the default, since we'll rely on MMD to choose standard Perl semantics where appropriate. : Values have no identity in Perl 5. Containers (variables, named or : anonymous) do. That also means that even though $foo = 5 and $bar = 5, : \$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo) : == id(bar), but I don't like that at all. : : Once again \$foo != \$bar just means a dispatch to infix:«!=»Ref,Ref : which might need to be different for PerlRef and PythonRef if the latter : exists at all. The difficult thing for the Parrot folks is the mixed case! : The homogenous cases are up to the languages. But for the mixed case some : meta language level has to define semantics or the languages have to adapt : from the inside out by explicit foreign knowlegde. Doubtless there is room to do both, as long as the language gets the override over global policy. I know Perl probably wants to break ties by coercing other language's scalars with implicit +, ~, and ? where the naive Perl programmer would expect it. $a + $b is not going to do string concatenation in Perl unless *both* strings are foreign, and then it's probably up to the global policy. And a pretty good argument can be made for *never* doing string concatenation with + in Perl. If the global policy is specific enough about semantics, then it will distinguish concatenation from addition independently of any language's
Re: identity tests and comparing two references
Larry Wall skribis 2005-04-06 11:10 (-0700): $$ref follow the ref list to the actual object. my $foo; my $bar = \$foo; my $quux = \$bar; my $xyzzy = \$quux; How then, with only $xyzzy, do you get $bar? $$xyzzy would follow until $foo. I don't like this at all. $ref.foo() is one of those contexts that forces a deref. The only way to call methods on the Ref itself is through var($ref), or whatever it's called today. This is weird. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 07:22:48PM +0200, Thomas Sandlaß wrote:
: HaloO Larry,
:
: you wrote:
: for ordinary functions. If it gets really popular people might
: even start writing:
:
: sub foo :(Str,Int) {...}
:
: I like it, but that could mean it will not become popular :))
: And this is also nice:
:
: sub foo :(Str,Int) of Str {...}
:
: Is a closure return type indicated with this siglet syntax, too?
:
: sub foo :(Str,Int) of :(Any) {...}
You would need :() only to group multiple siglets into a single type.
So an Any can stand on its own.
: Will there be an announcement if this syntax becomes official?
Paint it official unless someone can come up with a good counterargument.
: BTW, would it be a good idea that you make such decisions known on p6a?
p6a is for political announcements, not technical. :-)
Things actually become official when they get put into synopses.
Unfortunately, I don't have much time to edit synopses much these days.
No billionaires have written me into their will lately (or if they
have, they haven't pegged out yet), so for now I have to earn my
own way out of the financial hole I'm in, and that takes a lot of
time away from Perl. I'm just barely keeping up with the email,
and I'm not getting anything done on the translator. Sorry.
If you want to help, earn a billion dollars and write me into your
will. And then peg out. Nothing personal. :-)
Larry
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 08:24:23PM +0200, Juerd wrote: : Larry Wall skribis 2005-04-06 11:10 (-0700): : $$ref follow the ref list to the actual object. : : my $foo; : my $bar = \$foo; : my $quux = \$bar; : my $xyzzy = \$quux; : : How then, with only $xyzzy, do you get $bar? $$xyzzy would follow until : $foo. I don't like this at all. You can't get at $bar anyway. You can only get at its thingy. Otherwise you're talking symbolic refs. : $ref.foo() is one of those contexts that forces a deref. The only way : to call methods on the Ref itself is through var($ref), or whatever : it's called today. : : This is weird. Chains of scalar refs are weird. At least, they're weird to anyone but a C programmer or a Perl 5 programmer. We're trying to re-Huffmanize the weirdness of Perl 6. Larry
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 11:30:35AM -0700, Larry Wall wrote: If you want to help, earn a billion dollars and write me into your will. And then peg out. Nothing personal. :-) Larry Darn. So far, I'm, 0 for 3 on that plan. However, I promise that item two will follow very shortly in time from item one. No promises about the delay between items two and three, though; nor any assurance of my ever achieving item one (it's failure, in fact, is virtually assured). --
Re: identity tests and comparing two references
Larry Wall wrote:
On Wed, Apr 06, 2005 at 08:24:23PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-06 11:10 (-0700):
: $$ref follow the ref list to the actual object.
:
: my $foo;
: my $bar = \$foo;
: my $quux = \$bar;
: my $xyzzy = \$quux;
:
: How then, with only $xyzzy, do you get $bar? $$xyzzy would follow until
: $foo. I don't like this at all.
You can't get at $bar anyway. You can only get at its thingy. Otherwise
you're talking symbolic refs.
: $ref.foo() is one of those contexts that forces a deref. The only way
: to call methods on the Ref itself is through var($ref), or whatever
: it's called today.
:
: This is weird.
Chains of scalar refs are weird. At least, they're weird to anyone but
a C programmer or a Perl 5 programmer. We're trying to re-Huffmanize
the weirdness of Perl 6.
How do you deref 'n' levels in such a chain?
My current project is a n-way merge of some very large {i.e., O(10**8)
records} XML datasets. One way I'm getting performance is by using
scalar reference chains to avoid copies. I am also recasting the type of
some of the objects used, so I need to be able to reach in 'one' level,
as well as 'all' the levels. Currently, I have to know the length of the
chain, but it's a constant at any layer so that's not a problem.
So if $$ref gives the 'all the way down' behavior, how do I get just
one layer down dereferencing?
=Austin
Re: identity tests and comparing two references
On Wed, Apr 06, 2005, Larry Wall wrote:
I think it's time to break out
the colon again and use something like:
infix:+:(Complex, Complex);
or
foo:(Str,Int)
for ordinary functions. If it gets really popular people might
even start writing:
sub foo :(Str,Int) {...}
Just so I can keep things straight in my head...
Would this last instance be the same as
sub foo (Str,Int) {...}
i.e., is the colon optional? Or does it become mandatory?
Or is it indicating something else that I'm not seeing?
FWIW, just to give an example of what the syntax can look like, in S06
the lines
woof ::= barkDog.assuming :pitchlow;
pine ::= barkTree.assuming :pitchyes;
would become
woof ::= bark:(Dog).assuming :pitchlow;
pine ::= bark:(Tree).assuming :pitchyes;
Pm
Re: identity tests and comparing two references
Larry Wall skribis 2005-04-06 11:37 (-0700): : my $foo; : my $bar = \$foo; : my $quux = \$bar; : my $xyzzy = \$quux; : How then, with only $xyzzy, do you get $bar? $$xyzzy would follow until : $foo. I don't like this at all. You can't get at $bar anyway. You can only get at its thingy. Otherwise you're talking symbolic refs. If Perl 6 is really to stay Perl, then can't is wrong. This is a very basic thing that should have equally basic syntax. There must be a way to get at $bar, because otherwise $bar's properties cannot be accessed. The var() thing, or whatever it will be spelled eventually, must exist for a reason: sometimes you want the reference. For the same reason, the reference at any level should be reachable, to be able to set its properties. Or, and that's what I'm concerned about more, to assign it a new value. And of course there must be some way to translate Perl 5 code. Chains of scalar refs are weird. At least, they're weird to anyone but a C programmer or a Perl 5 programmer. I have always found chains of scalar references to be very easy to use and understand, even when I first learned about them. I cannot imagine that they are weird to anyone, and have in the years that I've been helping people out on Perl Monks and in several IRC channels, never seen anyone express a negative opinion about them. References are kepts very simple in Perl 5 and that's what makes them easy to use. The difference between references and aliases works very well, and keeps the separation of identifiers, containers and values explicit, superficial and clear. Implicit dereferencing where no ambiguity can be, like with arrays and hashes, is fine, but IMO implicitly dereferencing scalars fees terribly wrong. It would feel less wrong if Array and Hash were subtypes (or whatever it's called) of Scalar, as Str and Num are, but then I'd start to want a non-Perl name for Perl 6 again, because the language would just not be Perl anymore. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
On Wed, 2005-04-06 at 14:37, Larry Wall wrote: On Wed, Apr 06, 2005 at 08:24:23PM +0200, Juerd wrote: : Larry Wall skribis 2005-04-06 11:10 (-0700): : $$ref follow the ref list to the actual object. : : my $foo; : my $bar = \$foo; : my $quux = \$bar; : my $xyzzy = \$quux; : : How then, with only $xyzzy, do you get $bar? $$xyzzy would follow until : $foo. I don't like this at all. You can't get at $bar anyway. You can only get at its thingy. Otherwise you're talking symbolic refs. I'm not sure I understand what symbolic means in this context. Can someone explain? I'm specifically confused because I thought that: unary:\ Given a parameter, create a new value of type Ref, make it refer to the operand and then return the newly created object. This, it turns out is my delusion because neither S03 nor A03 define such an operator (though it's used in examples a few times in both, and it is given a precedence). So, what specifically does unary:\ do? If it does indeed create a new object (value if you will), then why is it that we would never want to modify that object? What if I want to add a mixin, for example: $r = \$a but Ref::Weak; Now, someone gets a ref to $r, and wants to call a method defined in Ref::Weak. How should they do that? -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: identity tests and comparing two references
On Wed, Apr 06, 2005 at 02:43:55PM -0500, Patrick R. Michaud wrote:
: On Wed, Apr 06, 2005, Larry Wall wrote:
: I think it's time to break out
: the colon again and use something like:
:
: infix:+:(Complex, Complex);
:
: or
:
: foo:(Str,Int)
:
: for ordinary functions. If it gets really popular people might
: even start writing:
:
: sub foo :(Str,Int) {...}
:
: Just so I can keep things straight in my head...
:
: Would this last instance be the same as
:
:sub foo (Str,Int) {...}
:
: i.e., is the colon optional? Or does it become mandatory?
: Or is it indicating something else that I'm not seeing?
It would be optional.
: FWIW, just to give an example of what the syntax can look like, in S06
: the lines
:
: woof ::= barkDog.assuming :pitchlow;
: pine ::= barkTree.assuming :pitchyes;
:
: would become
:
: woof ::= bark:(Dog).assuming :pitchlow;
: pine ::= bark:(Tree).assuming :pitchyes;
Yep, somethin' like that...
Larry
Re: identity tests and comparing two references
Juerd wrote: Thomas Sandlaß skribis 2005-04-04 18:50 (+0200): In particular what does infix=Scalar of Ref of Ref of Int,Int do? Depends. What does it mean? :) Specifically, what is infix, what is =? Ups, a missing : warps this to a completly different meaning! Comparing a coderef infix with the comparison operator = to the word list 'Scalar of Ref of Ref of Int,Int'. I tried to ask what infix:=Scalar of Ref of Ref of Int,Int does. This is the assignment infix operator = for 'Scalar of Ref of Ref of Int' on the lhs and Int on the rhs. BTW, does the parser have a change to detect this typo? About the rest of the mail I'll try to rant tomorrow. -- TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
On Tue, Apr 05, 2005 at 06:38:43PM +0200, Thomas Sandlaß wrote: : Ups, a missing : warps this to a completly different meaning! : Comparing a coderef infix with the comparison operator = : to the word list 'Scalar of Ref of Ref of Int,Int'. : : I tried to ask what infix:=Scalar of Ref of Ref of Int,Int : does. This is the assignment infix operator = for 'Scalar of Ref : of Ref of Int' on the lhs and Int on the rhs. : : BTW, does the parser have a change to detect this typo? Yes. It should complain that = is not a valid type signature. Any foo (or foo:...) followed by ... should be parsed as a single term selecting the function that MMD would dispatch to given that type signature. Larry
Re: identity tests and comparing two references
Juerd wrote: my $four := three; Assuming you meant $three instead of three. Indeed. Sorry. my $five = 5; $four = 4; # $one == 4 now? No, $four (and thus $three, which it is bound to) is now 4. $three is a reference, which is a value, which is now *replaced* with the new value. OK. Then you need to define the behaviour of referential values. In particular what does infix=Scalar of Ref of Ref of Int,Int do? I get from your remarks that you intend to treat it exactly like 'Scalar of Ref of Any' without dispatching to 'Ref of Int'. That means creating a new value 'Ref of Int' from the rhs, binding the Scalar and the Ref to it or some such. Is that so? Are we going to walk the path of inefficiency where $foo++ is really actually literally just $foo = $foo + 1, throwing away the old variable, assigning a new one? Heck, no! The $foo++ means postfix:++( $foo ) the second is infix:=Any( infix:+Any,Int( $foo, 1 ) ) either dispatched at runtime or optimized at compile if possible. How efficient that is compared to each other I don't know. And will Perl 6 reference values rather than their containers, that is: will \$foo differ when $foo gets a new value, just as in Python id(foo) changes after foo += 1? Depends on the definition of the semantics of 'Ref of Scalar of Any' versus 'Scalar of Any' versus 'Ref of Any' versus 'Scalar of Ref of Any'. My question was actually about the language level definition of *chains of references*! 1) Is the referene creation done with \, := and implicit in scalar context? Or do \ and := differ? And what's different with ::=? 2) Is derefencing still done with $ chains where you have to know how far to go? Is $$$foo still valid Perl 6 syntax? 3) How are Refs dispatched in comparison to Scalars, Arrays and Hashes? Here is another attempt to pose my question with - depicting an indirection. After the declarations with my we have two chains: $four - $three - $two - $one - 1 $five - 5 Now what does $four = 4 mean? Dump the chain from $three downwards and end up with $four - 4 $five - 5 or go all the way down and just rebind $one and dumping the value 1 $four - $three - $two - $one - 4 $five - 5 The next question was about how far down $$four goes and how rebinding at that level works. If it goes one down and rebinds there we get: $two - $one - 4 $four - $three - $five - 5 BTW, Parrot could collapse chains of reference in a GC run or as side effect of identity checks. I certainly hope we still have mutable values by design and In my head mutable value and constant variable sound funny. Is your view of the world like Python or like Perl 5? More like an any-junction of all languages supported by Parrot :) Values have no identity in Perl 5. Containers (variables, named or anonymous) do. That also means that even though $foo = 5 and $bar = 5, \$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo) == id(bar), but I don't like that at all. Once again \$foo != \$bar just means a dispatch to infix:«!=»Ref,Ref which might need to be different for PerlRef and PythonRef if the latter exists at all. The difficult thing for the Parrot folks is the mixed case! The homogenous cases are up to the languages. But for the mixed case some meta language level has to define semantics or the languages have to adapt from the inside out by explicit foreign knowlegde. Regards, -- TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Thomas Sandlaß skribis 2005-04-04 18:50 (+0200): In particular what does infix=Scalar of Ref of Ref of Int,Int do? Depends. What does it mean? :) Specifically, what is infix, what is =? 'Scalar of Ref of Any' without dispatching to 'Ref of Int'. That means References and aliasing should have nothing to do with types, except for checking. That is, even my Scalar $foo := my Int $bar should let $foo =:= $bar and \$foo == \$bar. 1) Is the referene creation done with \, := and implicit in scalar context? A reference points to a variable the same way a name does. Only the level at which these exists is different, but that brings along a lot of different thinking. A name is visible in the source, a reference is an unmentioned value. The difference between my $foo = \$bar; #1 and my $foo := $bar; #2 is that in #1, $$foo =:= $bar, and in #2, $foo =:= $bar (assuming =:= does NOT autoderefence, and this again makes clear why that'd be a bad idea). In English: in #1, the value of $foo is a reference that points to the container that is known as $bar, and in #2, $foo itself is the same thing as $bar, with both names pointing to the same container. Or do \ and := differ? And what's different with ::=? They differ. ::= is like :=, but at compile time rather than runtime. I'm not sure what the benefit of this is, but I imagine it speeds things up and saves a few BEGIN blocks. 2) Is derefencing still done with $ chains where you have to know how far to go? Is $$$foo still valid Perl 6 syntax? I should hope so! Here is another attempt to pose my question with - depicting an indirection. After the declarations with my we have two chains: I don't understand how your chains relate to the code you posted before. I certainly hope we still have mutable values by design and In my head mutable value and constant variable sound funny. Well, in Perl, values and variables have always been exactly the same thing. That is, $foo is as much a scalar as the thing that is created for the number 3. The big difference is that variables are mutable and literal values are read-only. I would like to avoid the word constant because that, in Perl 5 jargon, is an inlineable subroutine. We're used to calling scalars that have a name or are explicitly referenced variables, and scalars that just are there, like what subroutines return or what is in source code literally, values. But in fact, the value is somewhere INSIDE the scalar. $foo = $bar; # copies $bar's value to $foo's value $foo = \$bar; # creates a reference to $bar's scalar and stores it # in $foo's value $foo = 3; # copies 3's value (the integer three) to $foo's # value $foo = \3; # creates a reference to 3's scalar and stores it in # $foo's value After $foo = \3, $$foo is immutable because 3 is immutable. However, after $bar = 3, $bar is mutable because not the variable 3, but only its value was copied. The read-only flag, which is part of the scalar, is left out of the copying process. (Note that for simplicity's sake, I'm talking of value as a single thing, while in Perl (at least Perl 5), a scalar can have several values all at once, the best known being dualvars: string and number. A scalar's value can be string, number, reference, glob or undef. (Should you really care, then note that undef itself is a special scalar, which, would you take away its readonly flag, would just as easily hold the string forty-two.)) Once again \$foo != \$bar just means a dispatch to infix:«!=»Ref,Ref which might need to be different for PerlRef and PythonRef if the latter exists at all. I hope variables have the semantics of the language they're used in, and values are copied to another interpreter's variables as needed. Otherwise in order to use a library written in, for example, Python, you would have to know how variables work in that language. Bluntly put, that'd suck. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
James Mastros skribis 2005-04-01 22:48 (+0200):
$x = 42;
$a = \$x but false;
$b = \$y but blue;
$a =:= $b ???
Even without the buts, that is:
$x = 42;
$a = \$x;
$b = \$x;
I strongly believe that $a =:= $b must be false. Assignment copies! $a
=:= $b should be true only if $a and $b are the same variable
themselves, as can be accomplished by a simple $a = $b or by passing $b
as an argument to a closure somehow, like in given $a - $b { ... }.
If =:= has nothing to do with :=, it shouldn't look like it that much.
If it tests reference equality, possibly referencing non-references, it
should be spelled =\= instead, although I really question the practical
use of such operator.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
Larry Wall [EMAIL PROTECTED] wrote: : On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: : : In P6, an object is a data-type. It's not a reference, and any member : payload is attached directly to the variable. Well, it's still a reference, but we try to smudge the distinction in P6. A reference as a Perl5 reference or just as a C pointer or a Parrot PMC? newclass cl, Foo # create new Foo class - 0 attributes $P0 = new Foo # make a new Foo instance $P1 = $P0 # both PMCs refer to the same object now $P1.meth()# same as $P0.meth() $P2 = clone $P0 # 2 distinct objects now $P3 = new Undef assign $P3, $P0 # same leo
Re: identity tests and comparing two references
On Sat, Apr 02, 2005 at 11:06:01AM +0200, Juerd wrote: : Is your view of the world like Python or like Perl 5? Them's fightin' words. :-) : Values have no identity in Perl 5. That's slightly not true, insofar as Perl 5 distinguishes hash keys by value (albeit filtered through stringification). : Containers (variables, named or : anonymous) do. That also means that even though $foo = 5 and $bar = 5, : \$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo) : == id(bar), but I don't like that at all. On the other hand, it would be nice to have an operator that tells you if two things would be considered the same hash thing if handed to a hash of shape(Any). That's how I think of =:=. If that's more like Python and less like Perl 5, I don't care. I'm trying to make Perl 6 like Perl 6, not like anything else. Objects are by default unique, but any particular class of objects (including value types) is allowed to define its own idea of uniqueness. Unique identity is precisely what we're looking for in a hash key, whether we stringify it or not. Larry
Re: identity tests and comparing two references
On Sat, Apr 02, 2005 at 11:22:43AM +0200, Leopold Toetsch wrote: : Larry Wall [EMAIL PROTECTED] wrote: : : On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: : : : : In P6, an object is a data-type. It's not a reference, and any member : : payload is attached directly to the variable. : : Well, it's still a reference, but we try to smudge the distinction in P6. : : A reference as a Perl5 reference or just as a C pointer or a Parrot PMC? In that context, I just meant somebody's got a pointer to it somewhere, if only in the symbol table, though it could also be in a PMC. As I mentioned in a recent message, Perl 6's notion of identity is class based. Perl5 refs are not really objects in that sense of having an identity. If $foo contains a reference to something else, you have to work harder to get at the container $foo rather than object $foo points to. By default, any OO operation is going to deref it, and that includes asking it for its identity, or asking its class to compare two of its objects for identity. Does this make sense? The only application I see for typed references is to tunnel object references through some other language so that that language sees the reference as an object of its type, but if it calls back into your language, you get your original object reference back. I'd classify that as a necessary evil, but one I'd prefer to hide from stock Perl 6 programmers. Larry
Re: identity tests and comparing two references
On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: What I want to be able to do is compare two references to see if they point to the same thing, in this case an object, but in other cases perhaps some other type of thing. Let's be clear about the difference between P5 and P6 here. In P5, an object was actually a reference with special magic that indicated that it was also tied to a package. In P6, an object is a data-type. It's not a reference, and any member payload is attached directly to the variable. So, comparing references to objects isn't all that common in P6, though it could certainly happen. Now, back to the concept of identity comparison... I would expect that you could do this: $ref1 ~~ $ref2 The table in S4 doesn't have an entry for Any ~~ Reference, but my guess is that that's just an oversight, as it seems to fit into the flow nicely. More generally, I see no direct way to tell if two values have the same storage (the same PMC in Parrot), so you might have to do something P5ish: \$a ~~ \$b
Re: identity tests and comparing two references
On Thu, Mar 31, 2005 at 11:46:22PM -0800, Darren Duncan wrote: : So, what is the operator for reference comparison? The =:= operator is almost certainly what you want here. Larry
Re: identity tests and comparing two references
Sam Vilain writes: Darren Duncan wrote: Now I seem to remember reading somewhere that '===' will do what I want, but I'm now having trouble finding any mention of it. So, what is the operator for reference comparison? As someone who wrote a tool that uses refaddr() and 0+ in Perl 5 to achieve the same thing, I agree with the need for such an operator. I think that =:= compares *lexical* identity is fairly clearly spelled out in S03. However, we need a way to compare *value* /identity/ (not equality or equivalence), without being subject to overloading etc. I'm pretty sure that =:= does what you want. If you have two scalar references, you might have to spell it like this: $$x =:= $$y And binding can't be overloaded[1], so you don't have to worry about that. Luke [1] Or maybe it can, but like the prefix operator in C++, only people who really know what they're doing will overload it.
Re: identity tests and comparing two references
: On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: On Fri, Apr 01, 2005 at 08:04:22AM -0500, Aaron Sherman wrote: : : What I want to be able to do is compare two references to see if they : point to the same thing, in this case an object, but in other cases : perhaps some other type of thing. : : Let's be clear about the difference between P5 and P6 here. In P5, an : object was actually a reference with special magic that indicated that : it was also tied to a package. : : In P6, an object is a data-type. It's not a reference, and any member : payload is attached directly to the variable. Well, it's still a reference, but we try to smudge the distinction in P6. : So, comparing references to objects isn't all that common in P6, though : it could certainly happen. : : Now, back to the concept of identity comparison... I would expect that : you could do this: : : $ref1 ~~ $ref2 No, ~~ will deref any explicit references and smart match against what is referenced. That's part of the intentional smudging. : The table in S4 doesn't have an entry for Any ~~ Reference, but my : guess is that that's just an oversight, as it seems to fit into the flow : nicely. That would be going back to the P5 way of thinking. The ~~ operator doesn't try to guess whether the user meant references to refer to themselves or their referent. It always assumes the referent. Note that when you say @foo ~~ @bar it's actually passing two array references to ~~, for instance, since they're in scalar context. : More generally, I see no direct way to tell if two values have the same : storage (the same PMC in Parrot), so you might have to do something : P5ish: : : \$a ~~ \$b Wouldn't work. Ends up doing the same as $a ~~ $b. Anyway, that's what =:= is there for. Larry
Re: identity tests and comparing two references
On Fri, Apr 01, 2005 at 08:39:52AM -0700, Luke Palmer wrote: : I'm pretty sure that =:= does what you want. If you have two scalar : references, you might have to spell it like this: : : $$x =:= $$y Unnecessary, I think. I want $x =:= @y to tell me whether the reference in $x is to the same array as @y. Larry
Re: identity tests and comparing two references
On Fri, 2005-04-01 at 10:46, Larry Wall wrote: On Fri, Apr 01, 2005 at 08:04:22AM -0500, Aaron Sherman wrote: : In P6, an object is a data-type. It's not a reference, and any member : payload is attached directly to the variable. Well, it's still a reference, but we try to smudge the distinction in P6. Hrm... ok, I'm a bit confused, probably because I'm thinking in terms of Parrot. In Parrot, an object PMC is not a reference, it's of some object type and contains fields directly in the PMC for any member data. There's also a vtable which tells you everything you need to know about its methods. So you're saying that P6 will only manipulate Parrot-level object PMCs via references? If so, sorry, I just didn't realize that. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: identity tests and comparing two references
At 7:37 AM -0800 4/1/05, Larry Wall wrote: On Thu, Mar 31, 2005 at 11:46:22PM -0800, Darren Duncan wrote: : So, what is the operator for reference comparison? The =:= operator is almost certainly what you want here. Larry Thanks to everyone for their answers. Last night I started coding with =:= by default since it was the best self-documenting option I could see, then lacking a definitive answer. From what I've read of your responses, this seems to have been the right choice. So I will assume that =:= is the definitive answer until the official docs decide to unambiguously say otherwise. -- Darren Duncan
Re: identity tests and comparing two references
Larry Wall skribis 2005-04-01 7:47 (-0800): : $$x =:= $$y Unnecessary, I think. I want $x =:= @y to tell me whether the reference in $x is to the same array as @y. But my $foo; my $bar := $foo; my $baz = \$foo; $foo :=: $bar; # true $foo :=: $baz; # also true?! $bar = 1; # updates $foo $baz = 2; # does not update $foo IMO, :=: should not auto(de)reference. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
Juerd skribis 2005-04-01 22:35 (+0200): $foo :=: $bar; # true $foo :=: $baz; # also true?! IMO, :=: should not auto(de)reference. s:g/:=:/=:=/ Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
Thomas Sandlaß skribis 2005-04-01 23:37 (+0200): Juerd wrote (with substitution applied): IMO, =:= should not auto(de)reference. So you expect $bar to contain value 2 and detach from $foo? No. But if you said $baz instead of $bar, then yes. How would one then reach the value in $foo? With $$baz? Assuming you did mean $baz in the previous line, yes. And for longer chains of referene with a corresponding number of $ on the front? But IIRC that was obviated in Perl6. Exactly. Because an array in scalar context is automatically referenced, and an arrayref in array context is automatically dereferenced, that implicity can exist. But a reference IS a scalar, and having scalars reference or dereference in scalar context automatically is madness. And if we're saying that an array is a scalar as much as a string or a number is, then why are values mutable, do scalars not have three different sigils and do things automatically convert without the intervention of lists? If =:= tests variable sameness, then it should do that literally in order to both be useful and look like :=. For reference equality you can still use \FOO == \BAR (I assume). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
HaloO Juerd,
you wrote:
Thomas Sandlaß skribis 2005-04-01 23:37 (+0200):
So you expect $bar to contain value 2 and detach from $foo?
No. But if you said $baz instead of $bar, then yes.
Ohh sorry, I mis-read your mail as talking about chains of
references: $baz to $bar to $foo to 2. The last step could
also be direct storage. Then my question was if an assignment
is forwarded along this chain or if a ref is somehow manipulating
it's target directly. Consider:
my $one = 1;
my $two := $one;
my $three = \$two; # same as := ? was actually your question, or not?
my $four := three;
my $five = 5;
$four = 4; # $one == 4 now?
$$four := $five;
say $three; # prints 5?
then why are values mutable, do scalars not have three different sigils
and do things automatically convert without the intervention of lists?
Values are immutable in the abstract. That means 3 is always 3. Only
variables
change (reference to) value, hence the name. An object that is not referenced
and objects that just reference each other are garbage collected! For simple
values the reference is optimised into direct storage if possible. These two
things are the implementation of conceptually immutable values.
By introducing a finite
subtype Example of Array where { is shape(0..9) of Bool };
you have 1024 possible immutable values which could be pre-allocated
and then referenced as needed. For less restricted types you get so many
possible values that other implementation strategies are needed :)
Calling a method through a variable conceptually produces a new value
of the object type in question which in turn is implemented by changing
the object in place for practical reasons.
If =:= tests variable sameness, then it should do that literally in
order to both be useful and look like :=. For reference equality you can
still use \FOO == \BAR (I assume).
In my view of the world =:= checks for identity of values. Equality could
hold for non-identical objects. E.g. a complex number object with imaginary
part 0 could be considered equal to a real number with the value of the
real part of the complex number:
my Complex $complex = (3.2, 0);
my Num $real = 3.2;
$complex =:= $real # false
$complex == $real # true
The above would of course be implemented by installing apropriate multis
for infix:== from the Complex class. Overloading =:= OTOH will be hardly
necessary nor usefull.
--
TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Larry Wall wrote: On Fri, Apr 01, 2005 at 08:39:52AM -0700, Luke Palmer wrote: : I'm pretty sure that =:= does what you want. If you have two scalar : references, you might have to spell it like this: : : $$x =:= $$y Unnecessary, I think. I want $x =:= @y to tell me whether the reference in $x is to the same array as @y. $x = 42; $a = \$x but false; $b = \$y but blue; $a =:= $b ??? If it's true, then the =:= operator is pretty useless -- two things that are =:= to each-other can have very different semantics. If it's not, then there needs to be some other way to tell. $$a =:= $$b feels sane to me. So does $a == $b. I generally don't like it when things half-smudge important differences. Either there should be no difference between a reference and a referent, or there should be. We shouldn't try to hide important truths. (This is why I don't like CGI.pm's HTML generation, for example -- it makes you feel like you don't need to know HTML, when you do.) -=- James Mastros
Re: identity tests and comparing two references
James Mastros wrote: $x = 42; $a = \$x but false; $b = \$y but blue; Assuming you meant \$x in the last row we are dealing with three values: 42 but true 42 but false 42 but blue Which are not identical but equal. The first value is not necessarily implemented that way because the boolean value can be calculated on demand. And $a and $b none the less manage to change the value in $x when new values are assigned to them, and these can be retrieved via $x. If you meant true not blue in the last line than $b =:= $x. $a =:= $b ??? If it's true, then the =:= operator is pretty useless -- two things that are =:= to each-other can have very different semantics. If it's not, then there needs to be some other way to tell. $$a =:= $$b feels sane to me. So does $a == $b. I think =:= shall supersede the $ chains in front of refs by always dereferencing through to value level and accumulating traits while doing so. Usually you don't even know how many levels of indirection there are. I generally don't like it when things half-smudge important differences. Me neither. -- TSa (Thomas Sandlaß)
Re: identity tests and comparing two references
Darren Duncan wrote:
Now I seem to remember reading somewhere that '===' will do what I want,
but I'm now having trouble finding any mention of it.
So, what is the operator for reference comparison?
As someone who wrote a tool that uses refaddr() and 0+ in Perl 5 to
achieve the same thing, I agree with the need for such an operator.
I think that =:= compares *lexical* identity is fairly clearly spelled
out in S03. However, we need a way to compare *value* /identity/ (not
equality or equivalence), without being subject to overloading etc.
Of course, actually comparing two `ref' or `Ref' objects for pointing
to the same place is achieved via `==' (or, if === is used, ${$ref1} ===
${$ref2} or the P6 equivalent :) )
Sam.
