On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
Hi all,
[--snip--]
Another reason put forward is support for the applicative do syntax. But that is, in standard terms, only a future possibility at this point. Further, the syntax is arguably rather dubious anyway as it, in particular to someone with an imperative background, suggests a sequential reading which is exactly what applicative is not and why it is useful. So from that perspective, using the applicative operators directly, without any syntactic sugar, actually amounts to a much more transparent and honest syntax, even if a bit more verbose in some cases.
"Verbose" is the understatement of the year. There's a lot of code where ApplicativeDo makes the difference between "readable" and "unreadable". Like it or not, but programmers are used to *naming things* (even locally) and using those local names to refer to things. "Random" combinations of <$> and/or <*> and/or... (whatever) with no concrete meaningful names don't really work if you're working with concrete CRUD-like data. (Fine, if you're working with very abstract things then you might not even have meaningful names and so they lose their value. This is *not* the universal experience.) I should also say: I certainly *understand* the textbook argument, but if we're going that way, then we're going to end up like C++... before C++11/C++14. The C++ community/committee have realised their mistake (stagnatiation) and resolved to instead produce more/better/newer textbooks. For the better, IMO. We can certainly argue over individual changes, but this is not a good *general* argument against change. Have you surveyed the actual number of books out there which show how to implement Monad instances and how many of them would be affected? Regards,