[Due to time constraints, this is a quick weigh-in without fully having
done my homework... apologies for that]
I think that we have definitely found value in putting additional
non-varargs formals after a vararg formal as Michael illustrated -- IIRC,
we've had cases where we've done this and benefitted from it (though I'd
have to dig through code to remind myself when/how). Specifically, it's a
nice way to add an optional argument to an otherwise flat vararg function.
By extension, I could imagine that having multiple varargs _could_ be
useful, though I haven't wanted it myself, and don't have any compelling
examples in mind. So I'd rather not outlaw it forever, though I could
imagine having the compiler say "our implementation doesn't support
multiple varargs functions yet -- please let us know if you would like
this feature."
Here are some cases to keep in mind:
* if the varargs are all of a consistent type (inferred or declared),
a change in actual type would suggest ceasing to parse into the
varargs. Here's an example that seems to work on master as I'd
expect:
proc foo(x...?t, y) {
writeln("got x = ", x);
writeln("got y = ", y);
}
foo("hi", "there", 3.0);
Similarly, it seems like one ought to be able to assert that a
varargs argument is homogeneous in type, though I'm having trouble
finding a syntax that works in the current implementation. But
imagine a case like:
proc foo(x...string, y) {
or:
proc foo(x...string, y...int) {
where the first would accept
foo("hi", "there", 3.0);
and the second would accept:
foo("hi", "there", 1, 2, 3);
This seems like a natural extension to what we have today.
Bottom line: I don't think Chapel should rule out such cases in the
long-term, though if we want to do it in the short-term to exchange a
segfault for a "not yet supported" message, I think that'd be a nice
improvement.
-Brad
On Thu, 3 Mar 2016, Rajath Shashidhara wrote:
> Hello,
>
> More than one variable arguments can be useful in this situation -
>
> proc vari(x, y ..., m:int, z:int, p...) {
> writeln(x);
> writeln(y);
> writeln(z);
> writeln(m);
> writeln(p);
> }
> vari("lions", "tigers", "bears", m=5, z=6, "dogs", "cats");
>
> Currently this fails to compile.
>
> I would expect all these statements to work -
> vari("lions", "tigers", "bears", m=5, z=6, "dogs", "cats");
> vari("lions", "tigers", "bears", z=6, m=5, "dogs", "cats");
> vari("lions", "tigers", "bears", 5, 6, "dogs", "cats");
>
> But, if you consider this scenario -
> vari("lions", "tigers", "bears","dogs", "cats", m=5, z=6);
> then assigning actual parameters to formal parameters is not possible.
> (unless we can set p to empty set ?)
>
> In the general case where variable args are interspersed with single
> args, it would become very hard to keep track of the assignment of
> actual parameters to formal parameters.
> for example,
> proc vari(x, y ..., m:int, z:int, p..., k:int)
> and
> vari("lions", "tigers", "bears","dogs", "cats", k=2, m=5, z=6);
> vari("lions", "tigers", "bears","dogs", "cats", k=2, "apes", "cows", m=5,
> z=6);
>
> I think it is best not to mix var args with regular arguments.
> Hence allowing it only at the end of a parameter list is best in the
> interest of readability and writability.
>
> Thank you,
> Rajath Shashidhara
>
> On Thu, Mar 3, 2016 at 7:46 PM, Michael Ferguson <[email protected]> wrote:
>> Hi Rajath -
>>
>> Thanks for looking into this bug.
>>
>> I'm hoping somebody else will also weigh in but here are my thoughts:
>>
>> I'm leaning towards agreeing with you about two var-args
>> arguments not being useful, but I might be missing something.
>> You can, for example, have
>>
>> proc vari(x... , otherArg:int) { }
>>
>> and call that with something like this:
>>
>> vari(1,2,3, otherArg=4);
>>
>> but I can't think of any way to do a corresponding thing with a
>> second var-arg.
>>
>> Also, we might get a better error message in this case if you
>> just detect the situation after or during parsing (rather
>> than making the parser not accept it). That way, we might get
>> an error like
>> error: multiple var-args arguments
>> instead of
>> error: syntax error
>>
>> -michael
>>
>> On 3/3/16, 8:20 AM, "Rajath Shashidhara" <[email protected]>
>> wrote:
>>
>>> Hello,
>>>
>>> I ran strace on the chapel compiler for the code snippet given in this
>>> issue :
>>> https://chapel.atlassian.net/browse/CHAPEL-178
>>>
>>> I noticed that Chapel compiler runs into a SIGSEGV for this input.
>>> Using gdb, I have identified that there is a problem in
>>> expandVarArgs() in chapel/compiler/resolution/functionResolution.cpp
>>>
>>> But, I think the problem lies in the grammar definition. I don't think
>>> it is meaningful to allow more than one variadic arguments in the
>>> function declaration. It will make it impossible to assign actual
>>> parameters to formal parameters in this situation.
>>>
>>> If we agree that this is a grammar definition error, I can dig into
>>> the bison grammar specification and correct it to allow only one
>>> variable argument definition (at the end of parameter list).
>>>
>>> I can also dig deeper into the source code (understand the
>>> expandVarArgs()) in case this is not a grammar defn error.
>>>
>>> I would like to know your opinion!
>>>
>>> Thank you,
>>> Rajath Shashidhara
>>>
>>> --------------------------------------------------------------------------
>>> ----
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Chapel-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
