I am fiddling a bit starting with going through th...

# pattern-matching

[Nico]

I am fiddling a bit starting with going through the predicates to determine whether a certain whenCondition is a pattern match. Is there any way to write some low level unit tests where I can play with instantiated PsiElements in order to inspect them and test my predicates?

On second thought, I probably should ask this kind of stuff in #arrow-meta

[raulraja]

https://github.com/arrow-kt/arrow-meta/blob/master/compiler-plugin/src/test/kotlin/arrow/meta/quotes/scope/plugins/WhenConditionPlugin.kt

https://github.com/arrow-kt/arrow-meta/blob/master/compiler-plugin/src/test/kotlin/arrow/meta/quotes/scope/plugins/WhenEntryPlugin.kt

https://github.com/arrow-kt/arrow-meta/blob/master/compiler-plugin/src/test/kotlin/arrow/meta/quotes/scope/plugins/WhenExpressionPlugin.kt

[raulraja]

Those are test that prove the identity template has no effect over a transformation but it would give us an entry point to different parts of the When

[mattmoore]

This is cool! Just seeing this now but yeah I pulled down the pattern-matching branch and started adding some tests around the when expression to start verifying behavior with the compiler plugin.

I like using the match keyword as this will make it easier to determine whether pattern matching should apply. This should be more performant than what I was originally attempting with a more complex check on the left hand side, searching for patterns in use.

I'm starting to tinker with the error suppression stuff today, should have something in place soon around that. I'm also hoping to start experimenting with the type proofs stuff to get more intuitively familiar with it. Hopefully will have some code ready to add to the branch today/tomorrow.

I'm still not familiar with the ide plugin stuff, but if I have some time I'll start tinkering with that. I'm looking at the existing stuff in meta to get a sense for how that would work.

[raulraja]

we can ignore the IDE until we get post codegen

[raulraja]

Something to consider is that what we are solving is not `when`specific
wSomething to consider is that what we are solving is not specific to

[raulraja]

when we are solving expression destructuring:
val (a, Street(b)) = term

[raulraja]

when just projects the resolved scope over the RHS

[raulraja]

when not always have a subject in which case is this sae case

[raulraja]

when when has no subject all cases are boolean predicates

[raulraja]

Since at the moment we can’t determine exaustivity all we care about is creating Partial functions from the match expressions

[mattmoore]

Ah yes. Maybe I should focus on destructuring first then. Do you think it would still be a good idea to have some keyword (perhaps still match) for the more generic case? I'm thinking otherwise it might be more difficult and cause conflicts with the existing "ignore, don't assign" behavior for _