Joel de Guzman <joel@boost-consulting.com> writes:
Hi,
I vote to accept FC++ into boost.
I've had the watch fc++ from its early beginnings. I have a more-or-less deeper understanding of the library. It's a fact that FC++, and especially the so called "functional programming" paradigm has influenced my preferred style of coding.
Mine too.
Functional programming is gaining acceptance. The C++ community is moving ever so deeper into FP stemming from the "STL-style" paradigm. Spirit is conceptually a collection of parser and semantic actions, both of which are purely const function objects in the FC++ sense. In FP, and in FC++, this set of parsers are called "parser combinators". Coupled with a way to combine (compose) these function objects to form a whole, we have a very important paradigm.
This style of programming is not limited to parsing. Indeed, the most powerful strategy for controlling complexity is 1) to have a set of primitive elements [axioms] 2) A means of combination 3) The means of abstraction. FP is just a means to tackle complexity in these terms. We might be confused with high-priest sounding terms such as currying, lambda, monads, closures, continuations, etc. ad nauseaum, but really, those are means to tackle no. 3 above: abstraction-- how to make complex systems act like they are just like any other primitive
That's "interoperability". Very important.**
in order to make still more complex systems. Equally important are 1
Well, without primitives, where would we sophisticates be? ;-)
and 2.
Sure, you have to have a way to put primitives together into programs.
When reviewing a language (yes, FC++ *is* a language, or more particularly, an EDSL--embedded domain specific language; sure Spirit is also an EDSL), I analyze it based on the three points I listed above.
The problem, as I see it, is that we already have a DSEL (sorry, I've never seen the "Embedded" placed first) for functional programming in Boost.Lambda that's terser, arguably easier to read, and whose idioms fit more closely with other Boost FP systems (bind, mpl), and existing C++ programming paradigms.
Not surprisingly, FC++ passes those three points-- it's based on haskell!
The FP paradigm is a cool idea. Let's have more of it.
Absolutely. I don't want *anyone* to take these comments too seriously, because I have **not** inveseted the thought that a formal review requires. As I see it, FP is a great approach; using it helps me to manage complex systems by keeping data immutable and by giving me a framework through which to view programming problems (like the STL does). FC++ is certainly an interesting study in DSEL design. If we're going to accept another functional programming language, it ought to justify itself in terms of expressivity or applicability to the problems faced by C++ programmers. I don't have a strong opinion on whether FC++ meets those criteria, but I haven't seen the clear evidence to the affirmative that I'd normally expect by this point in a review. -Dave (**) Monads, OTOH, seem to be a means to tackle the complexity that strict purity introduces in systems that would be more natural with mutable data and deterministic execution order. -- Dave Abrahams Boost Consulting www.boost-consulting.com