Larry Wall writes: > There's no doubt that the QM view of extended entanglement is very > useful. After all, that's what the whole universe runs on. But most > mortals will want the classical view to be the default, so we'll > require some kind of explicit markup or pragma if you want to extend > entanglement further out than comparisons. That's why junctions can't > be passed into a function unless the function specifically allows it, > for instance. (Then there's the matter of sneaky return values.) > > The only alternative is to autothread every conditional, and I don't > think we'd survive the lynch mobs if we did that. Maybe there's some > middle ground here that I don't see, but if so, I don't see it. And > if I don't see it, all the other Pooh bears will have trouble with it > too.
The collapsing behavior of Quantum::Entanglement (and what is being expressed as wanted here) is actually a sort of parallel logic programming. Instead of trying and backtracking, it's just doing it all at once. Instead of providing a collpasing junction type which will confuse the heck out of people, I think it's best to concentrate on how we will integrate logic programming in the language. And the best way to concentrate on that at this point might be not to think about it at all. But junctions might be our ticket into the world of logic programming. We'd have to change them, but there are some amazing parallels between what junctions currently do and what regexes do (regexes even use the same symbols) and what my "Argument Patterns" proposal does with junctive types, which are both logical programming frameworks. So let's put it in the back of our minds. It's going to be in the front of mine for the day, but I might not come up with anything. Luke