Quantcast

[metal] Feature Complete - Request for Feedback

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
Dear community,

As some of you might be aware through sporadic discussions on this mailing
list throughout the last couple of years, I've been working for quite a
while on a modern template metaprogramming library called Metal, that I
advocate as a direct replacement for the aging Boost.MPL.

I believe my work is finally complete now and so I come to you to request
for feedback and ask whether you think that Metal would be a valuable
addition to the Boost distribution. My intention is to request a formal
review in the next days / weeks, depending on your preliminary feedback.

In a glimpse, Metal is a pure template metaprogramming that explores all
modern features available to C++14 to overcome the limitations of
Boost.MPL, most notably:

* vastly improved performance [1];
* terser syntax [2].

Repository: https://github.com/brunocodutra/metal
Documentation: http://brunocodutra.github.io/metal/
Boost Incubator:
http://blincubator.com/bi_library/metal-2/?gform_post_id=1566

I appreciate your feedback and opinion on whether Metal is a good fit for
Boost!

- Previous discussions

About a year ago I came to this list to discuss a proposal of merging Metal
into MPL as a new API built from ground up, while at the same time serving
as a backend for the previous API on modern compilers.

At that time, Metal was lazy and very similar to MPL, but since then it
underwent great simplification and embraced the all-eager design, so I
don't think this would be a good idea anymore. Besides, it soon became
clear that this would be a huge undertaking with potential to inadvertently
breaking a lot of good code to little gain,
so I decided instead to tackle the problem migration from MPL by providing
a handy adaptor [3].

[1]: http://metaben.ch/
[2]: http://brunocodutra.github.io/metal/index.html#in_a_glimpse
[3]:
http://brunocodutra.github.io/metal/group__external.html#gaede6847ad3e0bb64c0c921112b29930e

Regards,
Bruno Dutra

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
 From a first look at it, this looks quite awesome. 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.

If there is a place besides the other libraries, I think it would fit in
quite nicely.

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.

Am 20.02.2017 um 21:49 schrieb Bruno Dutra via Boost:

> Dear community,
>
> As some of you might be aware through sporadic discussions on this mailing
> list throughout the last couple of years, I've been working for quite a
> while on a modern template metaprogramming library called Metal, that I
> advocate as a direct replacement for the aging Boost.MPL.
>
> I believe my work is finally complete now and so I come to you to request
> for feedback and ask whether you think that Metal would be a valuable
> addition to the Boost distribution. My intention is to request a formal
> review in the next days / weeks, depending on your preliminary feedback.
>
> In a glimpse, Metal is a pure template metaprogramming that explores all
> modern features available to C++14 to overcome the limitations of
> Boost.MPL, most notably:
>
> * vastly improved performance [1];
> * terser syntax [2].
>
> Repository: https://github.com/brunocodutra/metal
> Documentation: http://brunocodutra.github.io/metal/
> Boost Incubator:
> http://blincubator.com/bi_library/metal-2/?gform_post_id=1566
>
> I appreciate your feedback and opinion on whether Metal is a good fit for
> Boost!


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
On Mon, Feb 20, 2017 at 10:06 PM, Klemens Morgenstern via Boost <
[hidden email]> 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.


> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
Dear Bruno,

>> 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.

I am on the skeptical side. I just learned boost::mpl and boost::fusion to implement compile-time computations for my proposed boost.histogram library, so I am by no means an expert on meta-programming. Nevertheless, I was positively surprised how fast I made progress with these libraries once I overcame my general attitude of "TMP is weiiiiird". The structural similarity of boost::mpl with the STL eased the learning curve a lot.

At first glance (I am looking at the code in the section "In a Glimpse" of your documentation), I don't see much syntactic difference to boost::mpl, could you elaborate on the differences? It seems you mostly you drop the trailing ::type, because you use alias templates. I like your metal::lambda, I am not sure if boost::mpl has that. If not, one could probably add it to boost::mpl.

I suppose my big question is this: can't you just merge your ideas/improvements into boost::mpl? With ifdefs you could enable C++14 features like templated aliases when they are available. Even more so, it should be possible to merge your speed improvements into boost::mpl.

