I'd thought I try to summarize what has come up so far and see if we can
find somebody who can write some RFCs.
1) the XS replacement should provide for a way to publish (C-level) APIs
across modules. That would get around the hacks that Tk, PDL, OpenGL,
etc have to go through at the moment. Good syntax suggestions have yet
to be made.
2) motivated by the PDL indexing requirements we suggest a number of
syntax level changes to make live easier:
a) typed arguments might help:
possibly a la
sub slice ( $spec :quote ) {
...
}
or
sub slice (string: $)
b) a range object that is returned by the ':' operator in certain
situations.
Quotations from Tuomas' message demonstrate the idea
> Also, the usual Perl index tricks should work (these should be specified
> in the span so that the code interpreting the span can use its knowledge):
>
> : # all the things on this dimension: full span
> 5:-1 # 5..last
> 5:-1:2 # Every second item, up to the last or second last
> -1:7:3 # Start with last item, then fourth last, etc. until 7.
And note that this is not easily obtained with current '..' and '.'
operators. Hopefully this has become clear from the previous
discussions.
c) an extension of overloading or some such to be able to use
$pdl(1:4,0,*)
or
$pdl[1:4,0,*]
to obtain what we now do via
$pdl->slice('1:4,0,*')
3) some change of overloading semantics/syntax so that a derived class
can more easily specify overloading of binary opartors when the first
arg is from the super class (ideally the super class shouldn't have to
know about the derived class):
overload '+' (SUPER,PDL::Complex) => sub {....},
so that
$pdl+$pdlcomplex
resolves to the complex addition with the first arg being promoted to
PDL::Complex
4) get some of the PDL semantics working for general perl arrays, e.g.
matmult of arrays. That also raises the question of multi-dim perl
arrays; are refs of array refs the answer?
5) related to the previous point there should be ways in perl to do
certain compile time optimizations that would allow it to specify
numerical algorithms compactly and implement them efficiently. Examples
are inspired by PDL, Mathematica and other array languages. Support for
sparse arrays/matrices/tensors should be an integral part of the
language.
6) we definitely want to keep lvalue subs
($tmp = $a->slice('1:5')) .= 5;
is just a pain.
7) a probably quite controversial proposal suggests to get rid of the
syntactical distinction between scalars and arrays and the whole $,@
business. My interpretation is that it comes down to everything is an
object and knows what it is (even if you are not using the OO syntax)?
Is that a reasonable summary of what has come up so far? Did I leave
anything out?
We should try to distill these issues down to a few RFCs.
Christian
PS: And finally, I'd like to say why I was quite reluctant to swallow
the bait in the first place (and probably get myself into all kinds of
trouble). According to one of LW's statements that I read "perl6 should
be a rewrite of perl by the community and a rewrite of the community by
the community". Now I read the following on what these RFCs are supposed
to be (http://prometheus.frii.com/~gnat/p6/rfc-format.pod):
> =head1 RFCs
>
> Larry Wall will decide the changes to make for perl6 based on our
> suggestions. To make life easy for him, we should put some effort
> into our suggestions. RFCs are intended to be focus discussion on
> something that will be useful to Larry when he makes his decisions.
This reads to me like the code of this religious cult whose aim it is to
worship the great LW.
I am not sure if this impression is intended but I notice a lack of
clarification how the syntax issues about perl6 are decided. Is it
really all down to one individual (however bright and charismatic this
particular person may be)? A more clearly stated process where possibly
a small group of developers (with write access to the repository)
decides things and where a project leader (LW?) has the possibility of a
veto or such seems at least transparent to me. It would probably also be
welcomed by industry if a clear process is outlined.
Maybe I am the only one seeing a possible problem here but as a
scientist I am deeply suspicious about a decision process that is down
to one individual only (not even taking the workload into account).
