for loop and streams
dul...@widd.de
I did some tests with the new for loop and don't understand some of the results. Perhaps this is just due to some warts in the implementation at the moment.
When looping over two lists of different length, the shorter stream shall give undefs, when it has come to the end of the list, AFAIK.
So this code:
@s1 = (11, 12, 13, 14);
@s2 = (21, 22, 23);
for @s1, @s2 -> $a {
print $a, "\n";
}
gives:
11
12
13
14
21
22
23
as expected. But
@s1 = (11, 12, 13, 14);
@s2 = (21, 22, 23);
for @s1; @s2 -> $a {
print $a, "\n";
}
gives:
11
21
12
22
13
23
It should give:
11
21
12
22
13
23
14
and something like 'Use of uninitialized ...' if warnigs were implemented.
Am I wrong?
Sean O'Rourke
> Hi folks!
>
> I did some tests with the new for loop and don't understand some of
> the results. Perhaps this is just due to some warts in the
> implementation at the moment.
Yes. I personally think it makes more sense, in a language that allows
infinite and/or lazy lists, to use the length of the shorter of the two
streams, so that's what I did. When I implemented this, I had forgotten
the Apocalypse passage mandating the other behavior. You're welcome to
change it if you want ;).
/s
Paul Johnson
If I recall correctly, which I probably don't, there was a question at
YAPC::Europe (or maybe it was the Perl 6 Mini::Conference) as to what
the shorter array would return. The answer, from Larry or Damian, was
that it might return undef or maybe it would keep returning its last
value.
Is that sufficiently vague?
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
John Williams
Exegesis 3 says:
"This works for all unary and binary operators, including those that are
user-defined. If the two arguments are of different lengths, the operator
Does What You Mean (which, depending on the operator, might involve
padding with ones, zeroes or undef's, or throwing an exception)."
~ John Williams
Sean O'Rourke
Not vague enough, because the current implementation manages to miss the
broad side of that semantic barn...
Different operators doing different things sounds awful to me, because it
makes it hard to predict what will happen, because new operators will have
to be able to control what they do with their operands, and because new
types of "array-like" operands will have to tell operators how to treat
them. Blech.
Maybe treating lazy and/or infinite data structures as "infinitely short"
for this purpose would capture most of what we mean, so hype(A,B) would
take the longer of two finite lengths, the "more finite" of a finite and
an infinite length, and infiniti for two infinite operands.
Of course, this still doesn't account for what kind of extension makes
most sense for a given operand/operator pair. It seems to me that
anything more complex than "undef" (which is consistent with out-of-bounds
array accesses) would be a nightmare to get right.
/s
John Williams
> Different operators doing different things sounds awful to me, because it
> makes it hard to predict what will happen, because new operators will have
> to be able to control what they do with their operands, and because new
> types of "array-like" operands will have to tell operators how to treat
> them. Blech.
>
> Maybe treating lazy and/or infinite data structures as "infinitely short"
> for this purpose would capture most of what we mean, so hype(A,B) would
> take the longer of two finite lengths, the "more finite" of a finite and
> an infinite length, and infiniti for two infinite operands.
Sounds reasonable.
> Of course, this still doesn't account for what kind of extension makes
> most sense for a given operand/operator pair. It seems to me that
> anything more complex than "undef" (which is consistent with out-of-bounds
> array accesses) would be a nightmare to get right.
We should respect default values if arrays can declare them.
Perhaps there will be a modifier for operator declarations to declare what
the default behavior should be. Otherwise I don't know how different
behaviors for different operators would be possible, especially for
user-defined operators.
sub operator:foo is hyper_default(1) ...
I agree with "Blech", but we can procrasticate doing it at least until
Damian makes it clear how operators will define their behavior.
Otherwise, a contextualized undef (0 in numeric context, '' in string)
would seem DWIM to me.
I wouldn't want to throw tons of warnings from one operation, so maybe
hyper-operating on unequal lengths gets a new warning, instead of throwing
lots of 'undefined value' warnings.
~ John Williams
Erik Steven Harrison
--
On Thu, 26 Sep 2002 14:06:50
John Williams wrote:
>We should respect default values if arrays can declare them.
>
>Perhaps there will be a modifier for operator declarations to declare what
>the default behavior should be. Otherwise I don't know how different
>behaviors for different operators would be possible, especially for
>user-defined operators.
Having an operator force some very narrow kind of
context to control what the list returns is very
strange. The list should respond in some generalized
way (undef or whatever the list is set to pretend is
undef) and have the operator choose how to respond to
that, and return whatever it deems to be the "result"
of the operation. Under this mechanic the only tricky
part is figuring out when the list is exhausted and
when it is passing the autoviv value legitimately.
Related note, if we can define default values for a
list, is that a compile time or runtime property. I
confess as to not knowing quite how to tell. I would
hope it was runtime for the syntax alone:
@users but autovivs ("Anonymous User");
-Erik
> sub operator:foo is hyper_default(1) ...
>I agree with "Blech", but we can procrasticate doing it at least until
>Damian makes it clear how operators will define their behavior.
>
>Otherwise, a contextualized undef (0 in numeric context, '' in string)
>would seem DWIM to me.
>
>I wouldn't want to throw tons of warnings from one operation, so maybe
>hyper-operating on unequal lengths gets a new warning, instead of throwing
>lots of 'undefined value' warnings.
>
>~ John Williams
>
>
Is your boss reading your email? ....Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Dan Sugalski
>On Thu, 26 Sep 2002, Paul Johnson wrote:
>> Is that sufficiently vague?
>
>Not vague enough, because the current implementation manages to miss the
>broad side of that semantic barn...
The intention is to allow aggregates to have different default return
values, IIRC. Right now we return undef as the default, when
accessing elements that don't exist, but there are cases where you
might want something else. (Numeric-only arrays might want to return
0, and string-only ones "", for example)
>Different operators doing different things sounds awful to me, because it
>makes it hard to predict what will happen, because new operators will have
>to be able to control what they do with their operands, and because new
>types of "array-like" operands will have to tell operators how to treat
>them. Blech.
Well... no, not really.
I think this vagueness is my fault, as I badger Larry and Damian
about it on occasion.
The reason it's vague is that the Right Thing depends on the types of
the variables on either side of an operator. Multiplying two matrices
should work differently than multiplying two multidimensional arrays,
or two vectors, or a vector by a matrix.
We should get the default behaviour defined and in use so people get
a handle on how things work, but we do want to make sure people keep
in mind that it's the default behaviour, not the required behaviour.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote:
: >On Thu, 26 Sep 2002, Paul Johnson wrote:
: >> Is that sufficiently vague?
: >
: >Not vague enough, because the current implementation manages to miss the
: >broad side of that semantic barn...
:
: The intention is to allow aggregates to have different default return
: values, IIRC. Right now we return undef as the default, when
: accessing elements that don't exist, but there are cases where you
: might want something else. (Numeric-only arrays might want to return
: 0, and string-only ones "", for example)
We can certainly have arrays that know how to return default values.
But my apocalyptic remarks about dwimming were specifically with
respect to hyperoperators that might have specific ideas about
how to deal with differing arrays.
That behavior should in turn be distinguished from what I said about
parallel C<for> loops. Those run until all streams are exhausted,
because otherwise there's no way for the code within the loop to
tell the loop to run longer. If you assume you should run longer,
it's always possible for the loop to terminate itself early. In the
particular case where one or another stream is infinite, the loop
will run forever unless terminated explicitly by either loop control
or detonation of the warhead.
: >Different operators doing different things sounds awful to me, because it
: >makes it hard to predict what will happen, because new operators will have
: >to be able to control what they do with their operands, and because new
: >types of "array-like" operands will have to tell operators how to treat
: >them. Blech.
:
: Well... no, not really.
:
: I think this vagueness is my fault, as I badger Larry and Damian
: about it on occasion.
Well, I'm never vague, except when I am.
: The reason it's vague is that the Right Thing depends on the types of
: the variables on either side of an operator. Multiplying two matrices
: should work differently than multiplying two multidimensional arrays,
: or two vectors, or a vector by a matrix.
:
: We should get the default behaviour defined and in use so people get
: a handle on how things work, but we do want to make sure people keep
: in mind that it's the default behaviour, not the required behaviour.
Right-o. A system is expert friendly if it has the right options.
It's novice friendly if it has the right defaults.
Larry