Em Ter, 2008-12-16 às 18:47 +0100, TSa escreveu:
> >   # the following will require a flatenning to get the actual index
> >   say @a[3];
> Could we not shift the problem into a more complicated form
> of the size of the array? Here it has size 0+3+0 but each of the
> summands could be lazy and hence infinite or at least finite with
> unknown value.

The number of "summands" might be also unknown. i.e.: map.

when you have

  my @a <== map { ... } <== something()

you can't really know how many elements you have in the first

> In any case the flat view @a has to step at most the first iterator in
> the array

I'm not sure I see what you mean, but I presume you mean "the first
iteration". In that case, if that iteration returns an empty capture, it
will continue iterating until it returns at least one item. But that
iteration can then return several items which need to be stored in the
lazy list.

> whereas @@a can look beyond that when indexed with a slice, that is
> something with semicolon in it.

Or the iterations of "map" and "grep"...

> An out of bounds access like @a[3] can be answered without flattening,
> right?

I consider counting the number of items in the inner dimension to be (a
simplified) flattening, think of:

  my @@a <== map { $^a == 2 ?? 
              map { $^b == 2 ??
                map { $^c == 2 && $b == 2 && $a == 2 ?? (1,2,3)
                      !! () }, 1, 2, 3
                    !! () }, 1, 2, 3
                  !! () }, 1, 2, 3;

That would result in


Which is considerably more complex than the first example and have the
following example slice accesses:

  @@a[1]; # returns (();(1,2,3);())
  @@a[1;1]; # returns (1,2,3) 
  @@a[1;1;0] # returns 1

Trying to access @a[0] would result in a recursive flattening until it
gets to the element that would otherwise be accessed by the slice


So it's not just a matter of counting 0-3-0, because to get the first 0,
you need to recursively flatten the inner dimmension until you realize
it's really empty.

If we allow that to be flattened at the beginning, it will simply
consume the iterator until it gets an element.

> In general I'm in favor of making @a and @@a distinct because
> otherwise the first @ in @@a feels like an operator instead like
> a twigil that belongs to the variable like $ belongs to $a which
> is also distinct from @a.

That's an important point. I think it would be consistent that '@@a'
should be the variable name, just as '@a', '$a' or any other. Specially
since '@@' is not a sigil and a twigil, but a sigil of two characters. 

> Since one could also go with a shaped @a I think the choice of @@a
> versus @a is a bit like the choice between a @a and an anonymous array
> in a $ var ala $a = [] which can be handled through $a almost like @a.

I'm not sure I understood that, but I think you're saying that slice
context could be seen just as a regular context, as scalar and list
context, which is something that I agree.

> >   @a =!= @@a :test;
> BTW, what does the :test mean there?

This is the proposed syntax for integration of test-driven-development
in the language built-ins.


Reply via email to