Re: [boost] [Boost] [Hana] Announcing Hana's formal review next week (June 10th)

Vicente J. Botet Escriba writes:

Le 15/06/15 22:39, Louis Dionne a écrit :

...

Vicente J. Botet Escriba writes:

[...]

...

* the instantiation either directly or when the type is an instance of a type class (using the second parameter). If you are referring to automatically-defined models, this is still possible. For example, the model of Monoid is automatically provided for any Constant containing something that's a Monoid too:

template <typename C> struct plus_impl() && models() >> { // implementation of plus() };

template <typename C> struct zero_impl() && models() >> { // implementation of zero<> };

The difference with the previous design, IIRC, is that in order to define a model of Monoid, you used to write something like

template <typename C> struct Monoid::instance() && models() >> { // implementation of plus() and zero<> };

Both are essentially equivalent, except that you can now define individual algorithms more easily. Yes, it is still possible, but you need more. With the previous design you you could design an mcd that forward to the current design.

That is true. This was at the cost of more complexity to customize specific algorithms. This was a tradeoff, and I decided to go this way. By the way, this move was very painful and I consider this was one of the larger design choices I had to make in the library, because it involved a ton of other smaller things visible only to someone who look closely.

...

...

[...]

* This is a library with a lot of Concepts. It is not easy to find the correct name for each of them and each of the functions in the C++ world when the concepts come from another language with different history. There are some names that I don't like, but I recognize that finding a coherent set of names is not easy.

* the fact that all the functions are in the same namespace. This imply that we need to find a different name for each function. Making use of namespaces for each concept add a freedom degree. One of my fears is that this would make the library much more complicated, especially for new users. What would happen if you had to prefix each algorithm with the name of the concept that defines it? I know I would sometimes ask myself "hey, what concept defines this?", so I can only imagine the worse for other users. I see this differently. It will force the user to ask himself, what exact function he is using.

Interesting. I think most users don't want to have to do this thinking, lol. My goal is to make metaprogramming easier for average programmers. In the mid/long term, I want Hana to be usable without even knowing about the Functor/Applicative/Monad/MonadPlus concepts & al. These concepts will still be available for more hardcore developers or FP people, and they are incredibly important because they are the basis on which the library is built. However, the average Joe who just wants a damn for_each on a tuple should not be required to understand Monads or even the Foldable concept (personally, it took a good while until I was finally comfortable with folds).

...

My preference so far has been to deal with this missing degree of liberty by selecting names that do not clash. It is sometimes a bit annoying, but I think the resulting simplicity is worth it. Currently you are free to use any names in boost::hana, but how would you name them if you were writing a proposal for the C++ standard? We will have Range-V3 one day and others that make use of similar names. Associating the names to the concepts allow to get rid of all these possible clashes.

I would try to piggy-back the same names as the Range-v3 library in my proposal, so that you can use algorithms both on tuples and runtime ranges. Actually, I think that's the future. But designing for the standard and for Boost are two very different things. I'll try to get the first one right, and then see if I want to go for the second too.

...

...

[...]

* Why and when free functions or member functions are used. I'm not sure whether it is Hana's job to explain why free functions are better than member functions for generic programming. I don't know, but I feel like anyone reading Hana's tutorial would know the answer . It seems that you use free functions everywhere except when you can not. Am I wrong?

Global function objects would be more precise, but yeah I think that's it. Off the top of my head, I'd say the only member functions are - .times for IntegralConstant, because that looks nice - operator[] for Sequences, because it has to be implemented as a member

...

...

The reference documentation is a little bit confusing for some one used to the C++ standard way. * The terms Concept/Superclass/Methods, ... Now using Concept/"Refined Concept"/Functions.

Thanks.

...

...

* A more formal definition of the mappings from concrete type to Concepts and the Super classes

Maybe this is enough for Boost, but I would like to see a more C++ standard like documentation. I'm not sure I understand what you mean by a more formal definition of the mapping from concrete type to concepts. Do you mean that the requirements of a concept should be defined more formally?

I would like a description that defines what expressions are valid given some constraints on other expressions.

Ok, so syntactic requirements instead of just semantic requirements. That seems a legitimate and useful thing to document. See this issue [1].

...

...

[...] I will do it as soon as I install the good compiler version. You can try it online at [7].

I will do. I would like to see how something like the metaparse library or

(http://blog.mattbierner.com/stupid-template-tricks-pride-and-parser -combinators-part-one/) becomes while using Hana interface.

That would indeed be a very interesting experiment. However, that would take a lot of time and I can't afford to do that right now. Perhaps later after the review, when all those issues I'm accumulating are fixed :-). Regards, Louis [1]: https://github.com/ldionne/hana/issues/127