Pattern Matching Champions
2024-01-24
plaintext logs
prev next
source on github
22:58
<rbuckton>
hello, rbuckton will you consider update how customMatchers are written in https://onedrive.live.com/view.aspx?resid=934F1675ED4C1638%21299428&authkey=!AEyZcVuri5fJLbQ (page 17)? It does not match what pattern matching using now in raw.githack.com/tc39/proposal-pattern-matching/new-spec/index.html
What is the purpose of receiver in a custom matcher?
23:02
<rbuckton>
I'm not sure I'm a fan of how InvokeCustomMatcher makes custom matcher implementations more complicated.
23:04
<rbuckton>
In the slide you point to, I have to add a number of extra conditions around return values to align with InvokeCustomMatcher just doing a ToBoolean on the result when the hint is boolean, and I'm not a huge fan of return type inconsistency.
23:11
<rbuckton>
In my opinion, a "hint" should primarily inform the method as to whether it does or does not need to perform additional computation/allocation when it isn't necessary. Having to check hint to ensure my return { match: false } isn't interpreted as true doesn't really match with the idea of a hint.
23:13
<rbuckton>
Is there a reason we consider anything other than MatchResult | boolean | undefined to be a valid result? If we restricted the result to just those cases, then we can have simpler custom matcher bodies that only need to elide the value portion if it won't be used.
23:18
<rbuckton>
Ah, I guess it's just boolean or Iterable now?
23:18
<rbuckton>

To be honest, if we had ADT enums, I'd have suggested we have something like:

enum MatchResult {
  Fail,
  Pass,
  One(result),
  Many(...results)
}

And have a custom matcher return MatchResult | boolean | undefined

23:19
<rbuckton>
With MatchResut.One(result) so that we don't need a full iterator protocol for a unary extractor like when Point({ x, y }) just to wrap the { x, y } result that will be further destructured.
23:24
<rbuckton>
In my opinion, a "hint" should primarily inform the method as to whether it does or does not need to perform additional computation/allocation when it isn't necessary. Having to check hint to ensure my return { match: false } isn't interpreted as true doesn't really match with the idea of a hint.
After further reflection, hint here isn't so bad since I don't need to differentiate between a { matched: false } and a { matched: true } anymore. I still think it would be nice to be able to optimize for the unary-extractor case in some way.