Jeremy Howard wrote:
The reason that having (1..) implies having (..-1) is that if you allow
(1..), then this is a valid construct:
@dot_dot_neg_one = reverse (map {-$_} (1..));
which is identical to (..-1)!
No, NOT identical. The same set of numbers, yes, but generated in
the
Ted Ashton wrote:
John Porter:
What would be the output of the following program:
$\ = "\n";
$i = 0;
for ( .. -1 ) {
$i++;
last if $i 2;
print
}
If the answer is (as I suspect), "This never prints anything; it goes
Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf,
etc.
Assuming that we end up supporting full IEEE floats, this becomes the
"obvious"
synthax, and I find C(-Inf..Inf) to be far more clear then C(..). We've
got
plenty of puncuation already, thank you very much.
Also,
Ted Ashton wrote:
Thus it was written in the epistle of John Porter,
Ken Fox wrote:
Both of those expressions are the infinite list (-infinity..-1). I
have
no idea how to write that properly 'cause I'm not a math guy. These
things aren't streams (infinite queues) -- they're
Ted Ashton wrote:
I understand very well the concern. I, for one, don't agree that having
(1..) in the language implies that having (..-1) is possible (though it
does
make sense to me that having (1..) and (..-1) would imply having (..)).
After
all, if I were to write
for (1..) {
I'm looking forward to the upcoming writeup :-).
I'm thinking of recanting the whole RFC! :-)
Damian
Thus it was written in the epistle of Damian Conway,
I'm looking forward to the upcoming writeup :-).
I'm thinking of recanting the whole RFC! :-)
*checking etymology* hmmm . . . "recant" . . . "recant" . . .
doesn't that mean to sing the whole thing over again?
:-),
Ted
P.S. Seems
I'm thinking of recanting the whole RFC! :-)
*checking etymology* hmmm . . . "recant" . . . "recant" . . .
doesn't that mean to sing the whole thing over again?
Literally: "to sing a different tune". :-)
Seems to me that while putting hooks in the core to allow this sort
Ken Fox wrote:
John Porter wrote:
Jeremy Howard wrote:
Yes, they're not identical. What I mean of course is:
(..-1) == reverse(map -__ (1..));
WHAT? So the semantics of .. are magically different in the context
of (..$n) so as to produce numbers in descending order?
No. They're
Damian Conway sent the following bits through the ether:
Rather than continue to argue the details, why don't people post some
examples of code where they feel these lazy lists might be useful, and
let's see if there aren't already good alternatives.
It should be noted that "infinite"
Jeremy Howard wrote:
Yes, they're not identical. What I mean of course is:
(..-1) == reverse(map -__ (1..));
WHAT? So the semantics of .. are magically different in the context
of (..$n) so as to produce numbers in descending order?
I don't think so.
--
John Porter
For any result of grepping (1..) (with a predicate which always
terminates, say), you can do this. If Cgrep { g($_) } (1..) is
nonempty, then it has a first element; we can find this first element
by running essentially this:
for(my $n=1; ; $n++) {
last if g($n)
}
Note
Ken Fox wrote:
Jeremy Howard wrote:
(..-1) == map -__ (1..);
That really confuses me. If the sequence (-4..-1) is (-4, -3,
-2, -1) then I don't see how your semantics are consistent. I'll
admit (reverse map -__ (1..)) is the same as (..-1) but reverse
on a stream is undefined. (It
I think I opened a bigger can of worms than I intended :-)
As MJD as pointed out to me in private email, if we are serious
about this feature, we probably want to go the whole hog and
look at Haskell's notion of list comprehensions. See
http://www.haskell.org/tutorial/goodies.html
(Note that I'm keeping the ':' notation, because then it's clear that
we're
talking about a generation rule, not an upper bound). Now I write it like
this, wouldn't it be nice if we could also say:
(1..:f(__)) == apply(f(__), (1..); # But I digress!
Correction (sorry). This should be:
Damian Conway wrote:
I think I opened a bigger can of worms than I intended :-)
Yes, sorry about the overload of email you must of got from me on this, this
morning ;-)
As MJD as pointed out to me in private email, if we are serious
about this feature, we probably want to go the whole hog
"Jeremy Howard" [EMAIL PROTECTED] writes:
Damian Conway wrote:
[...]
Personally, I intend only to update the RFC to include the *possibility*
of (..$x) and (..). I'm reasonably sure Larry will kill the whole thing
-- I think I might too, were I in his place ;-)
Now don't encourage
17 matches
Mail list logo
