matt diephouse wrote:
sub foo($param is junction) {...}
Doesn't that go against perl's dynamic philosophy?
???
That requires me to type my methods where I may not want to.
> Let's say I have a sub that logs errors:
sub log_error($fh, $error) { # filehandle and error msg
$error_num++; # global
print $fh: "$error_num: $error\n";
}
my $file = open "error.log";
log_error $file, "This message is phony";
However, during my debugging, I realize that I need two error logs (Don't ask me why, I just do). Instead of changing the one line to
my $file = open "error.log" & "../some/other.log"; # I hope this is legal
Under my junctive semantics it is. It simply calls C<open> twice, with the two states, and returns a conjunction of the resulting filehandles. Though you probably really want a *dis*junction there.
I also need to change the subroutine now, because the error count will be off, even though my change is temporary. It reduces the ability to write subs that accept anything and DWIM.
So how does C<print> know to parallelize, rather than just pass in the junction? You can't have it both ways. Either the default is to parallelize at the point a junction is passed to a subroutine, and you have to mark subroutines that preserve their junctive arguments; or the default is that junctions pass into subroutines, and you have to mark subroutines that parallelize when given a junction. I've thought about it at considerable length, and played around with the Q::S module. I concluded that passing junctions into subroutines by default is a Very Bad Idea. The reason, as Luke has already pointed out, is that junctive logic is different from scalar logic. So most subroutines won't be able to "accept anything and DWIM" anyway. Damian
