David Green writes:
On 8/13/06, Smylers wrote:
Please could the proponets of the various behaviours being discussed
here share a few more concrete examples ...
OK,
Thanks for that. In summary, if I've understood you correctly, it's
that:
=:= two aliases to the same actual variable
David Green schreef:
===
...is equality-of-contents, basically meaning that the things you're
comparing contain the same [...] values.
How about strings; are normalized copies used with the === ?
http://www.unicode.org/faq/normalization.html
http://www.unicode.org/notes/tn5/
--
Affijn,
On 8/14/06, Smylers wrote:
David Green writes:
Thanks for that. In summary, if I've understood you correctly, it's that:
=:= two aliases to the same actual variable
=== one variable contains a copy of the other's actual contents
eqv both contain contents which represent the same thing
On July 14th Yuval Kogman wrote:
On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote:
I'm afraid I still don't get it.
Or rather, while I can manage to read an explanation of what one of
these operators does and see how it applies to the variables in the
examples next to it, I am
On 8/13/06, Smylers wrote:
Please could the proponets of the various behaviours being discussed
here share a few more concrete examples which start by explaning a
scenario in which there is a desire to do something, preferably one
that Perl 5 coders can identify with, and then show how
Way back on 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:19:24PM -0600, David Green wrote:
[...]
No, === is also deep. It's only shallower (or potentially shallower)
in the sense that it treats any mutable object node as a leaf node
rather than changing to snapshot semantics like
I think that Jonathan meant for his reply to my message to go to the
list, so I am including it in its entirety, in my reply.
At 11:23 PM -0700 7/13/06, Jonathan Lang wrote:
Darren Duncan wrote:
Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn't
Yuval Kogman writes:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs
=:=.
I'm afraid I still don't get it.
Or rather, while I can manage to read an explanation of what one of
these operators does and see how it applies to the variables in the
examples next to it, I am
On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote:
I'm afraid I still don't get it.
Or rather, while I can manage to read an explanation of what one of
these operators does and see how it applies to the variables in the
examples next to it, I am struggling to retain a feeling of _why_ I
Yuval Kogman writes:
On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote:
Or rather, while I can manage to read an explanation of what one of
these operators does and see how it applies to the variables in the
examples next to it, I am struggling to retain a feeling of _why_ I
would
Darren Duncan wrote:
Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
recommend having negated versions of all these various types of equality
tests. Eg, !== for ===, nev for eqv, etc. They would be used very
frequently, I believe (and I have even tried to do so), and of
Darren Duncan wrote:
Assuming that all elements of $a and $b are themselves immutable to all
levels of recursion, === then does a full deep copy like eqv. If at any
level we get a mutable object, then at that point it turns into =:= (a
trivial case) and stops.
( 1, 2.0, 3 ) === ( 1,2,3 )
Mark A. Biggar schreef:
Darren Duncan:
Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
recommend having negated versions of all these various types of
equality tests. Eg, !== for ===, nev for eqv, etc. They would be
used very frequently, I believe (and I have even tried
At 9:22 AM -0700 7/14/06, Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are
themselves immutable to all levels of
recursion, === then does a full deep copy like
eqv. If at any level we get a mutable object,
then at that point it turns into =:= (a trivial
Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are themselves immutable to all
levels of recursion, === then does a full deep copy like eqv. If at any
level we get a mutable object, then at that point it turns into =:= (a
trivial case) and stops.
( 1,
At 6:55 PM +0200 7/14/06, Dr.Ruud wrote:
say foo if $x !== $y;
into
say foo unless $x === $y;
And how about symmetry:
say foo unless $y === $x;
very unreliable.
Any equality or inequality operator is commutative, so it doesn't
matter whether you have $x and $y or $y and $x,
On Thu, Jul 13, 2006 at 10:56:59PM -0700, Darren Duncan wrote:
: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
: recommend having negated versions of all these various types of
: equality tests. Eg, !== for ===, nev for eqv, etc. They would be
: used very frequently, I
At 12:55 PM -0700 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:56:59PM -0700, Darren Duncan wrote (edited):
: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
: recommend having negated versions of all these various types of
: equality tests. Eg, !=== for ===, !eqv for
On Fri, Jul 14, 2006 at 09:22:10 -0700, Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are themselves immutable to all
levels of recursion, === then does a full deep copy like eqv. If at any
level we get a mutable object, then at
that point it turns into
Darren Duncan schreef:
Dr.Ruud:
say foo if $x !== $y;
into
say foo unless $x === $y;
And how about symmetry:
say foo unless $y === $x;
Any equality or inequality operator is commutative,
If $x and $y are not of the same type, and one or both of the involved
types has its own
On 7/14/06, David Green [EMAIL PROTECTED] wrote:
On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the
On Thu, Jul 13, 2006 at 10:19:24PM -0600, David Green wrote:
: On 7/13/06, Yuval Kogman wrote:
: So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
: It makes sense now, but I still feel that as far as ergonomics go
: this is not perfect.
:
: I think I understand it... (my
At 7:25 PM +0300 7/12/06, Yuval Kogman wrote:
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
snip
Coincidentally, I raised almost the same questions there a week
earlier, and had a brief discussion with audreyt about it,
On Thu, Jul 13, 2006 at 00:55:30 -0700, Darren Duncan wrote:
So, in the general case, it would seem best if the binary operator === was
just an ordinary method that each class provides, rather than requiring
classes to defined a .id. Or
in addition to this to help with performance, a .id
So, Larry assisted by Audrey explained the purpose of === vs eqv vs
=:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect. Then again, I trust that Larry's opinion is
probably better and at the very least more likely to be accepted
than mine ;-) [1]
So, this
On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote:
: [1] My preferred ergonomics:
:
: 1. eqv goes away
: 2. what was eqv is renamed to ===
: 3. === becomes =:=, which has a constant feel to it
: 4. =:= is rarely useful IMHO, so you can just type
:
On Thu, Jul 13, 2006 at 12:50:19PM -0700, Larry Wall wrote:
: Then $a eqv $b and $a leg $b both just default to a signature that selects
: everything.
Though arguably P5's string-forcing semantics should be Cleg and the
polymorphic semantics should probably be Ccmp.
Larry
At 5:36 PM +0300 7/13/06, Yuval Kogman wrote:
User defined types can choose on their own whether to override
=== and/or .id or not, and they would use their own knowledge of
their internal structures to do an appropriate
deep comparison. There is no need to try to generate some kind of
On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs
David Green wrote:
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs of == and eq, but I don't know what
to suggest instead (we're running short of combinations of = and : !))
Agreed.
So there are three basic kinds of comparison: whether the
On Thu, Jul 13, 2006 at 12:50:19 -0700, Larry Wall wrote:
On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote:
: [1] My preferred ergonomics:
:
: 1. eqv goes away
: 2. what was eqv is renamed to ===
: 3. === becomes =:=, which has a constant feel to it
: 4. =:= is
On Thu, Jul 13, 2006 at 21:55:15 -0700, Jonathan Lang wrote:
Apparently, there are _four_ basic kinds of comparison: the ones
mentioned above, and == (I believe that eq works enough like == that
whatever can be said about one in relation to ===, =:=, or eqv can be
said about the other). I'd
Yuval Kogman wrote:
Jonathan Lang wrote:
Apparently, there are _four_ basic kinds of comparison: the ones
mentioned above, and == (I believe that eq works enough like == that
whatever can be said about one in relation to ===, =:=, or eqv can be
said about the other). I'd be quite interested
At 10:36 PM -0700 7/13/06, Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn't
implicitly coerce its arguments to a particular type?
Yes, absolutely. The === takes 2 arguments exactly as they are,
without changing anything, and says if they are two
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
After a brief discussion we managed to formulate several questions that we feel
are slightly to totally unresolved.
1. what is .id on references? Is it related to the memory
If we do have deep value equality checks, then default == and eq
are probably:
sub infix:== ( $x, $y ) {
+$x === +$y;
}
sub infix:eq ( $x, $y ) {
~$x === ~$y;
}
So that the compare-as-sometype behavior is retained from perl 5
Jedai and I went through some of pugs current implementations. Here's a list of
what we expect the operators to return and what they currently do.
This does not exactly agree with S03 right now, but is our opinion.
Force into a type before comparing values:
42 == 42 - true, same numeric
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
*wave*
1. what is .id on references? Is it related to the memory slot, like refaddr()
in Perl 5?
That's something I'm
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 );
op(@foo, @bar)?
Is it going
On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:
Isn't that ~~?
Per S03:
Array Array arrays are comparablematch if $_ »~~« $x
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Not at all,
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into ~~, but without invoking code when it
shouldn't.
But it should! It's the smart match! If the rhs matches the code ref
(the code
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:
The other way to think about === would be that it tells you if its LHS
*could* be constant-folded onto its RHS (if it were constant for long
enough)
What is the benefit here?
Because of the word deep. Deep implies arbitrary work,
Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into ~~, but without invoking code when it
shouldn't.
But it should! It's the smart match! If the rhs
44 matches
Mail list logo
