Damian Conway wrote:
Rod Adams wrote:
I never want to see implicit threading. Ever.
If this is the only stumbling block, then it's easily solved.
Instead of ruining junctions by imposing all kinds of complex and annoying hoops and hurdles (i.e. C<use junctions> and C<no junctions>), we can just offer a C<no autothreading> pragma that prevents any non-explicit junction from autothreading any operator or subroutine. Put it at the top of your code and you'll never get any implicit threading.
Well, allow me to explain what I want in a little more detail, so I can be sure I'm getting it.
I want to be able to feed a junction to functions that handle it, but I also want to thread over ones that do not. But I do not want the decision of which way to go to be made for me.
So, I want to be able to pass a raw junction into C< == >, because it understands junctions, and will take care of the threading for me, likely in a way that's much more efficient than my generalized »« threading ever could. I do not consider this implicit threading. It's passing the task of threading off to C< == >, which itself performs some form of explicit threading.
But when I'm faced with some function that does not directly support junctions, or one which does, but not in a way that I like, I want to be able to thread my junction over it.
I do not think that what you said above is enough to accomplish this. I believe what I need to separate your threading desires from mine is two fold:
1) I need my »« modifier which forces explicit threading, which will not normally be needed under "use autothreading;" conditions.
2) I need "no autothreading;" to alter the calling syntax to require »« when threading is desired (or you can do a .values() and .junctiontype() and roll your own if you really want to). But I can still pass junctions around at will, withstanding normal type check requirements.
Then the only argument left is whether "use autothreading" or "no autothreading" should be default. I would, of course, say "no autothreading;", and then turn back on the ability to store junctions.
IMO, "no autothreading" would provide enough cover for the unsuspecting, removing the Bad Side Effects problems that spawned Larry's no junction storage default. At the same time, junctions still have enormous power via the »«. If people don't want to have to bother figuring out when to thread for themselves, they can then turn on "use autothreading", and let perl attempt to figure it out for them.
Also, if "no autothreading" is default, the person new to Perl6 will always have something to present to investigate to figure out what is going on. In my code, it'll be the funny looking C< »$junction« > things. In your code, it'll be the C< use autothreading; > at the top of the page.
The only implementation problem I see is a potential for the »« to be mis-parsed, since » and « seem to be serving several different roles these days, but I don't think any of them conflict with this meaning. If you want to rename »« to something else, I'm open to suggestions. Just leave it fairly simple.
As for why implementation should be easy (or at least the delta between your way and my way is easy):
- The functionality of »$junction« has to be defined anyways if autothreading happens. It's just calling an already existent chunk of code.
- The logic of when to thread becomes:
given $situation {
when marked_with_»«()
{ thread }
when use_autothreading() & damians_ouija_board()
{ thread }
default
{ don't thread }
}And you've already defined how the ouija board works, everything else should be boilerplate for the compiler/runtime to handle.
This sound reasonable enough?
-- Rod Adams
