Attempt to properly implement ? and + signature semantics

[mikhail-barg]

This PR attempts to address #776

I'm referring to the docs on + and ? and my interpretation of these lines is as follows:

• if an argument with ? does not match anything, it gets no value => gets undefined;
• if an argument with + matches multiple values, it gets an arry of these values as a value (because there's no other way to pass multiple values into a single argument), so:
  • n+ matching 1.0 would result in a literal 1.0
  • n+ matching 1.0, 2.0, 3.0 woul result in array [1.0, 2.0, 3.0]

As you may see, I've only changed recently added 035 and 040 tests to match the semantics above, so I believe this change is not a major breaking change. It's more like covering previously vague topic. I've also added a number of tests to display the behaviour more explicitly.

@andrew-coleman what do you think?

[Turings98apprentice]

While I would agree that the docs do not seem to match the current behavior, I do believe this is a breaking change, because it changes how function arguments are set. JSONata scripts written before this change would have no guarantee of working the same after this change.

I think this is a step in the right direction for function signatures, but I also think we need to examine this issue a little deeper before making v3.0. For example, there are still other [undocumented (oops)] issues with how function signatures work that we should make an effort to address/correct in the same version jump (imo).

[mikhail-barg]

@Turings98apprentice Thanks for pointing to another unexpected signature cases. I've added cases 045-047 based on your examples, and while 045 is passing with my changes applied, 046 and 047 are not.

I see where the problems are coming from in these cases, and I believe it's impossible to slove those with the current regex-based signature validation approach.

Since you've mentioned approaching v3.0, I think it would be possible to re-think the signature engine as a whole. So I made an mock/MVP with a custom state automata. Please see signature2.js and signature2-test.js for the idea of the behaviour becoming possible.

This automata approach is based on this paper. I've had an implementation of it once before and I believe it gives quite a lot of flexibility. So what do you think?

Note: this is totally a WIP/proposal, so there are some features laking:

• no support for () groups
• no support for array/function <> arguments
  but these should be straightforward to add.

I've also haven't followrd the linter guidelines yet (and I'm totally not fluent in JS at all), but I'll fix those in case this proposal gets motion.

@andrew-coleman FYI