I also looked at your benchmarks and they are a bit confusing. I am mostly interested in how your lib compares to the mpl, but not all benchmarks have mpl data, and those that have (see at or count_if) only use up to 50 elements. Is that a hard limitation of the current mpl implementation?

I am looking forward to the comments from the authors of boost::hana and boost::mpl.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
On 21.02.2017 12:53, Hans Dembinski via Boost wrote:
>
> I suppose my big question is this: can't you just merge your
> ideas/improvements into boost::mpl? With ifdefs you could enable
> C++14 features like templated aliases when they are available. Even
> more so, it should be possible to merge your speed improvements into
> boost::mpl.

The biggest and most useful feature of "new" TMP libraries is variadic
templates that increase performance by a really huge factor. The problem
with MPL is that vector type sequence must derive from vectorN-s, which
are documented and can be used in template specialization. So it is
impossible or pointless to remplement mpl::vector in terms of variadic
parameters because of that. The other problem that I can quickly recall
is recursive iterator-based approach, which also kills performance.

Personally, I found it better from both performance and code sanity
sides to extract types from mpl::vector to variadic sequence via partial
template specialization (with mpl::vectorN<Ts...> using boost PP) and
then pass variadic type sequence to whatever TMP library I'm using
(brigand to be specific, but I think its unrelated in this case).

>
> Best regards, Hans
>
> _______________________________________________ Unsubscribe & other
> changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
--------
Mitsyn Sergey

---
Это сообщение проверено на вирусы антивирусом Avast.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski <[hidden email]>
wrote:
>
> I am on the skeptical side. I just learned boost::mpl and boost::fusion
to implement compile-time computations for my proposed boost.histogram
library, so I am by no means an expert on meta-programming. Nevertheless, I
was positively surprised how fast I made progress with these libraries once
I overcame my general attitude of "TMP is weiiiiird".  The structural
similarity of boost::mpl with the STL eased the learning curve a lot.

Great! So you'll be mind-blown by what Metal can do with the help of modern
C++ features!

> At first glance (I am looking at the code in the section "In a Glimpse"
of your documentation), I don't see much syntactic difference to
boost::mpl, could you elaborate on the differences? It seems you mostly you
drop the trailing ::type, because you use alias templates.

Metal is purposefully designed to resemble MPL stripped of all the
`typename`s and `::type`s, but their similarities end there.
MPL was written some 15 years ago, at a time that compilers that actually
handled templates correctly were scarce. If you peek at MPL's source code
you will promptly realize that half of it is really working around broken
compilers, the other half being emulating missing language features that
were introduced only much later in C++11. That is actually the greatest
feat of MPL, heck it was written even before C++03 was standardized!
Fortunately we can kiss all that heroic hackery goodbye, now that we have
access to variadic templates and template alias, along with the fact that
compilers of this decade are not all that bad anymore. This gives Metal a
lot of flexibility to address other issues that MPL couldn't tackle back
then, such as scalability and ease of use.

> I like your metal::lambda, I am not sure if boost::mpl has that. If not,
one could probably add it to boost::mpl.

MPL has something functionally similar called quote, except that mpl::quote
doesn't actually exist, because it couldn't possibly be implemented without
variadic templates. What do exist are its numbered relatives, mpl::quote1,
mpl::quote2, ..., up to mpl::quote15, each able to handle only
metafunctions that take exactly that many arguments, with no support for
variadic metafunctions whatsoever. This a great example of MPL's greatest
shortcoming: there was no other option back then, but to enumerate every
possible specialization of templates, which entails a _lot_ of code
repetition and the most gruesome preprocessor hackery you'll ever see.

> I suppose my big question is this: can't you just merge your
ideas/improvements into boost::mpl? With ifdefs you could enable C++14
features like templated aliases when they are available. Even more so, it
should be possible to merge your speed improvements into boost::mpl.

It does sound like a good idea from the user's point of view since Metal
looks so similar to MPL, but because they are so drastically distinct
internally, merging them into a single library doesn't really make any
sense. Fortunately, if you are coming from some legacy metaprogram, it is
easy to incrementally migrate to Metal using the helper metal::from_mpl,
but there is really no reason to ever use MPL anymore on a new project.

