* 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.
My best understanding is that Hana is much more like Phoenix and just happens to also be able to do TMP. One of the things which annoys me about some of those who write "lightweight metaprogramming frameworks performance superior to Hana" with all sorts of wild unjustified claims is that they are usually comparing their TMP framework to Hana being used in a mode Hana was not intended by Louis to be its main use case. So of course a custom, specially written single purpose framework is going to beat a general purpose framework. So what. Bruno's Metal doesn't make extravagant claims based on unfair comparisons of apples to oranges, and is to be presented for peer review here. I therefore strongly support it over other lightweight template metaprogramming frameworks. I definitely think there is a space in Boost between full fat Hana being used in subset mode and a more specialised, single purpose TMP framework with significantly better time and space complexities. I've only skimmed the surface of Metal, but what I've seen so far looks impressive.
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.
Hana's really, really fast at its primary intended use case. Louis put a ton of effort before starting Hana into benchmarking implementation techniques, and it shows. Hana being used for TMP isn't performance competitive, though it's way better than MPL or any of the previous gen libraries. Metal isn't the fastest of the new generation libraries from what I've been told, but it's competitive to them. That's my best understanding of the situation anyway, corrections are welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/