> -----Original Message-----
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 3:52 PM
> To: Austin Hastings; Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> Jonathan Scott Duff writes:
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values Â+= rand;
> > >
> > > This is the same as
> > >
> > > all( %languageometer.values ) += rand;
> > >
> > > right?
>
> Well, yes. It's also the same as each of:
>
> any( %languageometer.values ) += rand;
> none( %languageometer.values ) += rand;
> one( %languageometer.values ) += rand;
>
> Since the junctions aren't yet being evaluated in boolean context, the
> type of the junction doesn't matter.
That is clear, once you've pointed it out, but really counterintuitive. Since all
things are applicable, though, I don't object too much -- it's like "and" vs. "but" in
English, I guess.
> Which is why making junctions applicable lvalues might be a bad idea. I'm not sure,
> but this
> looks like a potential confuser.
I think I disagree. With the caveat that there may be something to be said for
discriminating between assigning TO a junction variable and assigning THROUGH one, I
think that the presence or absence of assignment-operators is still the (obvious,
sufficient) indicator that an assignment is taking place.
all(%languageometer.values) + 6
doesn't look like (and shouldn't be) an assignment.
all(%languageometer.values) += 6;
does.
> > It's the same as
> >
> > $r = rand;
> > $_ += $r for %languageometer.values
> >
> > Your junction looks like it should work but I think you're really
> > adding the random number to the junction, not the elements that compose
> > the junction thus none of %languageometer.values are modified.
>
> Hmm... that depends on whether junctions hold references, or what they
> do in lvalue context, and a whole bunch of other, undecided things.
>
> > > And is this
> > >
> > > > %languageometer.values Â+=Â rand;
> > >
> > > the same as
> > >
> > > all( %languageometer.values ) += one( rand );
>
> No, what you just wrote is the same as:
>
> all( %languageometer.values ) += rand;
So the vectorization op is providing the "call once per element" distribution service.
Which takes vectorization out of the MTOWTDI category and into the somewhat-orthogonal
functionality category.
Vectorized operator: %languageometer.values Â+=Â rand;
Vectorized "sides": %languageometer.values Â+=Â rand;
Alt. Vectorized "sides": all(%languageometer.values) +=Â rand;
Vectorized operands: Â%languageometer.values += ÂrandÂ;
Alt. Vectorized operands: all(%languageometer.values) += ÂrandÂ;
I withdraw my aesthetic objection: if vectorizing the operator isn't going to work, I
don't like *any* of them very much.
> > I don't think so. It's like:
> >
> > $_ += rand for %languageometer.values
>
> Sortof. I think Larry was implying that rand returned an infinite list
> of random numbers in list context. If not, then what he said was wrong,
> because it would be sick to say that:
>
> (1,2,3,4,5) Â+Â foo()
>
> Calls foo() 5 times.
Why would it be sick, and in what context?
With Larry's new "vectorized sides" suggestion, putting a guillemot on the right side
of the operator vectorizes the right side operand, which *should* call foo() five
times.
(1,2,3,4,5) Â+ foo() # do { my $x=foo(); (1+$x, 2+$x, 3+$x, 4+$x, 5+$x); }
(1,2,3,4,5) Â+Â foo() # (1+foo(), 2+foo(), 3+foo(), 4+foo(), 5+foo())
(1,2,3,4,5) +Â foo() # Maybe the same as above? What does
infix:+(@list,$scalar) do?
(1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, @list2)
do?
=Austin
