Even simpler custom matchers

[tabatkins]

I'm glad we added the new feature that the Symbol.matcher method can just be a boolean predicate for simplicity, but playing with some examples I don't think it's gone far enough.

If you have a boolean predicate in hand, the only way to invoke it within match is:

match(x) {
  when(${{[Symbol.matcher]: predFunc}}): ...;
}

(In this particular case you could instead write if(predFunc(x)), but if the value you're testing is arbitrarily deep in a pattern you can't easily do that; you'd have to bind the value with an ident matcher and then put the test in the following if(), which disconnects the two. Not ideal.)

It would be nice if we could write when(${predFunc}), and automatically infer that if predFunc is a function (and doesn't have a [Symbol.matcher] on it either), we should just call it with the matchable, treat the return value as a bool, and resolve it to the matchable as a pass-thru. (So you could use with on it as normal.) That is, treat it identically to the more verbose version above.

(Note Yulia's "Layer 1" in the alternate proposal https://github.com/codehag/pattern-matching-epic, which is just predicate functions. The syntax there doesn't work properly when you expand out to the full feature, but the use-case seems reasonable.)

---

If we did this, it's adding another carve-out to the fallback case (just === match) for non-primitives in ${} patterns - now, in addition to 1) objects with [Symbol.matcher] written by the author, 2) all the built-ins, and 3) every class, we add 4) every function to the list of "things that do something more complicated than just ===".

This is making me less sanguine about having that fallback case at all. We still want it for when the expression resolves to a primitive (for symmetry with the literal matchers, and just general usefulness), but I'm leaning towards non-primitives instead just throwing at runtime if they don't match one of the above cases. If you do want to equality-match against a non-primitive object, with this new functionality that's still pretty trivial - ${x=>x===someObj}. (And arguably this is clearer than ${someObj}, which looks like it's probably invoking a custom matcher rather than just using simple equality.)

This would also make it safer to add more cases in the future, like if we add enums or similar.

Thoughts?

[theScottyJam]

every class

I'm not aware of every class having a special behavior when used with ${...} syntax?

(And arguably this is clearer than ${someObj}, which looks like it's probably invoking a custom matcher rather than just using simple equality.)

Hmm, you have a point here.

[tabatkins]

I'm not aware of every class having a special behavior when used with ${...} syntax?

Relatively new - as part of defining built-in matchers, we put one on Function.prototype that checks if the matchable has the function as its constructor. That way you can do ${MyClass} and get an instance check for free.

Wait, shit, that'll mess up this idea I think. @ljharb? Can we distinguish constructor functions from other functions?

[ljharb]

You still need the ability to === match against functions.

No, sadly all functions are effectively indistinguishable - constructors are just functions with a Call slot that throws.

[tabatkins]

You still need the ability to === match against functions.

Yeah, I covered that in my post - ${x=>x===someFunc} would work.

No, sadly all functions are effectively indistinguishable - constructors are just functions with a Call slot that throws.

Argh :( Wonder if it's worth adding a keyword to invoke a function then, like when(pred ${foo}), where pred ${...} is another matcher pattern that expects the ... to resolve to a bool-returning function.

[ljharb]

Encouraging inline creation of arrow functions would be a blocker, as it was for pipeline F# style and PFA.

[tabatkins]

No, F# pipeline required inline arrow functions for basically everything non-trivial. Allowing arrow functions for relatively rare expansion opportunities is a different beast entirely. Don't take the wrong lesson.

[ljharb]

That’s fair, but it still seems surprising to me to have such a special case for functions.

[tabatkins]

Well, it would be a "special case" for everything that doesn't have a special-case in the spec already (primitives, and objects with custom matchers)

[noppa]

Maybe there should be a helper like

Function.matcher = predFunc => ({
  [Symbol.matcher]: predFunc
})

match(x) {
  when(${Function.matcher(predFunc)}): ...;
}

Sure, it's not quite as succint as just when(${predFunc}), but maybe the verbosity comes with certain explicitness that could even make it more readable. At least it's more readable than the inline ${[Symbol.matcher]: predFunc} version with all its brackets.

[tabatkins]

And note that you're even missing a pair of brackets there! It's ${{[Symbol.matcher]: predFunc}} actually ^_^

[codehag]

TL;DR -- before we get too deep into this, it might be worth understanding the purpose of this in my document before trying to integrate it, and also discussing if the form that it is currently in is the right one. But not for the technical reasons listed here, at least not in my opinion.

It could be that the existing syntax is what should be used. The two were developed with different goals in mind so that explains why they differ. What I did was with providing a very simple way to write any matcher out of the box.

The interpolation is for arbitrary expressions. Therefore

function matcher() {
  return whatever // tbd. Could be a simple boolean, could be a custom matcher. 
}

match (x) {
  when (${matcher(x)}) : ... // match against a matcher, similar to ${(x=>x===1)(x)}
  when (${func}) : ... // I guess this match to the pointer of the function with ===, or fall back on a matcher
}

in my layering approach, i took a short hand for ${matcher(x)} which is matcher or the SymbolMatcher, with the goal of allowing things to be built up in parts. So the following would be equivalent:

function matcher() {
  return whatever // tbd. Could be a simple boolean, could be a custom matcher. 
}

match (x) {
  when matcher : ... // match against a matcher, similar to ${(x=>x===1)(x)}, or falls back on SymbolMatcher
  when (${func}) : ... // match to an arbitrary expression, in this case, the pointer of the function with ===. No longer falls back. 
}

It is just another shorthand, similar to {}, [] etc. It is useful in that it lets the proposal be broken up in the way that I did. Taking it out of context may not make sense. My thinking was that we would do a check for [symbol.matcher] -- if it isn't present and is a callable, call it. if it doesnt return a matcher, throw. This is the thinking behind the option.some matcher here: https://github.com/codehag/pattern-matching-epic#layer-2-custom-matchers -- In other words, a function that has a matcher on it, will go with the matcher rather than calling the function (or constructor, etc).

function func() {
  return whatever // tbd. Could be a simple boolean, could be a custom matcher. 
}

func[Symbol.matcher] = (val) => { 
  //.. whatever
}

match (x) {
  when func : ... // matches to the matcher. 
  when (${func}) : ... // match to an arbitrary expression, in this case, the pointer of the function with ===
}

in the current examples, this is a little different.

class Option {
  // ..
  static Some(val) {
    return new Option(true, val);
  }

  static None() {
    return new Option(false);
  }

  static {
    Option.Some[Symbol.matcher] = (val) => ({
      matched: #hasValue in val && val.#hasValue,
      value: val.value,
    });

    Option.None[Symbol.matcher] = (val) => ({
      matched: #hasValue in val && !val.#hasValue
    });
  }
}

match (result) {
  when (${Option.Some} with val): console.log(val);
  when (${Option.None}): console.log("none");
}

In this form, I am not sure if there is a way to check === the Option.Some function, which may be useful to distinguish. Not "is this an object constructed with this" but "is this this function".

Likewise, you may want to do something like this:

// Church Numbers
function S(n) {
  return n + 1
}

S[Symbol.matcher] = (n) => { 
  var match = false
  if (n >= 0) {
     var result = n - Math.floor(n) !== 0;
     if (result) {
      match = true
    };
    return { match }
}
  
function IsGreaterThanThree(x) { return x > 3 }

var ChurchNumber3 = S(S(S(0)))
var nums = [S, ChurchNumber3, 5, Number]

// Current
for (x in nums) {
  match (x) {
    when (${S}) : "is church number" // match on SymbolMatcher -- no access to checking if function pointer. Second two will pass
    when (${Number}): "is number" // SymbolMatcher
    when (${GreaterThanThree(x)}: "is greater than 3" // simple function matcher
    default: "Fail" // S, Number will end up here
  }
}

// maybe
for (x in nums) {
  match (x) {
    when S: "is church number" // SymbolMatcher, matches numbers that align with church numbers
    when Number: "is number" // SymbolMatcher, as number has this defined as well
    when GreaterThanThree: "is greater than three" // simple function matcher, has no SymbolMatcher
    when (${S}) : "is church number function" // Function pointer matcher
    when (${Number}) : "is number constructor"
    default: Fail
  }
}

At least, as far as my understanding of the current proposal goes. Maybe this is wrong. The current behavior, reading the spec, is if it is an identifier other than Infinity, NaN, or undefined, we do a binding. I think this is a missed opportunity. This becomes clearer when you consider what I am proposing within context.

There is a discussion to be had as to whether or not this shorthand is wise, as implicit passing of arguments may be difficult to understand for users (and there is inconsistency in my experimental writeup that needs to be discussed).

It would be great if we followed up, rather than eagerly decomposing my examples in the epic (which was not concrete, and explicitly stated that it was not a concrete change).