> I also looked at your benchmarks and they are a bit confusing. I am
mostly interested in how your lib compares to the mpl, but not all
benchmarks have mpl data, and those that have (see at or count_if) only use
up to 50 elements. Is that a hard limitation of the current mpl
implementation?

Unfortunately that is indeed a hard limit of of Boost.MPL. Just like
mpl::quote, everything else in MPL had to be implemented by enumerating
every possible combination of arguments, which implies that some hard limit
must have been chosen. That limit is 50 to sequence sizes and 15 to
mpl::quote, mpl::apply and their friends.
Metal doesn't have any theoretical limit and the number of arguments can
easily reach the thousands in practice.

Now I know that these arguments may sound a bit too abstract to someone not
very experienced with template metaprogramming, but the advantages of
modern C++ quickly become apparent when you try it out, so I invite you to
give Metal a spin, so you can convince yourself.

> I am looking forward to the comments from the authors of boost::hana and
boost::mpl.

While the author of Hana is very active in the Boost community, it is
unfortunately very unlikely that you'll hear from MPL authors in this
mailing list nowadays.

Regards,
Bruno

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Personally, I found it better from both performance and code sanity sides
to extract types from mpl::vector to variadic sequence via partial template
specialization (with mpl::vectorN<Ts...> using boost PP) and then pass
variadic type sequence to whatever TMP library I'm using

You should be aware that this doesn't work in general, because MPL types
are unspecified and pattern matching them actually means relying on
implementation details. That is specially true for mpl::vector, which
returns a proxy type that in turn masks the contents of the original
vector whenever
mpl::insert or mpl::erase is used, in a way that cannot be pattern matched
like this. There is no portable way of transferring the contents of a MPL
sequence to a variadic type, except for using MPL's own algorithms. If you
check out the implementation of metal::from_mpl, you'll find that it relies
on mpl::fold to extract the contents of sequences into a metal::list.

This is by the way another advantage of Metal, since all of its types are
precisely defined and friendly to pattern matching.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 21.02.2017 um 14:03 schrieb Bruno Dutra via Boost:

> On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski <[hidden email]>
> wrote:
>>
> [...]
>
>> I suppose my big question is this: can't you just merge your
>> ideas/improvements into boost::mpl? With ifdefs you could enable C++14
>> features like templated aliases when they are available. Even more so, it
>> should be possible to merge your speed improvements into boost::mpl.
>
> It does sound like a good idea from the user's point of view since Metal
> looks so similar to MPL, but because they are so drastically distinct
> internally, merging them into a single library doesn't really make any
> sense. Fortunately, if you are coming from some legacy metaprogram, it is
> easy to incrementally migrate to Metal using the helper metal::from_mpl,
> but there is really no reason to ever use MPL anymore on a new project.

Could you elaborate a little more on this metal::from_mpl?
How is it used?
Can I just replace all occurrences of "boost::mpl" in any code by
"metal::from_mpl" and it works?

>
>> I also looked at your benchmarks and they are a bit confusing. I am
>> mostly interested in how your lib compares to the mpl, but not all
>> benchmarks have mpl data, and those that have (see at or count_if) only use
>> up to 50 elements. Is that a hard limitation of the current mpl
>> implementation?
>
> Unfortunately that is indeed a hard limit of of Boost.MPL. Just like
> mpl::quote, everything else in MPL had to be implemented by enumerating
> every possible combination of arguments, which implies that some hard limit
> must have been chosen. That limit is 50 to sequence sizes and 15 to
> mpl::quote, mpl::apply and their friends.

Just a short note:

You can increase this upper limit by changing the values of some
Boost.MPL macros and pre-generating headers for Boost.MPL-containers
with these new values. For this, some python-scripts exist in
"libs/mpl/preprocessed".
However, they stopped working after the migration to Git from
Subversion. And they were pretty complicated to use (and understand).

Therefore, a few years ago, I created some helper python-script
"boost_mpl_preprocess.py" which fixes pre-generating the headers and
greatly simplifies the process. It is also located in the same directory
in Boost-source since Boost 1.59.
Just call it like this to see the options and its usage:
   python boost_mpl_preprocess.py --help


