Subject: Re: [boost] MPL and MPL core
From: Manu343726 (manu343726_at_[hidden])
Date: 2015-04-02 05:33:18
Bruno Dutra wrote
> 2015-04-01 10:13 GMT-03:00, Louis Dionne <
>> Why would you want an MPL replacement when you could have much
> Well, why would you want much better if you can have much simpler? :)
>> If you're going to go for C++11/14 anyway, why in heaven would you want
>> stick to the MPL?
> There seems to be a misconception that MPL is utterly outdated and old
> fashioned, but I beg to differ. I find myself increasingly fond of its
> design and I particularly like how well it mimics STL. In my opinion,
> that is precisely one of its greatest strengths.
I don't think that MPL can be seen as "simple". Neither considering its
idioms, related mostly to old C++ features. typename ::type, iterator based
interface, etc; which make the code far more obfuscated than Meta or Hana.
The point of getting the effort to write a new metaprogramming library for
Boost is to study how C++11/14, i.e. new features and idioms, can aid when
metaprogramming. Getting stuck on old idioms is not a good idea. Want
backwards compatibility? Then just install Boost <= 1.57.0. Is that easy.
Anyway, I'm agree with Louis that most metaprogramming libraries that have
come after C++11 look at tmp in a very different way. The STL-like interface
is not a plus point for MPL at all. The STL is not designed for functional
programming, and like it or not, TMP is functional. Also comes with exactly
the same composability problem the STL has with its iterator based
interface. Of course there are workarounds like metafunction classes, but
they are just that, workarounds. Iterators make sense with head:tail
typelists, but have no place on modern metaprogramming and variadic
So, what we are trying to achieve here? Reading the full thread, it's clear
that three main bullets raise out:
- Backwards compatible (Again, just install previous MPL versions)
For simple metaprogramming, I think Eric's Meta does the job. Eager, simple,
ready for common metaprogramming problems.
Modern/reinvent the paradigm? Hana looks nice, throwing away almost all the
syntax idiosyncrasies of TMP. I'm trying the same with Turbo, but my goal is
to write Haskell-like code (Still on it, Turbo does not currently do that
entirely). I think we should accept that TMP is functional, and get the best
of the fp world.
My long-term goal is to port almost all the Haskell prelude to tmp, in the
same sense of FTL but at compile-time.
Summing up: MPL style is not the best for modern TMP. If you still keep
thinking on a new MPL on the same way of the old one, then the separation
between a metafunctions library and a typelists library is the right thing
-- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4674036.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk