Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-02-25 12:43:59

2015-02-25 13:42 GMT-03:00, Ganesh Prasad <sir.gnsp_at_[hidden]>:
> Porting metalog to hana as an add on might be a good idea, but I quite
> disagree from the user's point of view. Hana is a beautifully designed
> library and it does precisely what it's designed for. In short it has good
> modularity. And , indeed, libraries are supposed to be highly modular.
>
> So, it might be better to keep metalog as a separate entity and provide
> good  interoperability between Hana and metalog.

Exactly. I don't have any experience with Hana yet and, hence,
couldn't know whether logic programming would suite it well, so my
initial intention is just to provide a use case for it and learn some
C++14 in the process. As I said, right now, I'm convinced metalog
could be a nice concept for an enhancement of MPL instead.

2015-02-25 14:02 GMT-03:00, pfultz2 <pfultz2_at_[hidden]>:
>> IMO the fact it mimics the standard library is very positive, for it
>> makes
>> transition much easier for someone used to the STL first experimenting
>> with
>> metaprogramming.
>
> Actually, that is what has helped me when I started using MPL. However,
> iterator-based approach for metaprogramming has a huge impact on
> performance.
> There is no such thing as random access in TMP.
>
> Since MPL is a core component of many libraries, it is important to have a
> library that is fast. A redesigned MPL doesn't need to be completely
> functional as its foreign too many C++ programmer. However, it should be
> lightweight and familiar. And being familiar doesn't necessarily require an
> iterator-based approach.

By "complete backwards compatibility" I don't mean a redesigned MPL
should rely on iterators as a core functionality as it does today.
Rather, it could profit much more of an efficient design better suited
to its functional nature, on top of which iterators and such could be
emulated. The iterator based interface in this context could and
certainly would be much less efficient than its core interface, but
not necessarily less efficient than it is today, for it could be
written to benefit of C++11/14 variadics for example. I believe that
was the original motivation behind Louis' MPL11, which ended up
breaking compatibility for a good reason I'm sure. Perhaps it's just
not practically feasible, but I intent to look into it regardless.

-- 
*Bruno C. O. Dutra*