Lambda the Ultimate

That message was from a while ago - the library was rejected, due partially to its overlap with Boost features already supporting functional programming.

Thank you Jim. Due diligence was performed. I checked Boost's announce list beforehand, but found no such announcement. Can you provide a relevant URL?

FC++ remains a fantastic library even if outside Boost. Personally I think Boost should drop its lambda library in favor of FC++.

Why, how generous of them:

Note that while the library is not accepted, the author has successfully established some of the merits of the functional programming paradigm and we should not require him to re-establish those same points in a future review. For that matter, I'm not convinced that we should have asked him to establish these points in the first place.

So some resistance to FC++ came from persons who required its author to explain the merits of functional programming. And these are C++ experts.

And these are C++ experts.

Well . . . Anyone can join the list and participate in a review.

Also, as I recall, there was just one person (out of maybe 15 who bothered to review the library, out of maybe 1000 on the boost-devel list) who doubted the benefits, and mostly of lazy lists. He also talked quite a bit about performance.

With your permission then, a review of the review may have value, because they intend to revisit the no-go decision at a later time.

Their remarks contradict yours rather plainly:

However I found it disturbing that during the review a number of traditional/ imperative-style C++ programmers were just not "getting it" about FP [functional programming].

So we have the same old problem of reaching the C++ crowd.

This was a very difficult decision, and I spent a long time sitting on the fence...in the end I received approximately 4 no votes and 7 yes votes...

Boost deserves credit for doing the review. The votes were almost two to one in favor. Both columns (yes/no) agreed that FC++ will get another shot at inclusion. That is the good news -- or bad news, if it affects FC++ in the wrong way.

There are two basic problems. The first is the value of multiparadigm programming (MP). The second is the view of a monolith with substantial overlap.

FC++ is a largely monolithic library with a fair [later called substantial] degree of overlap with other boost components. This led to a good deal of confusion/discussion during the review period. Such a state of affairs (monolith with substantial overlap) could conceivably be acceptable if there were clear problems for which FC++ was a uniquely suited practical solution....I don't believe that the *practical* value of FC++ as a *monolithic* embedded DSL in C++ supporting mixed paradigm programming has been satisfactorily established....If the authors were to break FC++ into smaller pieces and should they participate in a future lambda, phoenix, FC++ merger then the above concerns would be addressed.

MP has immense practical value. No one should argue that point. Sadly, we still do. I am wiping my tears away with tissue paper right now. If people aren't "getting it" about FP, then by definition, they have no basis to dismiss FP or MP. It is just unknown territory.

The more subtle matter is the monolithic charge. Now I haven't any details to refute it. Nor do I think refutation desirable. Maybe the charge sticks.

All I would propose is that hard evidence may need a different light of interpretation. The Boost folks puzzle over FP and MP, by their own admission. So a bias may distort their judgment about what is, and what isn't monolithic. The same data points that suggest, to C++ gurus, a "monolith," may suggest, to multiparadigm gurus, "flexibility."

Let me elaborate. Here we have FC++, there we have Boost. Boost admits to substantial overlap between them. So they are doing similar things. That fact speaks volumes. Has Boost been inching towards FP on an ad-hoc, piecewise basis? If not, then why is it doing so many similar things? The question then becomes, Which library is more coherent? FC++ provides a very capable functional DSL, designed from scratch with FP in mind, whereas Boost provides....components.

So a Devil's advocate could argue for scrapping Boost components and rewriting them more cleanly under C++ with FC++ as a DSL -- i.e., a MP language. That MP power could define exactly the right path to cool, new Boost libraries ad infinitum. Maybe FC++ seems difficult to break up because it makes too much sense to keep together. Maybe Boost, not FC++, has been doing things wrongly all along.

The question may have arisen during review: How might Boost components appear if built on top of C++/FC++? I suspect the answer is that they would be clean, polished, smaller, and easier to maintain. That statement I base on my own experience in MP.

The statement is merely a straw-man, meant for attack. It is not The Answer. I disclaim any detailed knowledge of library internals, and leave myself open to contrary evidence. Boost is open-minded about FP and MP, for which they earn my thanks.

I think calling FC++ a DSL is wrong. FP is FP. A language is only domain-specific where there is a domain limiting its uses. To call FP a domain is really stretching things. That's like calling C a DSL.

The other correction is that, in my Devil's hypothetical, some Boost components would simply disappear, since FC++ handles their capabilities. Others would be streamlined.

Their remarks contradict yours rather plainly:

However I found it disturbing that during the review a number of traditional/ imperative-style C++ programmers were just not "getting it" about FP [functional programming].

I don't see how that contradicts what I said.There was one notable who said that he understood lazy lists, and that they were useless, partly becuase of performance issues. That statement doesn't preclude people who didn't review the library, but did post seeking further explanations of FP.

All I would propose is that hard evidence may need a different light of interpretation. The Boost folks puzzle over FP and MP, by their own admission. So a bias may distort their judgment about what is, and what isn't monolithic. The same data points that suggest, to C++ gurus, a "monolith," may suggest, to multiparadigm gurus, "flexibility."

