Currently ExprTuple.len raises a NotImplementedError as a mechanism to avoid confusion between num_entries and num_elements. This was useful for a time when we needed to update instantiations to use num_elements rather than something of the form num(len()). But this gets annoying because it inhibits the ability to use an ExprTuple as an iterable in a straightforward manner. For example, fn(*) fails because it tries to get the length of the iterable. It makes the most sense to have the len method return num_entries() so it can be used as an iterable, but there is some danger of there being confusion between num_entries() and num_elements(). That shouldn't be such a problem for active developers who understand the distinction well. It is also helped by the fact that num_entries() returns an int while num_elements() returns an Expression. I think this is just a matter of proper training. What do you think, @wdcraft01 ?
Currently ExprTuple.len raises a NotImplementedError as a mechanism to avoid confusion between num_entries and num_elements. This was useful for a time when we needed to update instantiations to use num_elements rather than something of the form num(len()). But this gets annoying because it inhibits the ability to use an ExprTuple as an iterable in a straightforward manner. For example, fn(*) fails because it tries to get the length of the iterable. It makes the most sense to have the len method return num_entries() so it can be used as an iterable, but there is some danger of there being confusion between num_entries() and num_elements(). That shouldn't be such a problem for active developers who understand the distinction well. It is also helped by the fact that num_entries() returns an int while num_elements() returns an Expression. I think this is just a matter of proper training. What do you think, @wdcraft01 ?