This may go without saying, but ...
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit with a =:= t
On Friday 14 July 2006 00:30, Darren Duncan wrote:
> This may go without saying, but ...
>
> If $a === $b means what I think it does, then I believe that a
> not-premature implementation optimization of === would be that it
> always $a := $b if it was returning true, so that any future === of
> $a
At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit w
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
Darren Duncan schreef:
> What I propose concerning non-premature === optimizing is a system
> where, at any time that two appearances of the same immutable value
> are compared with ===, they are immediately consolidated into a
> single appearance.
That should only be done voluntarily. A bit like
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
On Fri, Jul 14, 2006 at 00:30:20 -0700, Darren Duncan wrote:
> This may go without saying, but ...
...
This is a VM issue. It clarifies semantics, and the runtime VM may
choose to do this freely for simple values (but not for objects
which just pretend using .id).
In short: yes, the semantics al
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, 2006-07-14 at 00:08 +0300, Yuval Kogman wrote:
> Also, sometimes i am matching on behalf of my caller, this is very
> common in dispatch algorithms, or things like tree visitors:
>
> my @list = $tree.filter_children( $match ); # very generic and useful
It's really the fact that tha
Aaron Sherman schreef:
> given $_ {
>when $x {...}
> }
>
> or
>
> $_ ~~ $x
Can that be written as ".~~ $x"?
--
Affijn, Ruud
"Gewoon is een tijger."
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
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
On Fri, Jul 14, 2006 at 04:34:26PM +0200, Dr.Ruud wrote:
: Aaron Sherman schreef:
:
: > given $_ {
: >when $x {...}
: > }
: >
: > or
: >
: > $_ ~~ $x
:
: Can that be written as ".~~ $x"?
No, but you might just possibly get away with writing:
.infix:<~~>($x)
assuming that the $_.foo(
"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
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
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
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
Larry Wall schreef:
> Dr.Ruud:
>> Aaron Sherman:
>>> $_ ~~ $x
>>
>> Can that be written as ".~~ $x"?
>
> No, but you might just possibly get away with writing:
>
> .infix:<~~>($x)
>
> assuming that the $_.foo($x) SMD eventually fails over to foo($_,$x)
> MMD. But that doesn't seem to be much
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 tu
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 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
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
Author: larry
Date: Fri Jul 14 17:00:12 2006
New Revision: 10215
Modified:
doc/trunk/design/syn/S03.pod
Log:
Differentiate === from eqv and clarify semantics.
Redefine cmp and add leg operator for old semantics.
Add ! metaoperator.
Fix random typos.
Modified: doc/trunk/design/syn/S03.pod
===
Author: larry
Date: Fri Jul 14 17:15:46 2006
New Revision: 10216
Modified:
doc/trunk/design/syn/S03.pod
Log:
More types and such.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(ori
At 5:00 PM -0700 7/14/06, [EMAIL PROTECTED] wrote:
Author: larry
Date: Fri Jul 14 17:00:12 2006
New Revision: 10215
Modified:
doc/trunk/design/syn/S03.pod
Log:
Differentiate === from eqv and clarify semantics.
Redefine cmp and add leg operator for old semantics.
Add ! metaoperator.
Fix rando
27 matches
Mail list logo
