# Re: [svn:perl6-synopsis] r14586 - doc/trunk/design/syn

```Larry Wall wrote:
> On Sun, Oct 05, 2008 at 08:19:42PM -0700, Jon Lang wrote:
> : <[EMAIL PROTECTED]> wrote:
> : > Log:
> :
> : Is there a way for the continuing function to access its index as well
> : as, or instead of, the values of one or more preceding terms?  And/or
> : to access elements by counting forward from the start rather than
> : backward from the end?
>
> That's what the other message was about.  @_ represents the entire list
> generated so far, so you can look at its length or index it from the
> beginning.  Not guaranteed to be as efficient though.```
```
If I understand you correctly, an "All even numbers" list could be written as:

my @even = () ... { 2 * [EMAIL PROTECTED] }

And the Fibonacci series could be written as:

my @fib = () ... { (pow((1 + sqrt(5))/2, [EMAIL PROTECTED]) - pow((1 -
sqrt(5))/2,
[EMAIL PROTECTED])) / sqrt(5)) }

Mind you, these are bulkier than the versions described in the patch.
And as presented, they don't have any advantage to offset their
bulkiness, because you still have to determine every intervening
element in sequential order.  If I could somehow replace '[EMAIL PROTECTED]' in
the
above code with an integer that identifies the element that's being
asked for, it would be possible to skip over the unnecessary elements,
leaving them undefined until they're directly requested.  So:

say @fib[4];

would be able to calculate the fifth fibonacci number without first
calculating the prior four.

It's possible that the '...' series operator might not be the right
way to provide random access to elements.  Perhaps there should be two
series operators, one for sequential access (i.e., 'infix:<...>') and
one for random access (e.g., 'infix:<...[]>').  This might clean
things up a lot: the sequential access series operator would feed the
last several elements into the generator:

0, 1 ... -> \$a, \$b { \$a + \$b }

while the random access series operator would feed the requested index
into the generator:

() ...[] -> \$n { (pow((1 + sqrt(5))/2, \$n) - pow((1 - sqrt(5))/2,
\$n)) / sqrt(5)) }

I'd suggest that both feed the existing array into @_.
__________________________
> : It would be nice if the programmer
> : were given the tools to do this sort of thing explicitly instead of
> : having to rely on the optimizer to know how to do this implicitly.
>
> Um, I don't understand what you're asking for.  Explicit solutions
> are always available...

This was a reaction to something I (mis)read in the patch, concerning
what to do when the series operator is followed by a 'whatever'.
__________________________
On an additional note: the above patch introduces some ambiguity into
the documentation.  Specifically, compare the following three lines:

X  List infix        Z minmax X X~X X*X XeqvX ...
R  List prefix       : print push say die map substr ... [+] [*] any \$ @

N  Terminator        ; <==, ==>, <<==, ==>>, {...}, unless, extra ), ], }

On the first line, '...' is the name of an operator; on the second and
third lines, '...' is documentation intended to mean "...and so on"
apparent that this is so: a casual reader will be inclined to read the
first line as "...and so on" rather than 'infix:<...>', and will not
realize his error until he gets down to the point where the series
operator is defined.
__________________________
Another question: what would the following do?

0 ... { \$_ + 2 } ... &infix:<+> ... *

If I'm reading it right, this would be the same as:

infix:<...> (0; { \$_ + 2 }; &infix:<+>; *)

...but beyond that, I'm lost.
__________________________
Jonathan "Dataweaver" Lang
```