At our company we had to increase the number of elements to 100 and it
works fine except for the obvious reasons Bruno already talked about. It
is so damn slow and wastes so much RAM that we can only compile
single-threaded which slows down compile-performance even more.

That is why I am so interested in a drop-in replacement for Boost.MPL
and asked about metal::from_mpl above.

> [...]
>
> Regards,
> Bruno

Thanks,
Deniz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Feb 20, 2017 at 3:49 PM, Bruno Dutra via Boost
<[hidden email]> wrote:

> Dear community,
>
> As some of you might be aware through sporadic discussions on this mailing
> list throughout the last couple of years, I've been working for quite a
> while on a modern template metaprogramming library called Metal, that I
> advocate as a direct replacement for the aging Boost.MPL.
>
> Regards,
> Bruno Dutra
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Will Metal be old as soon as Concepts appear? (ie probably C++20)
Or are they complimentary?

Tony

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 21.02.2017 um 14:11 schrieb Bruno Dutra via Boost:

>> Personally, I found it better from both performance and code sanity sides
> to extract types from mpl::vector to variadic sequence via partial template
> specialization (with mpl::vectorN<Ts...> using boost PP) and then pass
> variadic type sequence to whatever TMP library I'm using
>
> You should be aware that this doesn't work in general, because MPL types
> are unspecified and pattern matching them actually means relying on
> implementation details. That is specially true for mpl::vector, which
> returns a proxy type that in turn masks the contents of the original
> vector whenever
> mpl::insert or mpl::erase is used, in a way that cannot be pattern matched
> like this. There is no portable way of transferring the contents of a MPL
> sequence to a variadic type, except for using MPL's own algorithms. If you
> check out the implementation of metal::from_mpl, you'll find that it relies
> on mpl::fold to extract the contents of sequences into a metal::list.
>
> This is by the way another advantage of Metal, since all of its types are
> precisely defined and friendly to pattern matching.
I think that's your main selling point. Afaik Hana also relys on
concepts more than on actual types; i.e. the result types are not
completely specified. If that is the case and you provide those, you've
got the place for your library.


Another dumb idea to make your life hell: do you think you could have
some interface to hana? I.e. you get a sequence from hana and have a
`decltype(metal::from_hana(seq))` to get a defined metal type? Or you
have a `metal::to_hana` function.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
Klemens Morgenstern wrote:
> Am 21.02.2017 um 14:11 schrieb Bruno Dutra via Boost:
>
> > This is by the way another advantage of Metal, since all of its types
> > are precisely defined and friendly to pattern matching.
>
> I think that's your main selling point. Afaik Hana also relys on concepts
> more than on actual types; i.e. the result types are not completely
> specified.

This is a false dilemma; it's possible to take 'concepts' and return
completely specified types.

There are other legitimate reasons to prefer strictness in the arguments
though - SFINAE friendliness is one. And there are reasons to prefer
concept-ness. Such as for instance

    mp_transform<std::add_const_t, std::shared_ptr<X>> // std::shared_ptr<X
const>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Feb 21, 2017 at 2:38 PM, Deniz Bahadir via Boost <
[hidden email]> wrote:

> Am 21.02.2017 um 14:03 schrieb Bruno Dutra via Boost:
>
>> On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski <
>> [hidden email]>
>> wrote:
>>
>>>
>>> [...]
>>
>> I suppose my big question is this: can't you just merge your
>>> ideas/improvements into boost::mpl? With ifdefs you could enable C++14
>>> features like templated aliases when they are available. Even more so, it
>>> should be possible to merge your speed improvements into boost::mpl.
>>>
>>
>> It does sound like a good idea from the user's point of view since Metal
>> looks so similar to MPL, but because they are so drastically distinct
>> internally, merging them into a single library doesn't really make any
>> sense. Fortunately, if you are coming from some legacy metaprogram, it is
>> easy to incrementally migrate to Metal using the helper metal::from_mpl,
>> but there is really no reason to ever use MPL anymore on a new project.
>>
>
> Could you elaborate a little more on this metal::from_mpl?
> How is it used?
> Can I just replace all occurrences of "boost::mpl" in any code by
> "metal::from_mpl" and it works?


