Fix unhelpful error message for node evaluators

[desa]

Fixes #1452

Log line now reads like

[missing:where2] 2017/07/07 11:05:08 E! error while evaluating expression: Cannot call function "sigma" with args ("y": missing), available signatures are [(float)].

Required for all non-trivial PRs

• Rebased/mergable
• Tests pass
• CHANGELOG.md updated

[nathanielc]

@desa I am not quite sure how to read that error message. Does the : indicate type information follows?

So if I called a function like foo("y", "x") and "y" is missing I get an error like:

Cannot call function "foo" with args ("y": missing, "x": int64), available signatures are [(float, int64)].

That seems confusing to me as it requires the read to understand that missing is a type inside lambda functions and figure out that their value is missing which is why the function cannot be called.

How hard is it to detect that 1. there is not valid signature and 2. special case the missing type to have a direct error message that says something like Cannot call function "foo" argument "y" is missing, values in scope are [...]? Then errors about type mismatch (excluding missing) can list the arg types, and available signatures as above.

[desa]

@nathanielc

Does the : indicate type information follows?

Yup.

1. there is not valid signature
2. special case the missing type to have a direct error message

Special casing missing should be easy.

Just so I'm not off track, the end result is that we'll have two types of error messages.

1. One for missing types that will read

Cannot call function "foo" argument "y" is missing, values in scope are [...]?

Any thoughts on what the log line should look like if there are multiple missing arguments? And should the values in [...] include type information?

2. One for all other types that will read

Cannot call function "foo" with args ("y": missing, "x": int64), available signatures are [(float, int64)].

[nathanielc]

If there are multiple missing list them all. Do not include type information in the list of vars in scope. The idea is to make it easier to spot a typo or similar in the names of the vars.

Sounds like we are on the same page.