Front page | perl.perl6.language.data |
Postings from September 2000
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > proposes a convenient syntax to slice multi-dimensional arrays;
> It is hard to evaluate this proposal without more context. In particular:
>
> - How does it relate to RFC 204? Is it an alternative, or an addition?
204 cannot be implemented since it prohibits usage of overloaded
objects as array indices.
> - How does it relate to RFC 81? The semantics of '..' seems to conflict.
What I say conserns the usage of '..' inside an index only. It cannot
conflict with anything else.
> - Why is it better to make ';' "special inside a hash/array index only"
Because ',' is already special there. There is little chance that ';'
operator is created as a general-purpose operator.
> - Why is a special token for a separator necessary "to avoid the (giant)
> overhead of creation of anonymous arrays"? Don't RFC 203 arrays and RFC
> 81/205 lazy generation avoid this?
a) "Lazy generation" is not defined, as stated it is a good wish only.
What is
@a = (0, 2..99, 200..9998, 1000000);
f(@a);
? My proposal has completely defined behaviour (AFAICS).
[Yes, I was proposing lazy evaluation for a long time. But I know
that it can be further than it appears.]
b) The call for $a[2,3;5,6] is
*) Put already-available SV pointers for $a, 2,3,4,5 and the cashed SV*
for tie::multi::separator() on stack;
*) Put the (cached) CV* for the method on stack;
*) invoke the call frame;
This is not *very* quick, but at least it may be "not that slow".
While all the alternatives require creation of anonymous lists, which
(I expect) will slow things down 7..10 times for the call above. For
$a[1..100;1..100] it may easily be 100..1000 times slower.
Your way was my way when I was designing Math::Pari. When I
*implemented* Math::Pari, it took some time to determine why it was so
much slower than what I expected. My proposal is based on this
experience.
Creation of [1,2,3] is *very* slow.
> - Overall, what is the problem in the existing array RFCs that this is
> designed to solve?
*) They are not compatible with overloading (unless overloaded things
are dramatically changed);
*) They create a lot of temporary anonymous arrays the only purpose of
which is to group arguments;
*) They go very high on the bizzareness scale.
> - Can we incorporate a solution into the existing RFCs without creating a
> new conflicting one?
>
> If there are implementation challenges around the existing RFCs, I would
> rather make changes required to overcome them within those RFCs.
I see no way how the existing RFC can be accepted. (No, I could not
read the "include all the PDL" proposal to the end, so I cannot
comment on this.)
> That we we
> get the benefit of the thought we've all put into the syntax of these RFCs,
> plus the benefit of Ilya's deep understanding of Perl internals.
Thank you for suggesting that I do not need to think to create a RFC.
Ilya
Thread Previous
|
Thread Next