From: Joel de Guzman (joel_at_[hidden])
Date: 2004-03-01 05:12:35
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. 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 in order to make still more
complex systems. Equally important are 1 and 2.
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. 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. I vote to accept
FC++ into boost. It is a mature library from authors with lots of years
of experience in the FP field behind them.
* What is your evaluation of the design?
I think I already answered that above. The concepts of FC++ are that
of Haskell, a time-proven FP language. However, the structure of the
library itself needs to be improved. I particularly don't like its
apparently monolithic structure.
I'm not quite convinced about maintianing purity. There have been some
intriguing discussion on both sides. I'd like to see more discussion in
* What is your evaluation of the implementation?
I've seen FC++ grow. The implementation is robust and sound. However,
there are lots of room for improvement. As many have noted already,
integration with boost is weak. In addition, I notice a lot of
commonality with FC++, BLL and Spirit's Phoenix. I fervently hope that
Brian will find some time for collaboration with Jaakko and I. Right now,
I am in the process of developing Phoenix-2, which hopefully will be the
basis of the anticipated LL/Phoenix merger. There are lots of areas where
it will be best to have a common implementation (for one, return type
deduction comes to mind).
* What is your evaluation of the documentation?
In a word: poor. However, I'm sure the author(s) are aware of this and
I'm sure we'll see better documentaion in the future.
Examples speak volumes. I'd like to see more fully commented or annotated
client applications and examples from the simple to the complex preferably
hooked into the documentation.
Tutorials. I'd like to see a tutorial that hand-holds a would be user
into the FC++ realm.
* What is your evaluation of the potential usefulness of the library?
Lazy lists and lazy evaluation, in particular, is a very powerful
concept. This facility alone makes FC++ worth it. I note with
enthusism the exact-real application. It wouldn't be possible,
or at least be very difficult to code this thing without FC++
and its lazy lists.
I would like to experiment, hopefully lots of help from Brian, to
implement new forms of *smart* ASTs (abstract syntax trees) with Spirit.
I intuit that lazy-evaluation and lazy lists are a key to better ASTs in
A few years ago, I wanted to use FC++ with Spirit. One reason why I
didn't use it was because Spirit was then a boost candidate and one
requirement, as a boost candidate, is that Spirit can only use std
or boost components. Now, I am enthusuatic that FC++'s authors are
here. I hope FC++ will be part of boost.
* Did you try to use the library? With what compiler? Did you have any
FC++ requires a conforming compiler. It was a good decision for Spirit,
starting from 1.8.0 will only support conforming compilers. I haven't tried
FC++ with a lot of compilers, but, as a requirement, for Spirit to be
able to use FC++, is that it can compile on 1) g++ 3.1 and above, 2) VC7.1,
3) Comeau, 4), Intel 8, 5) CW8. Hopefully, the authors will make sure
that it does.
* How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
I think that's obvious already ;-)
* Are you knowledgeable about the problem domain?
Yes. And I hope others will give it a shot at FP. It's a really cool
paradigm that will surely make our lives, as coders, more productive.
What's not so obvious is that STL is heavily FP flavored. Let's have
more of FP in C++!
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library? Be sure
to say this explicitly so that your other comments don't obscure your
I vote to accept FC++ into boost. There are concerns, sure. However,
I don't see them as show-stoppers and surely, the authors can fix
them before incorporating them into the boost code base.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk