At 11:16 PM -0600 8/16/06, David Green wrote:
On 8/15/06, Darren Duncan wrote:
At 2:51 PM -0600 8/15/06, David Green wrote:
[...]
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no rea
On 8/16/06, Agent Zhang <[EMAIL PROTECTED]> wrote:
On 8/17/06, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> Where can I find a pod2html that groks the p6 version of POD? I want
> to format my fresh-from-svn copies of the doc...
>
...
And there're also an online HTML version of the Perl 6 Spec
On 8/17/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
Generally speaking, the direct use of === is more for specialized
purposes, somewhat like the direct use of =:= is. If one can't tell
the difference between === and eqv, they most likely want snapshot
semantics anyway, and so might as well for
Just noticed this on line 474: "Variables with native types does not
support undefinedness"
S02 states that there is no ".length" method on Str's (or for cumulative
element length of Arrays); you have to ask explicitly for the units you
want to count . But then it goes on to define the StrPos and StrLen
types, which are unit-agnostic. So why not have a .length that returns
a StrLen?
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
-- Original message --
From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]>
> S03, lines 418-420: "[cmp] always returns C,
> C, or C (which numerify to -1, 0, or +1)."
>
> Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
> which case it would be cl
On 8/17/06, Darren Duncan wrote:
At 11:16 PM -0600 8/16/06, David Green wrote:
I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case
(regardless of Seq vs. Array -- I didn't t
On 8/17/06, Reed, Mark (TBS) wrote:
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
Maybe you could view it e
On Thu, Aug 17, 2006 at 11:27:21AM -0600, David Green wrote:
: However, what I'm wondering is whether Order::Same is "but true" and
: the others "but false"? (Which makes cmp in boolean context the same
: as eqv, but it seems to make sense that way.)
We should not be encouraging people to use c
I don't know if I've made this clear, but over the last few years I've
been treating "but True" and "but False" as design smells. They're
fine as a workaround for dire circumstances and uncooperative types,
but you'll not find me designing very many of the core interfaces to
use them, or other run
On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements therefore
On Thu, Aug 17, 2006 at 12:18:55PM -0600, David Green wrote:
: So perhaps what I'm looking for is more syntactic
: sugar for easily traversing nested data
: structures in different ways.
Quoth S03:
If that's not enough flexibility, there is also an C function
that can be passed addition
On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
>$a=[1, 2, [EMAIL PROTECTED];
>$c=[1, 2, [EMAIL PROTECTED];
>$d=[1, 2, [EMAIL PROTECTED];
>
>So $a, $c, and $d may all have the same *value*
>(or "snapshot", when evaluated all the way down
>through nesting and references), i.e. they
David Green wrote:
No, look at the example I've been using. Two arrays (1, 2, [EMAIL PROTECTED]) and (1,
2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents. "eqv" only tells
me whether they have the same value (when @x and @y are evaluated).
That's a different question --
I was just reading through S12, and it doesn't seem to ever actually
state that the default invocant name is "self". (Is it self? Or is
it $?SELF, which doesn't appear at all?) S12 mentions declaring an
explicit invocant with : in the method signature, and that it's
optional; and then later on
Author: larry
Date: Thu Aug 17 16:08:34 2006
New Revision: 3
Modified:
doc/trunk/design/syn/S04.pod
Log:
Some leave simplifications.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod
Author: larry
Date: Thu Aug 17 16:39:38 2006
New Revision: 5
Modified:
doc/trunk/design/syn/S06.pod
Log:
More old use of multiple invocant terminology changed to longnames.
Added mechanism for both short and long switch names.
Modified: doc/trunk/design/syn/S06.pod
==
Author: larry
Date: Thu Aug 17 16:45:20 2006
New Revision: 6
Modified:
doc/trunk/design/syn/S12.pod
Log:
Added explicit mention of "self" by suggestion of markjreed++.
Modified: doc/trunk/design/syn/S12.pod
==
--
On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote:
> As a lead-in, I should say that Synopsis 3 has a good and complete
> explanation of these matters and has had it for several weeks, in my
> opinion.
>
> Since you are wanting to compare two mutable Array, just use the eqv
> operat
On 8/16/06, Larry Wall <[EMAIL PROTECTED]> wrote:
: Is the output 01234 or 12345?
I'd say 01234 on the theory that the 3-arg loop is really saying:
$n = 0;
while $n < 5 {
NEXT { ++$n }
NEXT { print $n }
}
and also on the theory that block exiting blocks always run i
Quoth [EMAIL PROTECTED] ("Mark J. Reed"):
> On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
> > >$a=[1, 2, [EMAIL PROTECTED];
> > >$c=[1, 2, [EMAIL PROTECTED];
> > >$d=[1, 2, [EMAIL PROTECTED];
> > >
> > >So $a, $c, and $d may all have the same *value*
> > >(or "snapshot", when eval
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
> Subject: Re: NEXT and the general loop statement
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remembe
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
>
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remember a debate some time ago where some
> complained
在 2006/8/18 上午 3:31 時，Ben Morrow 寫到：
Just to make sure I've got all this straight:
=:= compares names
=== compares containers
eqv compares values
=:= evaluates both sides as lvalue -- that's VAR() -- and compare
them with ===.
=== evaluates both sides as rvalue and, for containe
On Thu, Aug 17, 2006 at 11:45:06PM -0400, Joe Gottman wrote:
> > -Original Message-
> > From: Luke Palmer [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 17, 2006 8:44 PM
> > To: Perl6 Language List
> >
> > Wasn't NEXT supposed to do something tricky, such as being mutually
> > exclus
26 matches
Mail list logo
