I have been thinking about what has come up on this list so far and was wondering if there isn't a strategy so that we all benefit and come up with a number of very strong proposals. The following seems to be a constructive approach to me: 1) There is nothing wrong with having many RFCs What remains is identifying which RFCs deal with very similar issues and identify conflicts between them. They can hopefully be resolved on this list. The next step is to update these RFCs so that conflicts are either removed or clearly pointed out with extensive crossreferencing to the relevant RFCs and a clear statement why this author sees it this way and not the other. That should leave us with a set of RFCs that can be read by one person to quickly get an idea what the consensus and what the open questions are. 2) The current PDL view versus possibly a slightly different view for the suggested n-dim arrays It seems not unlikely that there will (at least initially) be a situation in perl6 where we might have both the new nD arrays and PDL objects. I wouldn't think there is anything wrong with that if we make it easy to switch from one presentation to the other. Basically, I'd imagine you'd be able to say $pdl = pdl @nDarray; @array = $pdl->nD; @res = @nD * $pdl->nD; $res = @nD * $pdl; # who wins? ;) And to be cool they would share the same compact data, so $pdl++ will actually increment @array; they are just slightly different views of the same data. I'd see that as very perlish: if you want to view them as (scalar) objects use the PDL view, if you wan't to see them as arrays use the nD array view. The thing I would like to make sure is that slicing syntax and operator behaviour would be virtually identical so that a user familiar with one could easily learn the other. If that means that PDL will have to change its slicing syntax that's fine. 3) Different programming styles and current PDL. Most people on this list (apart from the pdl-porters ;) seem to favour a slightly different programming style than what we have in current PDL. Also, some people have mentioned that PDL is awkward to program right now. I personly would have hoped that apart from all the suggestions how perl6 should fix this I could go away with some lessons on how to improve PDL now to make it more user friendly while we're waiting for perl6. Here it is absolutely crucial that people don't stay general but give conrete examples and say: look, this is not nice code .... I would rather write this... Then we can see if we can adopt this other style for PDL NOW. And that leads to my fourth point: 4) Code up some actual algorithms in the new virtual num-perl6 To see how useful our current suggestions are we should pick a number of real-world problems, e.g. Levenberg-Marquardt curve fitting or whatever and write scripts in the virtual code to see what it would actually look like. That's also a good way to identify missing bits and pieces in our suggestions. So Karl or I might code up how we might envisage that in an improved PDL, Jeremy, Budda or so use might use an approach that is more inspired by functional programming. Along the way we might discover that we really need to specify additional detail or a current syntax proposal leads to awkward code, etc. Also, I might go home and say: yeah, this piece of code by Jeremy (say) looks really awesome and is much better than what PDL can offer. How does that sound? Christian
