Thanks for the encouragement. I will probably be writing an article on the Unimperative language for CodeProject.com and for the C++ Users Journal (or Doctor Dobbs Journal).

Hi Axilmar,

The MyFxn version can be used as a variable which can be used interchangeably with other Functions. The template add can not. MyFxn can also accept variable number of arguments, and it can return variable number of arguments.

A better comparison might be:

  boost::any add(boost::any a, boost::any b) {
    return any_cast&ltint>(a) + any_cast<int>(b);
  }

Which is quite similar to what Function does. In fact closer still would be:

  boost::any add(std::vector<boost::any> args) {
    return any_cast&ltint>(args.at(0)) + any_cast<int>(args.at(1));
  }

There you have the basis for Unimperative.

The more general question I think is why program functionally as opposed to imperatively. Certain algorithms are more easily expressed in terms of functional programming just as others are more easily expressed with imperative programming.

I would prefer to discuss BIL interfaces elsewhere (i.e. my blog, or a new forum topic) but here goes:

If I have N objects that I want to call from an interface reference, I must have N interface references, too.

That is not true. You might have N interface references, but that is not neccessary. Abstract base types require an extra pointer in every object. Whether or not you use them polymorphically. You only pay for references when you use them.

The MyFxn version can be used as a variable which can be used interchangeably with other Functions. The template add can not. MyFxn can also accept variable number of arguments, and it can return variable number of arguments.

Thanks for the reply. We have talked in the Heron forums...I was one of the few (as I recall, the second one) guys that have posted in the sourceforge Heron forums, a few moons ago.

My question was not about the theoritical benefits of Unimperative(i.e. functional). I know about them; yes, carrying is one of them. Easier to write, well, maybe (if you can get your head around functional programming, that is).

My question was from a project point of view: is there any project that actually requires such a functionality?

For example, let's say that I may want to store a series of randomly chosen functions (yeap, extreme case, I know) in a list to call them later. Let's say I do it with a functional style, i.e. by using Unimperative or FC++ or boost::lambda. Wouldn't I need to store the function type alongside? So I would have to do something like:

switch (fn.function_type) {
    case ADD:
        x = fn(1, 2);

    case DIV:
        y = fn(1, 2, mod);

    etc
}

I could do it in an object-oriented style, but that would be like doing the work twice: my objects could be functors anyway, instead of Function placeholders.

So, what's the need? what's the necessity? is there any practical/actual need for this certainly very clever stuff? that's what I was asking.

That is not true. You might have N interface references, but that is not neccessary.

(link to your blog? -I am lazy, I know) Of course its true...if I want to have, let's say, 40 objects at the same time, I need 40 interface references. The only time that it might be beneficial to use interface references is when I use objects on the stack, just like in the examples...which is a trivial and non-interesting case, in my opinion. When objects are polymorphic, it is because I want them to be around for a long time, and therefore allocated on the heap. If I was to use objects in the stack only, I might as well do the algorithm as a template (so the interface constraint becomes implicit).

My point is again, that I don't find any real necessity for this.

Hi again Achilleas,

Unimperative is entirely dynamically typed. It is quite different than FC++. In Unimperative you can pick an arbitrary function from a list as follows:

  
  Function FxnFromFxnList = (NthItem, _1, _2);
  Function FxnList = (MakeList, Add, Sub, Output)
  Function F1 = (Eval, (FxnFromFxnList, 0, FxnList), 7, 4 // evaluates to 11 (CD: my mistake sorry
  Function F2 = (Eval, (FxnFromFxnList, 1, FxnList), 7, 4 // evaluates to 3
  Function F3 = (Eval, (FxnFromFxnList, 2, FxnList), 7, 4 // evaluates to nil, but outputs 7 and then 4 to standard output

I am going to quell the interfaces discussion, sorry. I don't have the time nor energy to debate that particular topic.

"In this paper, we show how FC++ can be used in common OO programming tasks. We demonstrate FC++ implementations of several common design patterns (Adapter, Builder, Command, and more). Compared to conventional C++ implementations of these patterns, our implementations are either simpler (in that fewer classes/dependencies are needed), more efficient, or more type-safe (thanks to parametric polymorphism and type-inference)."

But your question might be "why the syntax?" I obviously can't speak for cdiggins, but the value that I see to it is essentially uniformity and concision: I can create a named functor (in C++ terminology, that is, rather than ML terminology) without the syntactic overhead of declaring a class, defining operator() for it, etc. and can store that in a variable of the appropriate type, pass it as a parameter, return it as a value, etc. Obviously you can do the same thing without the syntactic support, but why, for the love of C++ verbosity? Functional programming in C++ is incredibly useful; the primary downside to it seems to be that it exhibits the worst aspects of C++'s tendency to illegibility. A little syntactic sugar helps the medicine go down.^*

^*"Syntactic sugar causes cancer of the semicolon." — Alan Perlis

C++ isn't very good at entirely abstracting away from the underlying details of the language, i.e. you need to have a pretty good grasp of basic C++ to reliably be able to do the more sophisticated, high-level things. The high-level things usually depend on a mixture of features, like templates and operator overloading, while other issues like the memory allocation model can't usually be entirely ignored either, despite the ability to hide behavior inside smart pointers and so forth.

In support of my point, very few books teach you how to use e.g. STL or the more advanced template techniques (like Alexandrescu's) as a beginner, without requiring that you already have a good grasp of C++. I think that foundation is necessary.

So, my advice to someone wanting to learn C++ would be first to make sure you have good reasons for wanting to learn it — because some commitment will be required to do it properly — and then go about it the old-fashioned way: learn the basic language first, and then learn the higher-level stuff.