Re: [boost] [metal] Feature Complete - Request for Feedback

Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: Jared Grubb (jared.grubb_at_[hidden])
Date: 2017-02-22 02:21:17

> El feb. 20, 2017, a las 13:59, Bruno Dutra via Boost <boost_at_[hidden]> escribió:
> 
> On Mon, Feb 20, 2017 at 10:06 PM, Klemens Morgenstern via Boost <
> boost_at_[hidden]> wrote:
> 
>> From a first look at it, this looks quite awesome.
> 
> 
> Thanks!
> 
> 
>> What I do however wonder is, where does it fit in with MPL, Fusion and
>> especially Hana? If you could give an overview of where your library is
>> compared to those, you probably increase the support for your library.
>> 
> 
> That is a very valid concern and I wondered myself whether there was space
> for Metal in Boost for quite a while, before finally deciding to put this
> proposal forward.
> 
> It basically boils down to whether template metaprogramming (TMP) is still
> useful to modern C++, given decltype and the paradigm shift it enables,
> which is very well explored by Hana. I believe that yes, TMP has its unique
> use cases, mainly because:
> 
> * it scales much better in terms of both compile time and memory usage on
> all major compilers. To convince yourself, just check metaben.ch and be
> sure to play with the 'subtract baseline' switch;
> * It integrates nicely with standard type_traits and utilities;
> * It draws a clear line between type-level and value programming, which
> improves readability when the goal is to trigger SFINAE and drive overload
> resolution.
> 
> Essentially I advocate you are better off using TMP if you are either
> dealing with a couple of dozens to thousands of elements or all you want is
> to constrain types to implement concept like requirements for functions
> templates.
> 
> Now, since we still need TMP, the following question is whether MPL fits
> our needs. I posit that it can't possibly for several reasons, the most
> apparent being:
> 
> * it is _very_ verbose, mainly because the necessary tools, such as alias
> templates, weren't available at the time it was developed;
> * it doesn't scale at all, because it relies on the preprocessor to emulate
> variadic templates, which is orders of magnitude slower and more memory
> hungry than pure TMP on a given compiler. Again you don't have to take my
> word for it, just browse metaben.ch.
> 
> Finally, comparing Metal specifically to Hana, I believe it has some
> potential advantages besides what I've mentioned so far:
> 
> * Metal is much lighter conceptually than Hana and in fact relies on only a
> couple of very simple concepts that are precisely defined early in the
> documentation, which are sufficient to formally describe every construct
> that the library provides [1]
> * being fined tuned for heterogeneous programming more than anything else,
> Hana happens to also support type level computations, while Metal is
> specifically designed for that end and is thus able to provide better tools
> in my opinion.

I'm not really sure I fully understand your comparison to Hana.

It sounds like you're saying that "Metal is smaller and simpler than Hana", in that Metal (1) has simpler/fewer concepts and (2) has a more restricted focus. It seems that Metal probably does something Hana does not, but I'm not sure what it is from this overview. 

When you propose Metal, I think it will be important to justify why Metal is useful in Boost even though Boost already has Hana. For example, is there something Metal does better (where "better" could be smaller code, faster code, faster compile, etc)? I think "simpler API" by itself is not quite enough, but I'm sure you have other reasons. It would be good to have a section of your proposal to show concrete examples.

> 
>> On a less important note: I'm not sure about the name, I immediately
>> thought of bare-metal C++ when I heard that. But that might just be me.
> 
> 
> To be honest neither was I when I picked it, however, after 2 years of
> development I learned to like it and started naming a couple of offspring
> projects after the same semantic domain, for example Alloy [2], where Metal
> is used as a backend to heterogeneous algorithm (it is very early in its
> development, but one can already see some use cases for Metal).
> 
> [1]: http://brunocodutra.github.io/metal/#concepts
> [2]: https://github.com/brunocodutra/alloy
> 
> Best regards,
> Bruno
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost