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
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, R
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 v
David Green writes:
> I guess my problem is that [1,2] *feels* like it should === [1,2].
> You can explain that there's this mutable object stuff going on, and I
> can follow that (sort of...), but it seems like an implementation
> detail leaking out.
The currently defined behaviour seems intuiti
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 e
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 on
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 t
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... (m
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
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 involv
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 tu
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 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 beli
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
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 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
cas
"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 ev
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
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 cour
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
>
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 _wh
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 str
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
implic
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 appe
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 interes
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
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.
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 v
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 o
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
uni
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 C and the
polymorphic semantics should probably be C.
Larry
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
: variabl
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 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 .
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 ===.
Coincidentally, I raised almost the same questions there a week
earlier, and had a brief discussion with audreyt about it, though
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
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 w
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
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 al
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 =
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 i
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
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
If we do have deep value equality checks, then "default" == and eq
are probably:
sub &infix:<==> ( $x, $y ) {
+$x === +$y;
}
sub &infix: ( $x, $y ) {
~$x === ~$y;
}
So that the compare-as-sometype behavior is retained from perl 5
wi
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 slot,
45 matches
Mail list logo