The idea is to be able to connect some preexisting MPL code to Metal, so
that new features may be implemented using Metal already, before eventually
porting everything in a gradual fashion and only if necessary. Thus
metal::from_mpl converts MPL Sequences, Integral Constants and Metafunction
Classes to their equivalents in Metal. It is recursive, so if you have an
mpl::list of mpl::int_, it will produce a metal::list of metal::number.
Check out the examples here: http://brunocodutra.github.io/metal/group__
external.html (click the panel to expand).


> At our company we had to increase the number of elements to 100 and it
> works fine except for the obvious reasons Bruno already talked about. It is
> so damn slow and wastes so much RAM that we can only compile
> single-threaded which slows down compile-performance even more.


> That is why I am so interested in a drop-in replacement for Boost.MPL and
> asked about metal::from_mpl above.
>

While Metal is not able to replace MPL like this, it can complement it with
the help of metal::from_mpl, which makes it possible to rewrite critical
sections that take the longest to compile for example. Give it a try, gains
with respect to performance and memory consumption are huge!

Regards,
Bruno

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>
> Will Metal be old as soon as Concepts appear? (ie probably C++20)
> Or are they complimentary?
>
>
Not at all, concepts are a replacement for std::enable_if and explicit
SFINAE, but one still has to write the predicates themselves, which are not
always as trivial as instantiating a type_trait. Specially when dealing
with std::tuple and std::variant one may find oneself dealing with dozens
to maybe hundreds of types, which in turn might have to be constraint in
curious ways in order to express particular concepts. Metal will be there
to make it easy.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Bruno Dutra

On Tue, Feb 21, 2017 at 3:45 PM, Klemens Morgenstern via Boost <
[hidden email]> wrote:
>
> This is by the way another advantage of Metal, since all of its types are
>> precisely defined and friendly to pattern matching.
>>
> I think that's your main selling point. Afaik Hana also relys on concepts
> more than on actual types; i.e. the result types are not completely
> specified. If that is the case and you provide those, you've got the place
> for your library.
>

Absolutely! Every concept in Metal is defined solely by its type, no
assumptions whatsoever are made about the presence of nested types or
values [1]. As far as Metal is concerned, types need only be declared and
may even be left undefined.

[1]: http://brunocodutra.github.io/metal/#concepts

Another dumb idea to make your life hell: do you think you could have some
> interface to hana? I.e. you get a sequence from hana and have a
> `decltype(metal::from_hana(seq))` to get a defined metal type? Or you
> have a `metal::to_hana` function.


My intention is to expand the `external` module to provide adaptors to
other libraries, Hana included, just like it provides for MPL now.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 21.02.2017 um 18:07 schrieb Bruno Dutra via Boost:

> On Tue, Feb 21, 2017 at 2:38 PM, Deniz Bahadir via Boost <
> [hidden email]> wrote:
>
>> Am 21.02.2017 um 14:03 schrieb Bruno Dutra via Boost:
>>
>>> On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski <
>>> [hidden email]>
>>> wrote:
>>>
>>>>
>>>> [...]
>>>
>>> I suppose my big question is this: can't you just merge your
>>>> ideas/improvements into boost::mpl? With ifdefs you could enable C++14
>>>> features like templated aliases when they are available. Even more so, it
>>>> should be possible to merge your speed improvements into boost::mpl.
>>>>
>>>
>>> It does sound like a good idea from the user's point of view since Metal
>>> looks so similar to MPL, but because they are so drastically distinct
>>> internally, merging them into a single library doesn't really make any
>>> sense. Fortunately, if you are coming from some legacy metaprogram, it is
>>> easy to incrementally migrate to Metal using the helper metal::from_mpl,
>>> but there is really no reason to ever use MPL anymore on a new project.
>>>
>>
>> Could you elaborate a little more on this metal::from_mpl?
>> How is it used?
>> Can I just replace all occurrences of "boost::mpl" in any code by
>> "metal::from_mpl" and it works?
>
>
> The idea is to be able to connect some preexisting MPL code to Metal, so
> that new features may be implemented using Metal already, before eventually
> porting everything in a gradual fashion and only if necessary. Thus
> metal::from_mpl converts MPL Sequences, Integral Constants and Metafunction
> Classes to their equivalents in Metal. It is recursive, so if you have an
> mpl::list of mpl::int_, it will produce a metal::list of metal::number.
> Check out the examples here: http://brunocodutra.github.io/metal/group__
> external.html (click the panel to expand).
>

