On Sun, 27 May 2018, Sven Schreiber wrote:
Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
> On Wed, 23 May 2018, Sven Schreiber wrote:
>
>> (Am I right in assuming that a new alpha argument could be added in
>> the future without compromising backwards compatibility? What I mean
>> is that a call like fevd(<int>, <bundle>) would still be possible if
>> the in the future the signature would be: <int>, <optional-scalar>,
>> <bundle>, right?)
>
> Hmm, not really. You'd need an argument-separating comma, as in
>
> fevd(<int>,,<bundle>)
>
> It's true that since the (notional) second and third arguments here
> are of different types, we could in principle check the types and
> "see" that the argument given second must really be the third one, but
> that sort of thing (auto-detection of implicitly omitted optional
> arguments) is not supported in geneval.c for any functions at present.
> Its also strikes me as kinda tricksy.
I found the part of the doc that inspired my hunch, it was in the
strsplit help:
<help-quote>
strings S = strsplit(basket,,",")
will split the input into an array of four strings using comma as
separator. The “extra” comma in the input above indicates that the i
argument is omitted, but it's not strictly necessary unless you wish to
extract a single element; if the second argument is a string and only
two arguments are given it is understood that sep rather than i is
intended. So
strings S = strsplit(basket, ",")
...
</help-quote>
So this only works in this particular function, not in general?
OMG, you're right but that now seems a bad precedent! So far as I
can see there's no way this can work "in general" without
hand-coding the argument-handling for every function to which this
special dispensation might be applicable.
I need to think some more about this. _Maybe_ there's a viable
mode of generalization.
Allin