Relationship between single-argument function expressions and pattern-matching switch condition fragments

[gwhitney]

There seem to be (at least) two places in civet where expressions with one "hole" are used, in single-argument function expressions (SAFEs) and in condition-fragment patterns in a switch. They have some similarities, such as right now the hole can more or less only occur first, and some differences in that .prop is a SAFE but not a valid condition fragment, !& is SAFE but ! isn't valid as a condition fragment, etc.

Would it be worthwhile to attempt to unify these two sorts of things precisely? I could imagine as an ideal that exactly the same expressions would be allowed as SAFEs and as condition fragments, with exactly the same rules as to when the & can be elided, either by extending the places it can be elided in a SAFE (so that e.g. > 3 would become a valid SAFE returning a boolean), or reducing the places it can be elided in a condition fragment (so that one would have to write the condition as & > 3).

One possible step toward this state of affairs would be just to allow any unary function as a condition in a switch statement, if that's feasible:

switch x
   ($) => 'haystack'.includes($)
      console.log('Found it in the haystack')
   &.callback a, b
      console.log('Callback succeeded')

I realize there is another difference in that the condition fragment > 0

switch x
   > 0
      console.log 'positive'

is inlined to x > 0 whereas at the moment & > 0 compiles to (($) => $ > 0) but this at first blush seems to be just a matter of code generation: it's plausible that Civet could detect the places where SAFEs are safe to inline and always do it, e.g.

(& > 3) 5;

would always compile to 5 > 3 rather than (($) => $ > 3)(5) as it does now. And switch statements seem like they would be one place where such inlining would always be ok.

Would it make Civet feel more systematic/uniform if there was just one mechanism underlying both these features?

[edemaine]

Nice catch of inconsistency. These two situations do share grammar rules, if I recall: explicit & followed by binary operators should behave exactly the same as switch matches (without &).

I agree that it'd be nice to allow functions, especially & functions, as switch patterns, which would allow these two cases to be more notationally consistent.

.prop is just some shorthand for &.prop because it's unambiguous. We can't do the same for > 5 because a typical use would be array.filter > 5 which already has a meaning. So we write array.filter & > 5 in that case.

So the most uniform I can imagine is that the & forms work in all scenarios, but when you can omit the & needs to depend on the setting I think.

[gwhitney]

Yes, SAFE with & allowed anywhere including switch conditions and initial & always allowed to be elided in switch conditions and otherwise only before . and ?. seems quite reasonable & consistent to me.

[edemaine]

@STRd6 Does allowing functions match your vision for pattern matching switch? Or how were you imagining adding arbitrary predicates?

[STRd6]

I think allowing single argument predicate functions is a consistent and coherent expansion of pattern matching.

Things like this are consistent with our existing concepts and would be nice to have:

switch x
  .name is "Cool"
    ...