Ahh, clicking the panel makes sense. :-)
I did not try this before and thought that doc-generation just failed
there (or that none was available).
Maybe, you should change the default view to be expanded (if possible).


>
>> At our company we had to increase the number of elements to 100 and it
>> works fine except for the obvious reasons Bruno already talked about. It is
>> so damn slow and wastes so much RAM that we can only compile
>> single-threaded which slows down compile-performance even more.
>
>
>> That is why I am so interested in a drop-in replacement for Boost.MPL and
>> asked about metal::from_mpl above.
>>
>
> While Metal is not able to replace MPL like this, it can complement it with
> the help of metal::from_mpl, which makes it possible to rewrite critical
> sections that take the longest to compile for example. Give it a try, gains
> with respect to performance and memory consumption are huge!

Our problem is, that we never really used Boost.MPL directly. We just
got it for "free" as a (costly) dependency through other Boost libraries
(e.g. Boost.MSM). So, I am not really looking forward to changing
anything there.
Using "find/replace", however, to just change the namespaces would have
been a great (= easy) solution.

But if find time I will see if Metal can help here.


>
> Regards,
> Bruno
>

Thanks,
Deniz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Feb 21, 2017 at 4:32 PM, Peter Dimov via Boost <
[hidden email]> wrote:

> Klemens Morgenstern wrote:
>
>> Am 21.02.2017 um 14:11 schrieb Bruno Dutra via Boost:
>>
>> > This is by the way another advantage of Metal, since all of its types >
>> are precisely defined and friendly to pattern matching.
>>
>> I think that's your main selling point. Afaik Hana also relys on concepts
>> more than on actual types; i.e. the result types are not completely
>> specified.
>>
>
> This is a false dilemma; it's possible to take 'concepts' and return
> completely specified types.
>
> There are other legitimate reasons to prefer strictness in the arguments
> though - SFINAE friendliness is one. And there are reasons to prefer
> concept-ness. Such as for instance
>
>    mp_transform<std::add_const_t, std::shared_ptr<X>> //
> std::shared_ptr<X const>
>

I'm glad you mentioned it, indeed there is no need for compromises there,
we can have both, but I forgot to discuss how Metal addresses this.

As a tool that makes it possible to drive overload resolution through
SFINAE, it was a very important design goal for Metal from the very
beginning that _everything_ it provides must be SFINAE friendly no matter
what. In the beginning the concepts Metal was based on were more flexible
and made it possible for example that any template specialization be used
as a List. That alone however opens a whole trunk of worms, because one has
to deal with stuff like this:

join<std::tuple<>, std::map<X, Y>, std::unique_ptr<Z>>

Should this be valid and if so what should be the result? One might think
that std::tuple<X, Y, Z> would be the obvious answer, but how about default
template parameters that both std::metal and std::unique_ptr have for their
trailing parameters? Should it then be std::tuple<X, Y, std::less<X>,
std::allocator<std::pair<X const, Y>>, Z, std::default_delete<Z>>? But why
should the result List "type" be std::tuple? Shouldn't it instead by
disallowed since the List "types" are not all the same?

Conundrums like these made it very tricky to implement even the simplest of
the algorithms and had a inevitable impact on performance. So I decided to
simplify the concepts to the minimum necessary to express their underlying
semantics, while providing helpers like metal::as_list and metal::as_number
that translate from List-like and Number-like things into strict Metal
Lists and Numbers. This proved to be the best design, because the
implementation simplified dramatically, performance improved and
metal::as_* helpers could be given maximum flexibility to convert the
widest variety of *-like things into their equivalents.

Your example is implemented in Metal like this

