From: joel de guzman (djowel_at_[hidden])
Date: 2002-04-10 18:12:09
----- Original Message -----
From: "Douglas Gregor" :
> On Wednesday 10 April 2002 01:21 pm, you wrote:
> > As much as I am impressed with MPL's intellectual investment, I am
> > completely underwhelmed by its approach by large, and in principle. (I
> > am sorry, there's nothing personal to MPL's authors. That's how I
> > feel.) I would look the same at a package that adds iterations, loops,
> > etc. in Haskell. I am much more comfortable with iteration than with
> > recursion, but again, in Rome do what the Romans do: Haskell does not
> > like loops, and neither does C++'s template engine.
> I think the real question is "Who are the Romans?".
> If the Romans are Haskell or Ocaml programmers, they may very well be
> appalled at MPL's use of iterators because iteration is abominable in
> functional languages.
> If the Romans are STL-savvy C++ programmers, they may very well be enthralled
> with MPL's use of iterators and iteration because it coincides with their
> knowledge of STL.
The C++ template metaprocessor is purely functional (no side-effects).
The underlying paradigm here is functional programming rather than
imperative programming. It's kinda inelegant, at least for me, to apply
an imperative flavor to something that is really declarative. However,
!elegant != !useful. I think MPL is a really cool piece of engineering
and the things it can do is really quite impressive. I've read the draft
documentation. Although I'm still not convinced with the STLish interface,
I am convinced that this is indeed a very solid foundation. The way I
see it, it also seems plausible to write a Lisp or Haskell like interface
PS> Dave, I would love to see a synopsis of all the available facilities
as well as an overview of the overall structure of the library to visualize
how much we will pay in order to use a certain facility.
A technical reference would be really helpful in understanding MPL more.
In particular, I'd like to know more about MPL's engine detached from the
STLish interface. I think this is what interests me most. If this engine is
exposed as a standalone unit along with a reasonable interface (and of
course with documentation how to use it), this *is* the core library
that I was alluding to in my previous post. I bet it can be reused to power
other metaprogramming libraries such as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk