Hi Chris --
It is correct/intentional that you would have to expand the 'kargs' tuple in order to pass it into another varargs function. The reason is that varargs argument lists are stored within the function's body as a tuple whose the is the argument's (in this case 'varargs'), and passing a tuple to a varargs function causes the tuple to be interpreted as the first/only argument in the actual argument list. Of course, the other option would be to have the subsequent calls accept the expected tuple type (if you can predict it) in which case you wouldn't need to expand the tuple. But expanding the tuple would be the typical way to keep forwarding varargs onwards. Or, if you were able to make the subsequent function definitions nested within the first, they could refer to the original varargs tuple without needing to pass it along through normal lexical scoping. Because Chapel is statically typed, heterogeneous (non-homogeneous) tuples require their indices to be param values so that the compiler can determine the type of the resulting expression. Homogeneous tuples don't require this since the resulting type will be the same regardless of the index: var x = (1, 2, 3); var y = (1, 2.0, "three"); config const i = 2; writeln(x(2)); writeln(x(i)); writeln(y(2)); //writeln(y(i)); // error -- compiler can't tell the type of y(i) The "too many times" instantiation is almost always indicative of something running off the rails (i.e., most types don't require that many instantiations -- essentially, "How many times has a generic type been stamped out for a different signature?" A frequent cause of running into this is to try and instantiate a generic type with itself resulting in an infinite instantiation of sorts. If you feel you're running into this in error and could provide a code sample demonstrating hitting the instantiation limit, that would help out. -Brad ________________________________ From: ct clmsn <[email protected]> Sent: Wednesday, November 16, 2016 9:44:00 AM To: [email protected] Subject: variable arguments, tuple expansion, and params use chapel-users/developers, found a small issue and was unsure if this is an expected or unexpected feature. ::variable arguments, tuple expansion:: proc callb(kargs...?k) { writeln(kargs); } proc calla(kargs...?k) { writeln(kargs); callb(kargs); } calla(1,2,3); the output is: (1,2,3) ((1,2,3)) at the moment, i can "sort of" hack around this issue by expanding the kargs tuple prior to calling callb in the function calla proc calla(kargs...?k) { writeln(kargs); callb((...kargs)); } :: params use :: when passing particularly complex, non-homogenous tuples into kargs (example: calla((1,2), (3, "cat"))) are there best practices? i've a program in which the kargs tuple going into calla needs to be passed around to several smaller functions in calla and there have been a couple occasions in which the compiler will claim "error: invalid access of non-homogeneous tuple by runtime value" or "Types.chpl:356: error: Function 'isHomogenousTuple' has been instantiated too many times note: If this is intentional, try increasing the instantiation limit from 256". in these cases, i've had some success annotating the value used to index kargs a param. thanks! ct
------------------------------------------------------------------------------
_______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
