[Feature Request]: Cartesian product iterator

[Iainmon]

Summary of Feature

Description:

It would be nice if there was a cartesian product iterator

var n = 0;
for (a,b,c) in cartesian(0..<3,0..<3,0..<3) {
    n += 1;
}
writeln(n); // 27

Is this issue currently blocking your progress?

No

Partial implementation

    iter cartesian(X,Y) {
        for x in X {
            for y in Y {
                yield (x,y);
            }
        }
    }
    iter cartesian(param tag: iterKind,X,Y) where tag == iterKind.standalone {
        forall x in X {
            forall y in Y {
                yield (x,y);
            }
        }
    }

[e-kayrakli]

Can you iterate over a domain literal instead?

for (a,b,c) in {0..<3,0..<3,0..<3} {
    n += 1;
}

P.S. Domains can be heavyweight there, but that's because of lack of a compiler optimization rather than a missing piece in the language in my view.

[Iainmon]

This would work, but I have needed this when the iterands were arrays, rather than ranges.

[bradcray]

Chapel used to have built-in syntactic support for this (though I'm not sure how mature the implementation ever got), but it fell out of favor at some point, with the intent of doing just this—making a general iterator that could do it. I still think it's the right decision, but it's funny to me that so much time has passed since we stated the intent without ever doing it.

[damianmoz]

This was on my list of feature requests too. I am not a functional programming expert by any means and I could be wrong but if the existing limitations on Chapel's where clause are removed, your problem is solved. I think. Syntactically, does not Chapel already have the mechanism to address this request, although Chapel would need to allow nested where clauses. See this 62 year old solution using a fully-functional where clause by Barron and Strachey (which was adopted in Haskell a while ago so it is still highly relevantl): Barron+Strachey2007-CartesianProduct.pdf

A more succinct exposition of the solution (but with less background and detail) appears towards the end of:

http://www.math.bas.bg/bantchev/place/cpl.html

Unleashing the potential of the where clause would also equip Chapel with some limited functional programming capability (FWIW) amongst other benefits.

This is not a language change per se and certainly not a criticism of the existing where.

What would a faster, a for or where based solution? Hmmm?

My 2c (and apologies for suggesting heaps of work for some poor bunny).

[damianmoz]

Note my edit. I forgot a have which totally changed the meaning of one sentence. Brain/Finger/Eye co-ordination issue by the typist. Sorry.