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

From: David A. Greene (greened_at_[hidden])
Date: 2002-04-12 22:42:41

Aleksey Gurtovoy wrote:
> David A. Greene wrote:
> 
>>I agree with this.  The MPL count_if example is really confusing.  I
>>have yet to see a convincing example of why such convolutions are
>>necessary.  Some have alluded to complex metaprogramming problems
>>more easily solved with MPL/"iteration" that recursion/pattern
>>matching but I haven't seen them.
> 
> When it seems that you don't have enough experience with the domain to
> appreciate what the library is has to offer. 

This is getting dangerously close to flameage.  No, I'm not a
metaprogramming expert.  I've done some mildly complicated stuff.
I think I represent a good chunk of MPL's user base.

> happy this way. Your reply implies that we are trying to sell you something
> that does not hold its promises. Well, we are not. The last thing I am
> interested in is to spend my time trying to convince somebody who has
> already made his mind.

I _haven't_ made up my mind.  But I have to admit that Andrei makes some
good arguments, and frankly, I haven't seen any concrete evidence to
refute them.  Several people have asked for examples of the complex
problems that MPL solves elegantly.

MPL developers seem to be really defensive lately and I don't suppose
I can blame them.  But ordinary Joes like Joel and me (well, Joel is
extraordinary because he hacks Spirit :)) _really_want_to_be_convinced_.
Believe me, I am trying to give you every opportunity to hype MPL.  I
really want to believe.  :)

>>There have been several calls for implementations of Loki facilities
>>in MPL and to my knowledge, not one has been posted.
> 
> It has been said (and shown) a long time ago that typelist part of Loki is a
> subset of MPL. In particular, that means that re-write of every other Loki
> facility that depends on typelists is trivial. If you are interested in
> porting Loki to MPL - go ahead. I am not, because we don't use Loki
> anywhere.

I'm not talking about a port of Loki.  I'm asking how to achieve
the same effects with MPL.  If that is best accomplished by taking
the subset of MPL typelists that Loki presents and re-writing all
of Loki to use that type, then that's my answer (no need to actually
code it :)).  I think people were trying to understand the added
value of MPL.  That is, does MPL provide facilities that make
coding a library like Loki easier?

Maybe Loki is a bad example.  Perhaps a better task is to implement
generic versions of various design patterns.

>>MPL may be nice, I don't know.  It's tough for me to begin using
>>it without documentation.
> 
> It has the documentation, the docs base is growing, and personally I am
> always glad to answer whatever usage question one might have. If it's not
> enough of the service for you, sorry.

I'm confused.  I've read several messages on the list that indicate
this-or-that part of the documentation is out-of-date, etc.  Maybe
I got the wrong impression -- I'm very sorry if that's the case.
What's that MPL2 develpment branch tag again?  :)

>>Such information has been promised for quite some time now and it 
>>seems it's still not up-to-date.
> 
> I should be missing something. Are you paying us to write the docs?

Of course not.  I appreciate that this is a volunteer effort.

>>be extremely useful.  Can MPL support algorithms written using
>>recursion?  If it can handle recursion as well as iteration, I'd
>>be happier.
> 
> You've asked this question before, and it has been already answered.
> 
> "You can always write your own recursive algorithms with MPL type lists. The
> termination are detected slightly differently to allow for different
> sequences, but that's about it."

You're right.  My apologies.  I've been away from MPL for a while
and my brain moved that discussion out of the cache.  :)

I'll excuse myself from the discussion now.

                             -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson