Doug Hunt wrote:
> But I would like to speak up in support of Baris' idea. I have long
> found it
> confusing (both to myself and to those I must explain my code to) the
> mix of
> pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
> appear to be scalars. I was even asked once why some arrays look like
> arrays and other look like scalars.
>
> It seems to me that scalars are quite overloaded these days. I suppose
> the question is:
>
> Do we want to continue the perl4 tradition of syntactic markers for
> different data types, or do we want to lump everything together?
>
> Since I'm in the 'numeric' camp, I would vote for full membership of the
> compact array type in the set of perl types.
I am not sure that PDL objects (piddles) are actually best represented
by arrays. It is much better to think of what are now piddles as a
rectangular region of nD space. The array '@' signals array context and
we don't want every function that returns a piddle to signal array
context. We now have functions that return lists of piddles
($fit,$fwhm) = fitgaussian $x, $y
and the distinction between list context and scalar context is a good
one to have with piddles as well.
The other problem with arrays is: how do we deal with functions that
take multiple piddle arguments if they are arrays:
@result = integrate @x, @y, @bounds;
Won't those all be clumped into one big input array? Does it mean we
have to write
@result = integrate \@x, \@y, \@bounds;
which seems bad to me.
Secondly I feel that the history of array indexing stands in the way of
the flexibility that piddle-like things need. So we are probably better
off asking for a
$pdl(0:-1,:2)
syntax for slicing. That leaves request for a default method and ';' as
range operator.
Christian
