--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Dave Whipp wrote:
> > Joe Gottman wrote:
Getting deep -- sorry. :)
> > > Alternatively, there might be a new parameter type that indicates
> > > that the parameter is not evaluated immediately:
> > >
> > > sub infix:!! ($lsh, $rhs is deferred) {...}
If the standard is pass-by-ref it wouldn't trip any side effects unless
you did so in your code, right? So is this necessary?
Next author....
> > 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 could certainly see some sweet uses for this. Any input from the
design team on whether this is a pipe dream or not?
> > I'm not sure quite how the syntax would work (should I be binding
> > or assigning?);
I'd say binding was right. $a is an implicit call to expensive_fn1(),
right? But that just looks like a tie to me. Maybe I misread it.
> > 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.
So in this case you're saying to thread and execute the functions *now*
so that $a and $b can be coprocessing? That's different from the above
example. Sounds like a designer's nightmare, but a beautiful concept if
the language could take advantage of implicit threading that easily.
Next author....
> 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.
Agreed, though I'd say (in fact I did, abover :) that := binding would
probably be necessary for that sort of per-object threading....which
kind of makes it equivelent to the per-sub threading. If the sub is
threaded and you bind it to an object, then that's a compile-time bind,
right? pre-spawning the thread, maybe? Then when the runtime call
occurs the thread receives the relevant arg values and starts
proceccing them immediately, etc. Still sounds like an elaborate tie()
to me, but a beautiful way to do it.
> 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.
Agreed, though anyone using threading this way should obviously be VERY
careful about it.... threads are not something to do accidentally. I
might even say that such ability should only be available upon explicit
pragmatic request....
use threads :implicit; # maybe?
use implicit :threads; # better?
or is that a horrifically inappropriate use of Larry's colon? :)
> 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;
> }
> }
> }
isn't $i an element alias rather than an index there?
Basically, I just failed to parse all that. Sorry -- internal P6 parser
still incomplete.
> 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?
> }
I'd say this is unlikely to work, but again, I haven't exactly thought
it all through very thoroughly.
> 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.
Or how they would interact. If you're doing implicit threading in a
program using explicit threading, things could get REALLY tang-toungled....
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
