Re: [boost] FC++: formal review

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-03-01 05:12:35

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. 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
   this area.

* 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
   Spirit.

   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
   problems?

   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
   overall opinion.

   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.

Cheers,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net