On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote:
> >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.
>
> The case of Damian's response in a prior message:
> [...]
> Could easily be achieved with a single layer of encapsulation?
>
> perl6 -e "$x = 'cat'|'dog'; say1 $x; sub say1 ($x) {say $x}"
Nope. Even in this case you've created a function C<say1> with a
scalar context that isn't expecting a junction of values, so the
call to C<say1> is autothreaded over the values of the junction $x.
> 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.
Welcome to the world of dynamic languages. If junctions disturb you,
then Perl 6's ability to override built-in routines and operators
will really keep you up at night. (See C<temp>, and
http://www.nntp.perl.org/group/perl.perl6.language/19195. :-)
> Actually, using the semantics you've outlined above, there is no
> implementation problem.
> However, I disagree that those semantics are desirable.
Fair enough. I'm not the one who expects to make that decision, nor am
I really advocating a particular interpretation -- I'm trying to leave
that to others. I'm just implementing (and explaining) how the
"current state of things" appears to be based on the specs I've read.
Pm
