Looking at the example code, it seems that this is perl-ifying Python. And I'm not saying that as a good thing. The code is more terse and less readable & understandable.
Some of those are very needed constructions (like algebraic data types with pattern matching), but it's adding an entire sub-language into a language that is built on the goal of being simple. I'm not sold into it either.
The sum types are create by multiple data declarations joined by directives. It's ugly, messy, error-prone and as your sibling comment says, misses the point of enabling static verification.
Everyone feels like X language is so great but if only we could add a feature from Y language to it. They then attempt to trivialize what is needed for that feature not realizing that the benefits of Y are due, in part, to the non-trivial amount of functionality. They almost always turn into a façade of the feature they truly want to support and they never gain traction because their usefulness just really isn't there.
Beyond that, some particulars:
* Being terse is a lower priority than usual
* Cool features are a lower priority than usual
* Be careful how you use and then re-use symbols (Haskell can be confusing this way).
* Use English (or whatever spoken language) in your symbols
[1]: I just made those up, but I wouldn’t be surprised if they were real.
That said, all of these things are symptoms of the preferences of the community around the language, and not restrictions imposed by the language design itself. Core Haskell is actually comprised of some pretty easily understandable functions. You can craft synonyms for more advanced abstractions such as applicative fairly easily once you understand the type system. Haskell more or less gives you everything you need to write functional programs in a way that reads like plain english--this is very uncommon however, given the language's origin and close connection with mathematics.
On the other hand, once I did get used to some of the infix operators, I started to really like some of them, i.e. how:
f data data
becomes
f <$> fancyData <*> fancyData
where what makes the data fancy might be validation, being in container like list, or even some sort of reactive-ui-component, like Flare library for Purescript does: http://try.purescript.org/?backend=flare
https://www.python.org/dev/peps/pep-0020/
"Explicit is better than implicit."