Re: [boost] Re: Re: Re: Re: full functoids

From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-25 12:24:40

On Wed, Feb 25, 2004 at 10:07:12AM -0000, Andy Little wrote:
> "Brian McNamara" <lorgon_at_[hidden]> 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_at_[hidden])