----- Original Message ----- From: "Joel de Guzman" <joel@boost-consulting.com>
Hmmm. lemme see...
object add_or_sub = if_(_1 == 0)[lambda[_1+_2]].else_[lambda[_1-_2]]; object f1 = add_or_sub(0)(4, 3); object f2 = add_or_sub(1)(4, 3); eval(f1); // evaluates to 7 eval(f2); // evaluates to 1
<<< Aside: I'm not quite fond of CamelCase :-) >>
The reason for the syntax of Unimperative is that I wanted to provide syntax which makes sense as a programming language independant of C++. The goal for Unimperative is to be both a subset of C++ and also an easily scripted language (ala Guile). I plan on writing a run-time interpreter for Unimperative as well. This will mean that I can both write a single Unimperative file: // factorial.uni Function Factorial = (If, (Eq, _1, 0), 1, (Mult, _1, (Eval, self, (Dec, _1)))); I can use this in a C++ program as follows: #include <unimperative> #include <iostreams> #include "factorial.uni" int main() { std::cout << any_cast<int>(eval(Factorial)) << endl; } But then I want to also be able to write: #include <unimperative> #include <fstreams> int main() { fstream("factorial.uni") > UnimperativeInterpreter; // the greater than operator is a stream redirect operator, which I was proposing earlier for boost::iostreams } Of course there is nothing preventing this possibility for Rave as well, it is just a little trickier. At this point it seems we have nearly identical tools, with different syntax. Unimperative syntax is quite deliberate, since I wanted it to be recognizable to programmers from backgrounds like Haskell, Lisp, Scheme, etc. It sounds like you are pleased with the Rave syntax as well, and won't be changing it anytime soon neither. It seems silly that we would be working on two tools with so much similarity. Can you think of any way we can help each other out, and perhaps reach some common ground?
If you've seen Phoenix2(http://tinyurl.com/6crgp), Rave is its dynamically-typed counterpart. It's really the same thing. I intend to use it to implement the new AST features of Spirit2 as well as a generic embedded runtime interpreter, say, for parsing c++.
That is quite impressive. I have to say Joel, I think your work is excellent and I love that you have been pushing the C++ envelope so much. CD