Predicate factory

[eloytoro]

Is your feature request related to a problem? Please describe.

the match function is the way to start defining cases for a value, but its design is limited because its reactive rather than proactive, by this i mean that you can only define cases when the value exists in the scope but there's no way to define case handling logic in a deferred and composable way

Describe the solution you'd like

I think this can be solved if there were an API that allowed for the definition of cases without having the value that will be matched against them, for example

const digitsFlow = flow<number>()
  .with(P.number, (n) => n.toString().length)
  .exhaustive();

Now we have a lazy definition of pattern matching, that can be run against any number of values in a pure way and it could also be made composable

const digits10 = digitsFlow(10)

const digitsStringFlow = flow<number | string>)
  .compose(digitsFlow) // new method to compose flows together
  .with(P.string, (s) => n.length)
  .exhaustive() // ts is smart enough to know that the `number` case was handled exhaustively

Describe alternatives you've considered

the naive way of course would be to make heavy use of lambdas but it would be quite ugly for composability

const digitsFlow = (n: number) => match(n)
  .with(P.number, (n) => n.toString().length)
  .exhaustive();

const digitsStringFlow = (n: string | number) => match(n)
  .with(P.number, => digitsFlow) // here you'd have to manually check that all cases are handled
  .with(P.string, (s) => n.length)
  .exhaustive()

[phaux]

related: #215 #209

[orimay]

Just came here to open the same issue. Besides, this way we'll get rid of a ton of runtime allocations (every callback, every array — they are all objects created at runtime and bloat GC).

[orimay]

I wrote a small representation of how it might be build:

Playground