[EMAIL PROTECTED] writes:
> These are some of the current issues that we have identified:

Excellent!  Thanks for this.

> (1) The current
> 
>    $pdl->slice("0:$n,(0)");
> 
> syntax sucks.

Would:

  $pdl->[0:$n][0][:]

suffice?  I figure this would translate into something like:

  $pdl->subscript( 0, $n )
      ->subscript( 0 )
      ->subscript( undef, undef )

That is, you can overload [] on objects but instead of being @{}
as it currently is (where your overload sub returns an array ref)
you get to handle the subscript operation yourself.

> (2) We see the need for a multidimensional, packed and typed array.
> 
> The question is: should such an array type be part of perl6 or should it
> be left to a module to implement such types?

I vote module.

>   @arr = complex packed 0:10000; # some arbitrary syntax suggestion
>   $pdl = pdlwrap [10,10,100], @arr; # wrap this packed array to make a
> [10,10,100] piddle
>   $arr[100] = 0;
>   print $pdl[0,0,1]; # print that same element

I picture each piddle as an object:

  my Complex_Packed $arr;
  $arr->[100] = 0;

I see the attraction of having an array appear as an array in Perl.
The problem is that your arrays have new implementations.  Currently
in Perl there's tie() and overloading on objects.

The problem is that you can tie() an array, but an object is a scalar.
Also, there are many array operations (push, pop, etc) still not
supported by tie.  tie makes assumptions about arrays that are perhaps
not valid with pdls.

This will take much thought to get right.

> (3) if we get better support for doing operations between arrays a la
> 
>     @mult = @a * @b;
>     @zipped = zip @a, @b;
> 
> etc we should strive to make things feel very similar when using arrays
> vs piddles. My feeling is that there will still be the distinction between
> piddles and perl arrays since I don't expect all the packed multidim
> stuff to make it into the perl6 core.

Right, but any new operations should be overloadable on piddles too.
That is, your piddles can redefine those operations on pdl objects so
they make sense.

> (4) Get access to the parsers output from perl so that we can do our own
> (PDL) optimizations on certain subroutines (the PP equivalent, see RFC
> 116). I think Damian Conway has mentioned this capability on the wish
> list for perl6 already.

Yup, we definitely want to do this for everything, not just PDL.

Nat

Reply via email to