develooper Front page | | Postings from September 2000

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

Thread Previous | Thread Next
Ilya Zakharevich
September 16, 2000 22:47
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Message ID:
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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About