I could rip out all methods except their minimal complete definition from every type class, and have those other methods be "algorithms that require instances of the type class". However, you can now only have a single minimal complete definition for each type class, which is less flexible. Let's pretend that you can somehow have multiple MCDs. Now, the default definition of the algorithms that were ripped out can't depend on that MCD, because they are out of the type class. That's another loss of flexibility. All in all, I see no gains and only losses in ripping out methods from the type classes.
Of course, you don't have to rip out every default method. It makes sense to keep some when you have multiple MCDs.
If you can explain to me what your proposal allows that can't be done right now, I'm open for discussion.
Of course, you can achieve that already in your library, but what I'm proposing is to separate the two purposes you have for implementing typeclasses. Instead, the user would implement a typeclass to fulfill type requirements, and would overload an algorithm to provide optimizations.
I really don't think the same advice can be applied here, and I don't see why it should. Type classes and regular structs are conceptually very different entities, even if they are implemented in the same way.
Perhaps, the advice doesn't directly apply. However, bloated typeclasses seems to be bad design. C++ concepts are never bloated like this nor are haskell typeclasses.
I agree that `bind` isn't a good choice. I'll think of something, but `apply` and `compute` are out of question because Monads are not computations; that's just one metaphor.
Also, I think it would be better to call the `Monad` concept, `Computation` or something like that, since monad doesn't mean anything at all outside the FP community.
First, I find Computation to be too reductive. Second, I don't want to rename a concept that's well known in FP and unknown in C++ to something else that's unknown in C++; I'd rather keep the well known FP word. Anyway, the day where all C++ programmers will know Monads is coming, but DQMOT.
The definition of a monad from wikipedia is a structure that represents computations defined as sequences of steps, so calling it `Computation` makes sense. Also the definition and the name is simple and clear to a lot of non-FP programmers. In contrast, calling it a monad and then defining it as an applicative with the ability to flatten values that were lifted more than once, is pretty meaningless to most C++ programmers. Monads as computations is just one metaphor, but it is the metaphor most familiar to C++ programmers. Or do you think there is a better metaphor for C++ programmers? Here are some other thoughts after looking at it more: - A lot of functions can be implemented with just `Iterable`, such as fmap, concat, cons, filter, init, take, take_while, take_until, etc. Or am I missing something? - The parameters to the functions are backwards to what most C++ programmers are used to, which will be the source of unendless confusion. I assume they are in this order because of its usefulness for curring inside applicatives. Perhaps instead, you could have another function adapter that rotates the first parameter to the last parameter, and then still keep the C++ convention of putting the sequence first. - It's important to note that the `decltype_` function will only work for constexpr-friendly types. - There seems to be a lot of copying by value, where it should use perfect forwarding. Has this been tested with non-copyable types and expensive to copy types as well? -- View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-... Sent from the Boost - Dev mailing list archive at Nabble.com.