On Sat, Feb 19, 2005 at 02:40:00PM -0600, Rod Adams wrote:
> Damian Conway wrote:
>
> >Of course, literal junctions *will* autothread in all circumstances:
> >
> > is_prime(any(6,7,8))
> > is_prime(6|7|8)
>
> I had not caught the difference between:
>
> use junctions;
> $x = 6|7|8;
> if is_prime($x) {...}
>
> and
>
> if is_prime(6|7|8) {...}
>
> before. Is this new, or yet another important detail I missed along the
> way? Or is this a side effect of not being able to store a Junction, and
> can go away if C< use Junctions > is turned on?
It's a side effect of not being able to store a junction.
> I will, however, question if this is optimal. Compare two simple cases:
> C< $x == any(4,5,6) > and C< $x < all(4,5,6) >. Both of them are prime
> candidates to some optimizations, but the optimizations are likely
> rather different. If we pass the junction into the operator, then it can
> perform some custom tailored code, to make things much more efficient,
> instead of relying on a more generalized junction optimizer to handle
> things.
There's nothing to *prevent* us from passing a junction into a routine
that perform custom tailored code for the junction--it's just not
the default. If &infix:«<» wants to optimize for junctions, we define
it with something like
multi sub *infix:«<»(Junction $x, Junction $y) returns bit { ... }
and it can then optimize appropriately. Autothreading routines
by default occurs only when the junction arguments are bound to scalar
parameters that are inconsistent with the Junction type (S09).
> >And if:
> > is_prime($x)
> >does happen to autothread when you weren't expecting it to, then one
> >of two things will happen. Either the subroutine will be 'pure' in
> >which case there's no problem in autothreading it; or else the
> >subroutine will have side effects, in which case you'll get an
> >explicit warning when the autothreading occurs.
>
> I addressed earlier concept of how does perl know when there are side
> effects, particularly with the execution path can weave to parts written
> in pure-parrot. In particular, if the Patrick responded by implying
> that there was no such side effect protection. see:
>
> http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
> http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's
> response)
>
> I see your statements on the subject, and Patrick's to be at odds. But
> then again, it might be that I've misread something again, though I'm
> doing my best to avoid it now.
AFAICT there aren't any conflicts between my and Damian's statements.
The example given in the 19210 post supposed that a Junction would
get passed to a "pure Parrot" function, but didn't actually provide
code to demonstrate that. Any "pure Parrot" routine declared as
accepting scalars inconsistent with Junctions would be autothreaded
the same as any other routine.
Assuming that a Junction *is* passed to a "pure Parrot" routine
(e.g., via a list or other data structure), and assuming that
Parrot is not itself supporting autothreading, then it's fairly
straightforward to define the Junction type such that requests
to stringify, numify, or otherwise access/evaluate the Junction
as a non-Junctional value will throw an exception.
> All of this knowledge, which comes almost innately during the
> process of writing code, can become almost Halting Problem hard
> for the compiler or runtime to figure out.
So far I haven't seen anything about Junctions that requires an
awful lot of knowledge, guessing, or exhaustive evaluation on
the part of the compiler/runtime system. They will likely need
to do a bit of checking of the arguments to decide when to
autothread a call, but they're going to be doing other sorts
of argument checking anyway, and the additional checking to be
performed is fairly shallow -- just testing each argument
for isa(Junction) or its equivalent. (We don't have to perform
deep inspection of arrays or the like.)
Pm
