Karl Glazebrook wrote:
> 
> Consider
> 
> @x[10:20, 20:40:2, 30:50]
> 
> This ALMOST works in the current Perl. @x gives array context,
> then the , produces a list.

I see a number of problems with the current (scalar) PDL objects being
turned (essentially) into perl arrays in perl6.

1) How do you pass lists of PDLs into functions without having to
explicitly reference them:

  my @result = fitit @x, @y, @derivs;

would turn (in current thinking) @x, @y, @derivs into one big array. So
is it

  my @result = fitit \@x, \@y, \@derivs;

which is much worse than what we do in PDL now. An automatic pass by
reference mechanism seems necessary (is that already in some RFC)?

2) any function returning such arrays would do so in list context.
Currently, PDLs being scalars you can distinguish with wantarray if the
user just wants one piddle or a whole collection of result piddles which
is very useful:

  return wantarray() ? ($fit,$fwhm,$correlation) : $fit;

I am not sure how you do this with the @notation??

3) Although PDL objects share some ideas with arrays it is much more
useful to think of each instance as singular. That's anyway the
programming style that an array-oriented numerical language should
favour.

4) The history of perl lists seems to unnecessarily restrict the vital
flexible slicing syntax. As I stressed a million times it must be
flexible and very concise to be useful. The solution: don't use the
@array syntax but stay with either blessed objects or some new prefix
(hard to find any that aren't taken). Then go for the

  $pdl(args)

syntax for slicing. Yes, it's new but not outrageous (DEFAULT method for
'()' overloading).

> 
> If [] is overloaded on @a then the subroutine sees a list like
> 
> "10:20", "20:40:2", "30:50"
> 
> The only reason it does NOT work in the current perl is that "10:20"
> is a syntax error.
> 
> What would be required to make this go away? i.e. to have 10:20 appear
> as a plain strring. What else would it effect?

As currently suggested 10:20 (or 10..20) would return a list (that could
be lazy evaluated). The problem arises when you try to use that in
arglists. 

With current perl5 logic

   $pdl(10:20,:2,(5))

would call the default method (or whatever is decided) with just one big
list that is the concatenation of the three lists. Definitely not what
is desired. 

Two possible solutions: (1) let 1:3:4 create a range object (rather than
a list)

  $rg = 1:3:4;
  $pdl($rg,$n:-1) *= 2;

or (2) introduce some way of specifying a prototype that allows
positional arrays in argument lists (that are not concatenated).

In summary, I doubt that having PDLs being represented by arrays helps
*unless* quite a number of things are changed with regard to array
passing, list context, etc.

  Christian

Reply via email to