On Wed, Feb 25, 2004 at 10:07:12AM -0000, Andy Little wrote:
"Brian McNamara" <lorgon@cc.gatech.edu> wrote
I agree with some of your comments here about FP in the C++ setting. Specifically, absolute purity (side-effect freedom) trades away assignment and mutable variables in order to buy freedom of evaluation order, which can be useful for compiler optimizations, especially in parallel settings. Since C++ clearly has effects and assignment (and the C++ compiler is not going to employ the same kinds of optimizing transforms common in pure languages), purity is not going to be a big win here.
In that case is not FC++ rather a grand title for the library? There is a strong sense in the documentation of attempting to 'hijack' (your word) C++ for your own purposes.IOW you don't actually like C++ much. For example the
If the documentation suggests that the authors don't like C++, then this is a problem. (Do others of you have that sense?) I disagree that "not liking C++" logically follows from "hijacking". Many of the successful Boost libraries "hijack C++ for their own purposes" (e.g. boost::lambda, with expression templates, or boost::mpl, with compile-time computation). I don't think this implies that Jaakko, David A., etc. don't like C++.
lambda library uses the term function-objects rather than functoids. Its a small difference but significant. You appear to be fighting C++ at every level from the compiler upwards. You appear to have got things upside down. It would seem more appropriate to call C++ process to do the dirty work from within the pure FP, rather than embedding FP in C+. That would be interesting, and would allow each language to perform at its best.
It is not clear to me that one way is "better" than the other. (Both pure FP nested within an impure language and impurities nested within pure FP are interesting, IMO.)
But there's more to FP than just purity. Higher-order functions, lambda, and closures let you write code in a more applicative style, which can raise the overall level of abstraction.
Ok I am trying to find where or why I might find this library useful. Higher order functions are essentially functions that manipulate other functions? Say to build up an expression from some token, object sequence either(both) at compile time or(and) at run time according to some rule. Presumably I am allowed to manipulate objects as well as functions in FC++.?
Yes and yes.
As I understand lambda in Context of C++, it is basically an alternative syntax to writing a function in the traditional (C/C++) sense, and achieves the above?
Kinda, yes. Here's an analogy that's rooted in C++. Consider iterator adapters. They let us view a container (or sometimes multiple containers) through a "lens" that adapts our view of what's in the container. For example, we might have a vector of pointers (vector<Obj*>), but we are interested in the objects pointed at by the pointers. So we use an iterator adapter which automagically dereferences the pointers, so that the value_type of the iterators is "Obj" rather than "Obj*". When our iterators "aren't quite right" for what we want to do, we can use iterator adapters to "fix" them for our current purposes, rather than writing entirely new iterator classes or writing special-purpose code (like an Obj*-comparator) to deal with things being not-quite-right. Now, higher-order functions (HOFs) are like "function adapters". If you have a function (or sometimes multiple functions) which almost does what you want, you can simply use HOFs to adapt them (via composition, currying, binding, etc.), rather than writing entirely new functions or writing special-purpose code to deal with the situation.
Raising the level of abstraction seems to be an end in itself. And for simplicity it requires that all entities conform. The C++ abstraction mechanisms make allowances for entities that dont conform.That is it can reach in at a low level. How does FP see non conforming entities.. Are they an impurity which is banned?
I am not sure exactly what you are asking, but... FC++ cannot prevent you from creating functoids with side-effects. If you do so, it is up to you to make sure the effects "happen at the right time" (just as always in normal C++ code). FC++ currently doesn't allow reference parameters. However discussions in another thread appear to have found a solution which would loosen this constraint. If by "non conforming entities" you mean "functions with side-effects", for the most part, FC++ cannot see/detect these things at all.
I do not know what 'comprehensions are. . I like (think in terms of ) objects(C++ classes). They play a far more important role in my day to day programming than functions. but they appear to be anathema to FP. Hence it seems to be an impoverished language. Its good with the abstractions . but cant deal very well with 'meat'.
Objects are not anathema to FP. (But _mutable_ objects are anathema in _pure_ FP.) Both paradigms (OOP and FP) deal with both data and behavior. In OOP, the data (objects) are the focus. In FP, the behaviors (functions) are the focus. A lot of this discussion may be "too abstract" to be useful. To make things more concrete, in a little while I will post a short example illustrating some differences of how the paradigms deal with data and behaviors. -- -Brian McNamara (lorgon@cc.gatech.edu)