Nathan Wiger wrote:
> My main fear is that while this RFC seems really good for math ops, but
> seems too array- and PDL-specific. Here are some examples of mixed
> contexts; how would these be handled under the RFC?
>
> @user_data = @empty || $user;
> %files = scalar(get_files()) || @DEFAULT;
> $total = @items + $MIN_VALUE;
> @full_names = @first_names . "Smith";
>
The last two already work under this RFC.
-(3) evaluates the operator in a scalar context, which is unchanged from P5
-(4) Broadcasts 'Smith' across the array, as specific in the RFC
> What I'd like to see is Perl to really DWIM (especially in that last
> one). But to do so you have to redo the rules of the RFC:
>
> Op Type Default homogenous context Mixed context
> --------------- ------------------------------ ----------------
> Math ops element-wise forced to scalar
It depends what you mean by 'mixed context'. If the array shapes allow
broadcasting (see the RFC for definition and examples), then an array
operation should occur.
> Boolean ops whole entity forced to list
This is the whole debate around <RFC 45 (v3): C<||> and C<&&> should
propagate result context to both sides> again, really (which I again forgot
to reference and discuss in RFC 82--oops...).
I don't like this RFC, partly because it breaks consistency with RFC 82, and
partly because it makes || and && act in a weird cross between scalar and
list context (evaluates in scalar context, propagates in list context).
Also, I see boolean operations frequently applied to lists of elements.
There is really nothing about this operation that makes it only useful for
scalars.
Finally, the control-flow/short-circuiting side effet of || and && would be
very useful for array operations. In lazily generated lists, using || or &&
for an element-wise operation would avoid computing elements of the RHS
where not necessary to do so.
> String ops element-wise forced to list
>
Again, I think the broadcasting behaviour currently defined in the RFC
provides the best result here.
> True, this opens a whole other can of worms, but I think it's closer to
> what people would want to use the ops for, and it's also more usable to
> us non-PDLers. Note there's a lot of inherent want()-like behavior built
> in there.
>
PDL-ers have complained on this list that not enough people here use PDL.
Non-PDLers complain about things being too PDL-oriented!
Well, in this case the RFC author isn't a PDL-er (it's me--and I'm a
modperl-er and C++er mainly! ...but I use PDL sometimes, of course). But I
really don't think this is relevant. In this case, I think the problem is
actually that the amount of utility available from implicit loops isn't well
understood, because it hasn't been available in Perl previously. Have a look
at some code of yours that manipulates data--log analysis, mailing list
generation, whatever. Look however you want to operate between two lists, or
broadcast across a list. These operations would be much faster, and more
compact, if implicit loops were provided.
As to this whole PDL vs non-PDL issue, lets stop worrying about it. As I
said in my original 'Role of perl6-language-data' post a few weeks ago, we
should look to many languages for inspiration in providing data crunching in
Perl 6:
<quote>
PDL provides a source of many important lessons for us. It shows the kinds
of features that are required for numeric data crunching, and it also shows
the kinds of obstacles we need to remove from Perl 6.
Other sources of inspiration for syntax, paradigms, and implementation ideas
include:
- Mathematica (combines functional, declarative, and procedural styles;
implements memoization, lazy lists, and array notation)
- Matlab (fast and simple array language)
- C++ expression templates such as POOMA and Blitz++ (implicit looping and
generalised slicing; loops unrolled and parse trees walked completely at
compile time resulting in zero run-time overhead)
- FORTRAN (still the most widely used numeric programming language)
- Haskell (effective data crunching in a purely functional paradigm)
</quote>
I'd certainly add Numeric Python to this list now I've got to know it
better, and Java libraries such as:
http://www.vni.com/products/wpd/jnl/JNL/docs/intro.html
