Patrick R. Michaud wrote:
On Tue, Feb 15, 2005 at 03:07:53PM -0600, Rod Adams wrote:
I see it this way:
When perl sees a function call, and one of the arguments is a junction, there are three basic options:
1) If the junction is wrapped up in some larger container, like a slurpy list, pass it on as is.
2) If the function in question is an "outputing" one, throw an exception.
3) autothread over the function.
Consider the following:
$x = 3|4; $y = fun($x); sub fun ($x) { warn "enter: fun($x)\n" if $DEBUG; $x + 1; }
Which option from above is in effect? I do not think I left any room for the junction to be enclosed in a larger container, so option #1 is out. That leaves #2 and #3.
If we autothread, the C<say> only gets a regular scalar, and is happy, so we could get the dreaded repeated outputs.
As you've written things above, C<fun> is autothreaded (your option #3), and we'll see two C<warn> output lines if $DEBUG is set. Whether or not the repeated outputs are "dreaded" is a matter of perspective. Since the caller has chosen to pass a junction to C<fun>, the caller shouldn't be overtly surprised when C<fun> is autothreaded, or that it generates multiple output lines. In fact, I'd be concerned if it didn't.
The case of Damian's response in a prior message:
Rod Adams wrote:
I also find the following incredibly disturbing:
>perl6 -e "$x = 'cat'|'dog'; say $x;" dog cat
That would be disturbing if that's what happened.
C<say @what> is just a shorthand for C<print @what, "\n">.
So saying a junction is the same as printing it, which is a run-time error.
Could easily be achieved with a single layer of encapsulation?
perl6 -e "$x = 'cat'|'dog'; say1 $x; sub say1 ($x) {say $x}"Or is the consensus that that's somehow not disturbing, and direct calls are disturbing.
If what you're saying is true, then feeding a junction into DBI for a "insert" statement, since the output proper is encapsulated, would create multiple new records in the database? I'm back to being very disturbed.
Actually, using the semantics you've outlined above, there is no implementation problem.If so, has Dan signed off on this?
If not, how does Patrick resolve whether to autothread or raise exception?
Well, the ultimate answer is that both Dan and Patrick (and others)
will negotiate the exact interface when we get to that point, and that we don't seem to be too concerned about it at the moment.
(It could just be that we're both burying our heads in the sand hoping it'll be magically "solved" by the other. :-)
However, I disagree that those semantics are desirable.
OTOH, what happens with...?
sub nofun($x is rw) { $x += 2; }
$y = 3 | 4; nofun($y);
Do we need to change the semantics of what happens with autothreading to:
method autothread (&func, $junction) {
my $result;
my $value;
for $junction.values -> $value {
my $temp = $value;
func($temp);
$result |= $temp;
}
$result;
}-- Rod Adams
