Interesting, is F# can solve this problem with active pattern?
Probably. See https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/active-pat... for details of active patterns in F#. The syntax is seriously twisted. You *can* associate data with the partitions, but it's really not obvious. If you want to classify something more than 7 ways F# is unhelpful. F# active patterns are not entirely unlike view patterns https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns only stranger.
view patterns are "active" too, sure while they are callable :) Unfortunately I am not so familiar with both to compare them in detail. Are they equal in capacity/in general or only partially? I mean, can Haskell view patterns cover all possibilities of Active Patterns of F#?
Pattern matching in Haskell does not seem enought flexible, for example, if I have `data D = D a b c d`, how can I match it without placeholders for `D` args? Something like `D...`? I need to write `D _ _ _ _` if I want to match without to bind args, right?
Yes, but (a) in all seriousness, that's not much of a problem, surely and (b) there is an alternative. If you write instead
data D a b c d = D { f1 :: a, f2 :: b, f3 :: c, f4 :: d }
then you can abbreviate patterns like this:
f (D{}) = ()
g (D{f1 = x}) = x
If you have enough fields for counting the placeholders to be a problem then you have enough fields that you really *ought* to be naming them anyway.
That it is, good! Thanks for this hint!
The problem with making pattern matching overly flexible is that people have to read and understand this stuff. It's a bit like regular expressions: POSIX regular expressions can be implemented to take linear time (by simulating an NDFA), but they are a bit limited, whereas Perl regular expressions are very expressive indeed, but they can all too easily take exponential time, and it isn't easy for John and Jane Doe programmers to tell when that is going to happen.
Sure, true.
Generally speaking, before proposing language changes, it's always a good idea to see if you can solve your problem by factoring out common stuff into a new function (or type, or typeclass) first.
Sure, but there is another point of view here. Alternative is to have flexible but elegant syntax embedded in language, instead of many-many extensions for any possibility - they "fragment" language. But of course this is controversial and ambiguous :-) === Best regards, Paul