Karl Glazebrook wrote:
> OK I will raise to the bait
>
> I think it's a bit unfair to say that PDL people have failed to 'bite',
> there was quite a bit of discussion on our list after your post. Also
> some concern about how much of perl6 is vapourware.
>
I do apologise, Karl. It turns out that I had a problem with my PDL-P list
subscription so I didn't see that there were some comments made. It would be
great to keep perl6-language involved anyway (as seems to be happening now).

> I definitely support embedding many of the key PDL ideas into the language
> - they key one is a much easier syntax for a multi-dim slice. We are
currently
> driven to
>
> $a->slice("10:100,30:200");
>
> compared to IDL AND NumPy: a[10:100,30:200]
>
It's not just that it's ugly. It's hard to optimise, and it doesn't work on
infinite lists (which don't actually exist yet ;-)

> perl6 should provide simple arrays, but they should be allowed to be
> replaced with objects with no change of syntax. So
>
> @a[10:100,30:200];
>
> Would work whether @a was a perl list of lists or a PDL compact array.
>
> So would @a * @b
>
Well, ideally, there wouldn't be a 'PDL compact array'. Instead, compact
arrays would be part of perl 6, and would be used as appropriate. But yes,
the same syntax should always 'just work'.

> Loop unrolling sounds really good, their should be hooks for objects to
> provide their own implementation. Proper overloading and ability to
> overload by arg type are required, i.e.
>
> sub myfunc{ float x, complex y }
> sub myfunc{ float x, float y }
>
There's been some discussion of this on perl6-internals. Dan Sugalski and
Ken Fox have pointed out that a general change towards thinking of lists as
pointers and streams would allow for nice optimisations when doing
reductions, as well as more generally speeding up passing lists as
parameters.
>
> Their should also be hooks for slices, for example if one is implementing
> a complex objects (e.g. representing a map) - one might want a slice in
> physical units instead of array indices.
>
> I'd even propose getting rid of @a for arrays and $a for scalars and just
> making the "a". I've never really liked that feature of perl - I am sure
> some users agree and some disagree - might be worth taking a straw poll.
> In this age where everything may (or may not) be an object are $ and @
really
> required? There are too many objects types and not enough funny symbols..
> even with Unicode.
>
This has been discussed before. It didn't go down awfully well ;-) 'Keeping
perl as perl' was a common argument...


Reply via email to