I would just like to reiterate an important point that Joel made that parts of the C++ community don't seem to have gotten yet. FP has been a part of C++ since the STL became a staple of C++ code.

I don't think I hear during review any complains about generic adaptors e.t.c, cause these are natural to C++ even though originated in FP paradigm.

In fact, it has been a part of C++ since templates were added, since templates are by nature functional.

I am not sure what that mean. What is 'functional' in basic_string class template? May be we just need to define terms.

Anyone who thinks that FP in C++ is just a toy obviously hasn't gotten past "C with classes". I'm not directing this at you Jon, but rather using your statement as an excuse to make a point.

[...]

I second this sentiment, and let me add that accepting FC++ or adding it to the standard won't be "adding FP to C++" any more than accepting MPL amounted to "adding metaprogramming to C++". Rather, it will simply be "adding another tool for a lesser supported paradigm in C++". And since when is having more tools a bad thing? C++ is hard enough without having to reinvent the wheel every time.

May be you looked deeper into FC++, but what would left of it if you remove lazy_list from it? Almost nothing that we don't have already in some form in boost (there could be a discussion on different lambda approach and % notation). That's why I sometimes kinda associated FC++ with innovations that came with it. IOW with lazy_list and everything related to it. From that stand point I believed in my review (still do) that FC++ is just a toy not a Tool. Toy is something kids play with, Tool is something adults use to do a real job. And I do not see lazy_list as a Tool to do anything that has practical use. And I do not believe author presented example to contradict this. Gennadiy.

...

I am not sure what that mean. What is 'functional' in basic_string class template? May be we just need to define terms.

The fact that you can't change the template, just like all templates in C++.

As well as any other class/struct/union. Does it make all c++ entities 'functional'?

It is immutable, so metafunctions are strictly pure functions.

This is not nesserary good thing. I would prefer to be able to use imperetive style in metaprogramming.

Of course, basic_string doesn't perform a very interesting computation as a template, which is why it doesn't look very functional to you. But in fact, it does perform a computation. It takes a character type as input and produces a string type as output. You cannot change the input character type into the string type, which is part of why the template is functional.

In this sence definition "int const" is also 'functional'. It take type int and 'produces' different type int const.

...

[...] From that stand point I believed in my review (still do) that FC++ is just a toy not a Tool.

I wasn't talking about FC++ in particular here, but rather FP in C++.

...

Toy is something kids play with, Tool is something adults use to do a real job. [...]

I think this is a pretty unprofessional way to make your point.

If you think so. I was just used analogies you introduced.

Dave

Gennadiy.

"David B. Held" <dheld@codelogicconsulting.com> writes:

...

[...] This is not nesserary good thing. I would prefer to be able to use imperetive style in metaprogramming.

Really? You would want mutable types? So suppose I define a class type, and then you use it in one place, and I redefine it later, and you use it again? Does the fact that the ODR is broken bother you?

Careful, Dave. In general, metaprogramming doesn't need to use types as its underlying computation mechanism. Java and Python have immutable strings but imperative code; likewise it's possible to design a language with immutable types but imperative metacode. In fact, I predict that if support for concepts is built into C++ we will eventually run out of rope even for the things we do today with TMP and we will *need* a new approach. I sure hope that approach can look more like regular C++ programming than TMP does. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"David B. Held" <dheld@codelogicconsulting.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud66jde56.fsf@boost-consulting.com...

...

[...] Careful, Dave. In general, metaprogramming doesn't need to use types as its underlying computation mechanism.

Right. C++ could allow mutable values at compile time to enable metaprogramming, whilst leaving the types immutable.

...

[...] In fact, I predict that if support for concepts is built into C++ we will eventually run out of rope even for the things we do today with TMP and we will *need* a new approach. I sure hope that approach can look more like regular C++ programming than TMP does.

Why wait? Maybe we should start designing a new approach right now. ;>

I hope to work with Daveed Vandevoorde on his metacode effort at some point. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Chris Smith wrote:

Is it such a bug that TMP does not "look more like regular C++ programming"? I submit that some visual distinction is helpful (while not endorsing the current baroque stylings) for grasping when stuff is happening while reading the code.

I would not mind to have another language for metacode, like a lisp-like language or something, as long as it looks more "designed for that" than what is currently done with templates. It works, but metacode or any equivalent solution would be so much more powerful and accessible. If we could iterate in metacode through types and member functions for example, imagine how more easy it could be to make complex compile-time assertions or make bindings to other languages like Boost.Python. It could make today's TMP code looks like old (or C) code using macros to simulate templates before their introduction. Maybe it could even be designed to make macros obsolete. My only concern with the metacode effort, is that I'm not sure C++ is the best language for its own metacode. Regards, Nicolas

Gabriel Dos Reis wrote:

"Object-orientation" was invented in '60s and was deemed only of intellectual values, available only in experimental or heavy environments; C++ took it from research labs and put it in the hands of Joe Programmer. With success. Generic programming has been around since the '70s (albeit without that name) and deemed only of academic values; C++ took it and put it in the toolkit of Joe Programmer. With success. I have hopes it will eventually do the same for functional paradigm.

But is metacode (or equivalent) really about functional paradigm, or more about ways to do things easily at compile-time? You could build classes at compile-time with procedural-like code and maybe that would put the capability with more success in the hands of Jow Programmer than with something more like Lisp? I really don't know the answer... Regards, Nicolas

"David B. Held" <dheld@codelogicconsulting.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qrva55o.fsf@boost-consulting.com...

...

[...] I hope to work with Daveed Vandevoorde on his metacode effort at some point.

Do you think there would be merit in starting over from scratch? With a new language, I mean.

Of course. But adoption and interoperability are difficult issues, then. http://felix.sf.net has one interesting strategy. -- Dave Abrahams Boost Consulting www.boost-consulting.com

...

[...] This is not nesserary good thing. I would prefer to be able to use imperetive style in metaprogramming.

Really? You would want mutable types? So suppose I define a class type, and then you use it in one place, and I redefine it later, and you use it again? Does the fact that the ODR is broken bother you?

If you want to fantasize that class definitions would be constants in such languadge, while templates would be 'variables'.

...

...

...

Toy is something kids play with, Tool is something adults use to do a real job. [...]

I think this is a pretty unprofessional way to make your point.

If you think so. I was just used analogies you introduced.

I didn't refer to anyone's work as a toy. Rather, I was making the claim that a paradigm was *not* a toy. That's neutral. Calling FC++ a toy, and then saying that "kids play with toys" implies that anyone who uses FC++ is "a kid". That's insulting. Or was that a backhanded compliment that I didn't understand?

Oh, well. I don't believe I have to excuse myself if you manage to dog something insulting in completely innocent statement, especially taken out of context. But just for the record, It should've mean in context where it was used: Toy (scientific project) is something kids (theorists) are play with (work on), Tool (reusable library) is something adults (c++ practitioners) use to do a real job (in production code). Gennadiy.