On Fri, Sep 12, 2008 at 11:33 AM, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
> In SMOP, I'm probably going to presume that everything needs to be lazy,
> then even:
>
> my @o = grep { /\d+/ } =$*IN;
> my @a = (1,2,(3,4,@o));
> my @b = (1,2,(3,4,@a));
Can only one array "have" the iterator? If not,
Qui, 2008-09-11 às 12:13 -0700, Larry Wall escreveu:
> And I guess the fundamental underlying constraint is that a list cannot
> be considered immutable unless its feeds can be considered immutable,
> at least in some kind of idempotent sense. This conflicts with the
> whole point of reactive prog
Hi Larry,
# from Larry Wall
# on Thursday 11 September 2008 12:13:
>So when you put something into a list context, some of the values
>will be considered "easy", and some will be considered "hard".
>The basic question is whether we treat those the same or differently
>from a referential point of
* Larry Wall <[EMAIL PROTECTED]> [2008-09-11 21:20]:
> As a first shot at that definition, I'll submit:
>
> 1 .. $n # easy
> 1 .. *# hard
>
> On the other hand, I can argue that if the first expression is
> easy, then the first $n elements of 1..* should also be
> considered easy, a
On Tue, Sep 09, 2008 at 08:50:02AM -0700, Larry Wall wrote:
: At the moment the design of Perl 6 (unlike certain FP languages) is
: that any dependence on the *degree* of laziness is erroneous, except
: insofar as infinite lists must have *some* degree of laziness in order
: not to use up all your
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
The second example actually modifies the object stored in the variable
'@a'. And that is a different issue.
I disagree. The assignment operator, as opposed to the binding operator
(:=) is an operator called on the Array object. It is the
Ter, 2008-09-09 às 10:10 -0500, Patrick R. Michaud escreveu:
> I think my question can be best understood by example -- what
> does the following produce?
> my @a = 1,2,3,4,5;
> for @a { .say; @a = (); }
The problem actually becomes more evident with
my @a = 1,2,3,4,5;
for @a { .say;
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Since Larry said that single assignment semantics is the ideal
we should strive for, I would opt for the iterator being unaffected
by the assignment to @a. When this happens the singly assigned
former content of @a is snaphot by the iterator.
My take on it:
The 'for' loop does bind $_ to alias each item of the list in turn.
But, "the list" is not synonymous with the variable named @a. However,
the = operator operates on "the list" itself, not the container,
replacing the elements in the existing Array (or whatever) object. So,
HaloO,
Patrick R. Michaud wrote:
My question is whether the change to @a inside the for loop
affects the iterator created at the beginning of the for loop.
Since Larry said that single assignment semantics is the ideal
we should strive for, I would opt for the iterator being unaffected
by the
On Tue, Sep 09, 2008 at 10:10:04AM -0500, Patrick R. Michaud wrote:
: I think my question can be best understood by example -- what
: does the following produce?
:
: my @a = 1,2,3,4,5;
: for @a { .say; @a = (); }
:
: My question is whether the change to @a inside the for loop
: affects th
11 matches
Mail list logo