using _ = metal::transform<metal::lambda<std::add_const_t>,
metal::as_list<std::shared_ptr<X>>>; // metal::list<X const>
metal::apply<metal::lambda<std::shared_ptr>, _> // std::shared_ptr<X const>

Admittedly a bit verbosier, but not too bad.
.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Feb 21, 2017 at 7:21 PM, Deniz Bahadir via Boost <
[hidden email]> wrote:

> Ahh, clicking the panel makes sense. :-)
> I did not try this before and thought that doc-generation just failed
> there (or that none was available).
> Maybe, you should change the default view to be expanded (if possible).


Thanks for your feedback, it is now obvious that collapsible panels are not
intuitive and need to be improved.
I started a discussion about this here:
https://github.com/brunocodutra/metal/issues/56


> Our problem is, that we never really used Boost.MPL directly. We just got
> it for "free" as a (costly) dependency through other Boost libraries (e.g.
> Boost.MSM). So, I am not really looking forward to changing anything there.
> Using "find/replace", however, to just change the namespaces would have
> been a great (= easy) solution.
>

I believe this is a fairly common issue, because MPL has been around for so
many years and so many core libraries depend on it. This has always been a
personal concern of mine, in fact I even opened a side project within Metal
that aims to address the problem by providing a minimal implementation of
MPL that could be used as a drop in replacement for use cases like yours.
See https://github.com/brunocodutra/metal/projects

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2/21/17 10:21 AM, Deniz Bahadir via Boost wrote:
> Am 21.02.2017 um 18:07 schrieb Bruno Dutra via Boost:

> Our problem is, that we never really used Boost.MPL directly. We just
> got it for "free" as a (costly) dependency through other Boost libraries
> (e.g. Boost.MSM).

What's "costly" about it?  What are you refering to?

Robert Ramey

> Thanks,
> Deniz
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Bruno Dutra wrote:
> That alone however opens a whole trunk of worms, because one has to deal
> with stuff like this:
>
> join<std::tuple<>, std::map<X, Y>, std::unique_ptr<Z>>
>
> Should this be valid and if so what should be the result?

Let me check...

> Should it then be std::tuple<X, Y, std::less<X>,
> std::allocator<std::pair<X const, Y>>, Z, std::default_delete<Z>>?

Yes. :-)

> But why should the result List "type" be std::tuple?

The type of the first list is used by convention.

> Conundrums like these made it very tricky to implement even the simplest
> of the algorithms and had a inevitable impact on performance.

Well... it does make things a bit more convoluted here or there, but it's
not that big of a burden.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [metal] Feature Complete - Request for Feedback

Boost - Dev mailing list
On Tue, Feb 21, 2017 at 11:32 PM, Peter Dimov via Boost <
[hidden email]> wrote:

> Bruno Dutra wrote:
>
>> That alone however opens a whole trunk of worms, because one has to deal
>> with stuff like this:
>>
>> join<std::tuple<>, std::map<X, Y>, std::unique_ptr<Z>>
>>
>> Should this be valid and if so what should be the result?
>>
>
> Let me check...
>
> Should it then be std::tuple<X, Y, std::less<X>,
>> std::allocator<std::pair<X const, Y>>, Z, std::default_delete<Z>>?
>>
>
> Yes. :-)
>
> But why should the result List "type" be std::tuple?
>>
>
> The type of the first list is used by convention.
>
> Conundrums like these made it very tricky to implement even the simplest
>> of the algorithms and had a inevitable impact on performance.
>>
>
> Well... it does make things a bit more convoluted here or there, but it's
> not that big of a burden.
>

Good, so let us raise the bar a further notch ;)

What about insert<std::map<X, Y>, number<2>, F>, should it yield
std::map<X, Y, F>? Should it SFINAE away because std::map can't fit 5
elements?

And how about erase<std::map<X, Y, F>, number<2>>, should it yield
std::map<X, Y>? Should it SFINAE away because std::map can't fit less than
4 elements?

Metal suffers of none of these issues, at the extra instantiation of
metal::as_list, which BTW also serves as a clear indication of intent that
helps other programmers understand the code and debug if necessary.

Regards,
Bruno

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12
Loading...