Hi,
Following my last reasoning on implicit threading and implicit
event-based programming[1], I came to two interesting realizations...
1 - Every object is potentially lazy, not only lists.
2 - Lazy doesn't mean "wait until I need the data", but "don't stall me
because of that data".
That basically means that
my @a <== map { some() }, grep { thing() }, $*IN;
Will read the data as it is available from $*IN even if you don't
request it. But it will happen concurrently with the rest of your code,
of course trying to access an element of the array that wasn't still
produced will cause your code to block, but only this specific code will
block, every other "continuation" will proceed as events arise.
That's fair, and the use of the feed operator makes it pretty explicit.
But... We already stated in the DRAFT S07 that the assignment operator
will be "mostly eager", which means that it will consume as much data as
it can before proceeding, but it won't wait for $*IN to end before
proceeding, so this kinda means that
my @a = map { some() }, grep { thing() }, $*IN;
Will try to read as much as it can from $*IN (which, if you happen to
have piped in a file, will mean the whole file), before it goes to the
next statement, but if you have your console just waiting there, the
code will move forward, while implicit event-based programming will wait
for new data in $*IN...
That being said, let me take it to the next level...
my $a = map { some() }, grep { thing() }, $*IN;
This is going to provide you with the same degree of lazyness than the
feed operator, since that's just storing the capture returned by map
into the scalar named '$a'. Now, that really means that
my $a = foo();
is a potentially lazy object with implicit threading and implicit
event-based programming, and that's just a plain function call, if, for
instance the code for &foo is:
sub foo {
for ^Inf { say $^n };
}
The really important thing here is that, contrary to my initial belief,
the magic is *not* in the feed operator. The feed operator is simply a
capture constructor that fits well with slurpies.
So the questions are:
* Are there any imperative barriers in Perl 6?
* Does that mean we need to spec a common way of implementing
implicit-threading and implicit event-based programming?
daniel
[1]
http://www.nntp.perl.org/group/perl.perl6.language/2009/05/msg31682.html
