Mark Cogan wrote:
> At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
> >It seems obvious that @a should be the whole array @a, not the size of
the
> >array. If I want to check the size of @a, I should have to do so
explicitly,
> >with scalar or $#.
> >
> >This is non-obvious if you think that || is a flow control statement, so
> >think about * for a moment:
> >
> >   @c = @b * @a;
>
> But, to me at least, arrays aren't something you multiply. Multiplication
> applies to numbers (scalars), and returns a scalar, so when you see
>
> @c = @b * @a
>
> it should be clear that something funny is going on.
>
Well, they're not something you multiply in Perl now. But there's plenty of
languages where you can, and it's ever so convenient.

> And, really, what is wrong with:
>
> @c = map {$a[$_] * $b[$_]} (0..$#a);
>
Numerical programming is all about manipulating arrays (or n-dim tensors,
but they're just order array slices really). Writing such programs in a
language that requires explicit loops is not only a pain, but creates code
that bears no resemblance to the numeric algorithm it's implementing.
Furthermore, it's out of the question in anything other than low-level
languages, because the looping and array dereferencing is much too slow.

It also makes easy things easy:

  @full_names = @first_names . @surnames;

and with the extension to scalars as one operand (coming in v2!):

  @quoted_lines = '> ' . @raw_lines;

or

  @histogram = '#' x @num_recs;
>
> >It's pretty clear what working on 'the whole array' means here, I think.
>
> I disagree. In particular, think of it from the point of view of someone
> who hasn't studied computer science.
>
> What should:
>
> @a = defined @a;
>
> return?
>
defined() is a function. Under the proposed extension of RFC 82 from
operators to functions, this example should return a list of booleans, where
each is true if the corresponding element of the original list was defined.
Under Perl 5.6, 'defined @a' is deprecated. This RFC would give it a useful
meaning (in a list context).

> >Treating || as a special case is asking for trouble. If you want a flow
> >control statement, use one:
> >
> >   @result = @b unless @result = @a;
>
> || may be a suboptimal example, but I think the idea that a @-variable
> without an iteration function refers to the array as a whole, and not its
> elements is an intuitive one, and having array iteration magically happen
> when you're not looking is dangerous.

It seems funny if you're not used to it. But that's because we learn that
lists are hard, and computers have to loop. After just a little unlearning
it actually becomes quite intuitive, and is generally picked up with no
additional trouble by new students. Programmers shouldn't have to know how a
computer implements things behind the scenes--which is really what requiring
explicit looping forces.


Reply via email to