Dave Whipp wrote:
> Joe Gottman wrote:
>
> > Alternatively, there might be a new parameter type that indicates
> > that the parameter is not evaluated immediately:
> >
> > sub infix:!! ($lsh, $rhs is deferred) {...}
> A nice concept! So nice, in fact, that it would be a shame to limit
> it to function args. I could see myself writing:
>
>
> my $a is lazy := expensive_fn1(...);
> my $b is lazy := expensive_fn2(...);
>
> print rand ?? $a :: $b;
>
> I'm not sure quite how the syntax would work (should I be binding or
> assigning?); but there are definitely cases where this ability is
> useful. Given this capability, defered evaluation of function args
> would be trivial.
>
> Another, very different, situation where laziness is good is to
> abstract fork/join situations:
>
>
> my $a is lazy_thread := expensive_fn1(...);
> my $b is lazy_thread := expensive_fn2(...);
>
> print $a + $b;
>
> In this scenario, each expensive evaluation would be launched as a
> separate thread. When the resulting value is later used, then the
> thread would be joined, blocking if the thread is not complete.
This is very worth pursuing.
I can see two ways to handle "implicit threading" -- at the object
level, or at the sub level.
Object Threading:
-----------------
my Int $a is threaded = expensive_fn1(...);
...
print $a; # Implicitly joins $a.thread()
Sub Threading:
--------------
sub expensive_fn1(...) is threaded {...}
my Int $a = expensive_fn1();
...
print $a;
The sub threading version seems, at first blush, easier to implement --
since if the variable requires a thread, then things like := binding,
and expression evaluation, get more complex.
Also, of course, it seems easier for developers to grok the concept of
what's in parallel and what's not when using the Sub Threading
approach.
But what to do about matrix arithmetic and other simple threadable
tasks?
sub m_add(@a, @b)
{
my @result;
my $i, $j;
@result = @a;
for @result -> $i {:is threaded # Thread this block?
for @result[$i]; @b -> $j; $b {
$j += $b;
}
}
}
Conversely, I have absolutely no idea what to do about threading on a
per-data-object basis:
sub m_add(@a is threaded, @b)
{
... What can the compiler figure out about threading @a?
}
This is one of those cases where the really smart guys who used to
spend time recoding the fortran compilers for Vaxen might be able to
clue us in on the "cool tricks for vector processing", but how
generalizable will it all be? (And, of course, is the internal
representation amenable to this?)
None of this addresses the issue of "explicit" threading -- cases where
the user wants to create and control her own threads.
=Austin
