From: joel de guzman (djowel_at_[hidden])
Date: 2002-04-15 00:23:07
----- Original Message -----
From: "Aleksey Gurtovoy" :
> I _do_ appreciate your comments. And it's not about Loki vs. MPL (at least
> not this sub-thread :). And I am not trying to disqualify anyone's posts
> basing on the criteria that their opinion is different than mine. I said
> what I think regarding an implicit statement of MPL not facilitating
> metaprogramming - basing on the technical merits.
Ok. I get it now. The next_if auxillary meta-function is needed only to
make non-conformant compilers happy (hey, no sarcasm here, please
not again :-). It is meta-lambda that has some problems with non conformant
compilers. After a long and winding road, I finally get it.
Here are my revised comments (so far):
1) fold (and map, filter?) are still the main *engine* I see behind the power
of MPL.
2) to be truly useful, fold (and map, filter?) [higher order functions] cry out for
a lambda facility.
3) without lambda (my opinion only) the count_if version *does not*
facilitate metaprogramming because I (user hat on) can write a count_if
version from scratch faster than it would take me to understand the whys
fully (i.e. why we need an aux next_if etc.)
4) I think effort must be put to make meta-lambda work in a non-PTS
environment.
5) Effort must be put to make meta-lambda work without using template
template facilities.
And last *and least* (Dave, this is no more than just a +personal wish+ )
6) More FP sounding names. fold is a good start. fold is not even
a part of STL. I wish for map, filter, foldl, foldr, etc. etc. You have good
arguments to go with the STL. IMO, what I don't quite find intuitive is
the mutation *implication* of erase, replace etc, etc. IMO, there are
pros and cons to both interfaces. I think too that it is too early now
to conclude which will be better for *us*, the users. So, why not have
both? After all, boost is supposedly a test bed. How can we test if
indeed the STLish interface is better if we don't have any other
option anyway?
<< remember, this is last *and least*. I can live without this. If I have
some time, a good start to get acquainted with MPL might be to
write an external library that implements a subset of Haskell's prelude.
I am quite enamored with this idea. I am even thinking about writing
a Spirit parser that inputs a Haskell subset code and outputs MPL
code. >>
Many thanks,
--Joel
PS> Aleksey, I may be assertive but I was not offended at all :-)
I still think that MPL is a beautifully engineered library regardless
of my criticisms. The template C++ metaprocessor as an FP facility
is a frontier that's largely unexplored. I am really glad that libraries
like MPL (and Loki) are exploring this further. I certainly hope that
in the end, we will reach an agreement that will lead us all to
unity.