The Boost folk don't "puzzle over FP by their own admission"! At worst, some people didn't get it! A whole mess of other people did get it!

Second, the monolithic issue has nothing to do with FP or MP, it has to do with modularity, compile times, documentation, namespace issues, etc. There are a million reasons to split libraries into smaller pieces. Don't call out Boost bias without considering the evidence.

Has Boost been inching towards FP on an ad-hoc, piecewise basis? If not, then why is it doing so many similar things? The question then becomes, Which library is more coherent? FC++ provides a very capable functional DSL, designed from scratch with FP in mind, whereas Boost provides....components

Which libraries are more coherent is not the only question: performance, simplicity, and readability are all issues. In addition, it is not a good idea to break existing code by removing, say, the old Boost lambda library. Even Brian McNamara wasn't proposing that. Since we're going to have the old lambda library (which has very nice syntax, BTW), then the new lambda syntax should complement it.

In addition, even McNamara wasn't suggesting we "add FP to C++". Each component should stand on it's own. Why does C++ need monads? There's a 37k header file if you do, and one paragraph of documentation in the FC++ manual.

In any case, if you decide you need it, you can still download youreself; Boost isn't stopping you.

So a Devil's advocate could argue for scrapping Boost components and rewriting them more cleanly under C++ with FC++ as a DSL -- i.e., a MP language.

That's really up to the individual maintainers of the libraries. Boost also discourages coupling, for obvious reasons.

That MP power could define exactly the right path to cool, new Boost libraries ad infinitum.

Like? If someone comes up with one and needs FC++, that will be considered in the next review period.

Maybe FC++ seems difficult to break up because it makes too much sense to keep together. Maybe Boost, not FC++, has been doing things wrongly all along.

Maybe I shouldn't have to include a 60k header file to use "flip". Maybe you should consider the arguments agains monolithic libraries before dismissing them. Maybe you should actually read the mails from the review period.

The question may have arisen during review: How might Boost components appear if built on top of C++/FC++? I suspect the answer is that they would be clean, polished, smaller, and easier to maintain. That statement I base on my own experience in MP. The statement is merely a straw-man, meant for attack.

Straw man arguments are annoying. I'm not going to go spend my time digging up evidence to refute the arguments of someone who admits he has none. Read some of the background (The boost library recommendations, some boost library code, the FC++ debate), and then we can have an informed discussion.

I don't see how that contradicts what I said.

The contradiction is between your

there was just one person...who doubted the benefits [of FP]

and their

I found it disturbing that during the review a number of traditional / imperative-style C++ programmers were just not "getting it" about FP.

I take their comment as normative, that's all.

The Boost folk don't "puzzle over FP by their own admission"! At worst, some people didn't get it! A whole mess of other people did get it!

Fine. The Boost article found it disturbing and required the author to establish some of the merits of the functional programming paradigm and even at this date is not convinced that we should have asked him...i.e. still wondering, then. Make of it what you will. The more they understand FP, the happier it makes me.

the monolithic issue has nothing to do with FP or MP, it has to do with [blah blah]...Don't call out Boost bias without considering the evidence....Maybe you should consider the arguments against monolithic libraries before dismissing them.

I did not dismiss them, I merely added a counterweight. The monolithic issue touches the subject of coherence. If a library is designed to implement FP, then maybe it ruins the design to break it into pieces. Maybe, not certainly. I have already said that the monolithic charge may indeed stick.

In any case Jim, don't overreact to my comments, qualified and tentative as they are. I am only raising possibilities, not levelling charges, and I was clear about that. I like Boost and FC++. Their overlaps may not be coincidental, was my point.

it is not a good idea to break existing code

The straw-man is rhetorical. The questions are more philosophical than tactical. Indeed, Boost says of FC++:

I would like to acknowledge its authors for the influence this library has had on other boost components. I strongly encourage you to keep working to bring the innovations from FC++ into boost in the future.

So Boost wants more, er, FC++ components in the future, no matter what I may think. If Boost is pursuing FP without knowing it, then future Boost components might not end up properly factored. Whereas the FP backdrop might actually lead to more and better factorizations, having sound theoretical properties, not just a sense of smallness. Knowledge of natural theoretical fault lines helps factorization. All I'm saying is that it may help Boost to ask these questions. C++ has not enjoyed a tradition of theoretical soundness or clean design.

Hm, that is some interesting formatting. How did you obtain it?

In the HTML code I see stuff like:

style="font-size: normal; font-style: italic; color: green"

but I assume you didn't type all that in yourself and that Drupal emitted it.

Here you go.

The dodgy multicast semantics of delegates in C# is unfortunate but thankfully you can still use them like plain old closures.

delegate T Function<T>(T arg);
static Function<T> Twice<T>(Function<T> func)
{
    return delegate(T arg) { return func(func(arg)); };
}