3 ms·
Regarding... A{} or B{} -> f1 a big part of the problem is that A and B are going to be putting different things into scope in the context of f1. If you'
by dllthomas 10y ago
Regarding...
A{} or B{} -> f1
a big part of the problem is that A and B are going to be putting different things into scope in the context of f1.
If you're not binding anything, you could do it with guards:
...
| isA myData || isB myData -> f1
...
- Morgawr 10y agoThis assumes that you have an isA and an isB function. This forces me to write such a function which I might not have and in case of very very very large data types (like ~20-30, if not more, constructors) it becomes unwieldy and very messy.
- dllthomas 10y agoIt's probably less work than duplicating the cases, and ideally you can give a more meaningful name to the whole "isA or isB" construct - especially when you have a lot of constructors!
- pklausler 10y agoIf he's not binding anything, he could just match C{} in the first rule and a wildcard (_) in the second.
- dllthomas 10y agoYes, but there could be a D{}, now or in the future. I rarely use wildcards that aren't embedded in the middle of some larger structure. They stop the compiler from telling me points I need to consider, as I change my code.