Re: [boost] Re: Re: Re: Re: Re: Re: Re: Adding Loki to Boost (reprise)

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.