On Sun, Sep 17, 2000 at 11:07:09AM +1100, Jeremy Howard wrote:
> > I repeat: what does
> >
> > $a[ $ind ]
> >
> > does if $ind is a (blessed) reference to array (1,1), but behaves as
> > if it were 11 (due to overloading)?
> >
> How $ind is implemented (ie the actual structure that is blessed) does not
> matter. What matters is what interface its class provides.
As I said: it provides *both* numeric value and list reference
interface (as complex values may do).
> <quote>
> When a lazy list is passed to a function it is not evaluated. The function
> can then access only the elements it needs, which are calculated as
> required. Furthermore, the arguments that generated the list are available
> as attributes of the list, and can therefore be used directly without
> actually accessing the list
> </quote>
f(1, 10..1e6, 1e8..2e8, 1e9)
How can the body of f() query the "attributes" to see that it got
something lazy?
> Furthermore, RFC 81 proposes syntax beyond just ($start..$stop: $step).
> Implementing it using tie::multi::range() followed by 3 numbers would not be
> enough.
Another example of "bizzare" (and not completely defined) interface.
I would think it stands a very little chance to become reality.
Apparently, the authors of RFC81 assume that iterators become better
integrated if they are introduced by a funny syntax. Since what they
want to accomplish is exactly this...
my $iter = new iterator start => $a, next => sub {};
foreach my $i (each $iter) {...}
Here an iterator is something which overloads '<>' (in Perl5 speak).
A way to integrate iterators would be very convinient indeed. As you
see, in principle it does not need any funny syntax...
> Anyway, we're defining a language interface here, not an
> implementation, so we don't really need to nail this down immediately.
No, an interface without a feasible implementation in mind is not viable.
> # Slice syntax extension
> @2d_slice = (0..1 ; 0..1); # ([0,0],[0,1],[1,0],[1,1])
This is very expensive. Do you know any example when such a list is
needed as a final result, not as a temporary?
> > @a = ($a .. $b);
> > tie @a, Array::Range, $a, $b;
> >
> > No other usage of .. is covered.
> >
> RFC 81 defines 4 uses of C<..>.
Sorry, the only context which I could find is the one above.
> > > The index in $a[1..100;1..100] should be generated lazily.
> >
> > This is *exactly* what my proposal is doing. The difference is that
> > it defines what "lazily" means.
> >
> Except that your proposal changes the language interface. In particular, it
> doesn't allow the creation of contiguous slices, AFAICS. @a[1..100;1..100]
> should refer to the whole box bounded by (1,1) and (100,100).
I have no idea what you are talking about. What else can it *mean*
but the whole box? Having different calling conventions does not mean
that the *results* are different.
> It's very important. It shows that a particular syntax is intuitive enough
> that it is understand by people with a wide range of backgrounds. Intuitive
> syntax is an important language design goal.
The syntax and the access-semantic of RFC81 and of RFC231 are the same.
However, RFC231 explain how this semantic can be achieved via simple
tie() interfaces.
> RFC 231 does not (yet) effectively cover the same range of problems that the
> array RFCs do. We need multidimensional slicing (not just multiple
> indexing)
Is in RFC231.
> flexible list generation,
This is orthogonal. And I do not see why this is needed to be in the
core language at all. I would guess that an appropriate module with
interfaces to generate efficient arrays is a better place for this
(see the example above).
> multiple levels of indirection,
Do not know what you mean here.
> and fast and compact reshaping.
If we want the reshaping to be supported by builtin arrays *and*
transparently by overloaded arrays, then yes, it is needed to be in
the core. But I see no need for this.
Again, this looks as belonging to a module, not to the core.
Ilya
