The most detailed description of ... is still to be found starting down a few
paragraphs in the https://design.perl6.org/S03.html#List_infix_precedence
section.
In general the operators have not suffered as much "spec rot" as some other
parts
of the "speculations" known as Synopses, so most of S03 is still pretty
reliable.
(You will find, however, that we do not support the speculated ^...^ operator.
:)
Anyway, the parsing of multiple lists just falls out of the fact that all
list infixes can combine multiple lists on the same level like that:
@a Z @b Z @c
@a X @b X @c
@a minmax @b minmax @c
This includes all operators created by the X and Z metaoperators:
<foo bar> X~ 0..9 X~ <.c .h>
The fact that you can reduce multiple lists like this:
[X+] @a, @b, @c
just naturally falls out of the same "every argument is on the same level" idea
that list associativity provides also to scalar operators:
$a ^ $b ^ $c # same as one($a,$b,$c), not one(one($a,$b),$c)
It's just a bit trickier for ... because both the beginning and ending of
each sublist participates in the dwimminess of how to produce the surrounding
sequences. So, for instance, an inner list consisting of a single value
can serve both as the terminating value of the previous sequence and the start
value of the next list, and a sublist of three values will take the first
as the terminative value of the previous sequence, but also use it as the
triple starting the next list to determine if the next sequence should be
arithmetic or geometric. It's quite dwimmy, but sometimes it's a little
hard to explain how it figures out what you want most of the time.
All of the list infixes get a bit tricky when you start putting infinite
lists as members. For Z, any or all of the lists can be infinite, since it
just stops on the first list to run out, but for X and ... it doesn't make
much sense to use more than one infinite list, 'cuz whichever infinite list
is varying the most quicly will tend to starve out the other sublists
downstream of it.
By the way, a vocabulary quibble, but we like to reserve the term "chained"
for the kind of associaativity that happens with comparison operators:
0 <= $x < 100
(Note in particular how the operator doesn't have to be identical all the
way across because it implicitly reuses the middle argument in separate
subexpressions and then &&s them all togother, short circuit and all.)
The other multi-arg list operators are just "list associative", in our
usual usage. (Though admittedly, if you squint, there's some reuse of
the middle arguments going on with the ... operator too. But it's more
like other list associative operators insofar as all the operators in
a given precedence level's subexpression must be identical.)
Hope this helps,
Larry
On Fri, Jan 26, 2018 at 10:50:19AM -0800, Sean McAfee wrote:
: Today I stumbled across the fact that the sequence operator can be chained:
:
: > 1...5...1
: (1 2 3 4 5 4 3 2 1)
:
: You can even reduce with it:
:
: > [...] 1, 5, 3, 10, 8
: (1 2 3 4 5 4 3 4 5 6 7 8 9 10 9 8)
:
: And even sequences with custom generators can be joined:
:
: > 0,1,*+*...144,*/2...9
: (0 1 1 2 3 5 8 13 21 34 55 89 144 72 36 18 9)
:
: Pretty cool! The online docs for the operator don't seem to offer even a
: hint that this is possible, though.
:
: Anyway, I was hoping that someone with more insight into the internals
: could describe how this works. Simple concatenation, or can sequences
: lazily dispatch to another sequence once exhausted, or...?
