Parsing for safe call expressions, existential expressions

[wcjohnson]

Q	A
Bug fix?	no
Breaking change?	yes
New feature?	yes
Deprecations?	yes
Spec compliancy?	na
Tests added/pass?	yes/yes
Fixed tickets	na
License	MIT

Safe calls

f?(x)

typeof f === "function" ? f(x) : null

Safe tilde calls

a~f?(x)

typeof f === "function" ? f(a,x) : null

Existential expressions

@rattrayalex Putting this here for you to look at, can be seprated out if desired.

x?

x != null

(note non-strict eq)

Notes

• Whitespace is not permitted before the ? in existentials or safe calls, and not permitted between the ?( in safecalls either. If there is whitespace present it will be parsed as a ternary.

• There is one grammatical ambiguity due to flow type casting. In vanilla JS, (a?(b):c) is parsed as a ternary -- here it is now being parsed as a Flow typecast of a safecall.

Note that this ambiguity is incredibly obscure. It only takes place if the whole expr is wrapped in parens (as is required for a flow typecast) AND the consequent is wrapped in parens AND no spaces are put on either side of the ?. In fact this ambiguity does not arise in any of the babylon fixtures and I had to discover it on my own.

[rattrayalex]

As discussed on gitter (and possibly elsewhere), I will indeed be passing on the existential expression. People should use ~isNil() instead. I definitely appreciate your work put into that; it's a good feature and seems well-implemented, I just want to keep the language small for now.
I'm open to reconsidering in the future if there's strong demand and good reasons that ~isNil() is inadequate.

As for f?(), I'm a bit more open-minded, but again leaning towards passing on the feature, primarily because it's not the kind of thing that is typically used very frequently and will therefore require a trip to the docs anytime someone encounters it.

I also am hopeful that match will reduce its necessity:

cbResult = match options.someCallback:
  | ~isFunction() with (cb) => cb(args)
  | else: null

That's obviously a lot more verbose than

cbResult = options.someCallback?(args)

but technically more powerful (you can also handle if it exists but isn't a function more cleanly) and hopefully more clear.

Again, I'm impressed with the work that went into this, and grateful for the PR. I also do think it's great that you're experimenting with these things on your own branch and while the oigroup version of LightScript has different philosophies, there's no doubt that it would hold appeal.