[boost] Re: FC++: formal review

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-01 09:19:18

Joel de Guzman <joel_at_[hidden]> 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