1. Types are not template-ized. I don't want everything to be a double.

This is an interesting point. My goal so far has been to prioritize simplicity above all. The purpose of the toolkit is for letting people write arithmetic equations easily. In light of that, I think sticking with doubles makes sense. 2. Perhaps variables should be first-class objects, not just placeholders in BLL. Maybe... The whole idea, though, is basically to macro-ify some boost::lambda::bind operations so that you let lambda do the heavy lifting of actually combining all the functors together. 3. (Style not substance) Many of the type and function names aren't very clear. Examples: go() and MapType; Sure; style can always be worked on. Right now, it's not very well-documented anyway so some of the implementation may not be intuitive.

I'm thinking the client syntax should be something more like this: expression expr; variable<double> x; variable<int> y; expr = x + y; double v = expr; // would throw because x and y are unassigned x = 10; y = 20; v = expr; // assigns 30 to v

Well, this is an interesting idea but it runs contrary to the metaphor I want. In the above example, the variables 'x' and 'y' work as global variables. I want the user to have to pass x and y directly to the equation. There's another reason for this: If one equation uses another equation, you have to make sure the equations use the right variables. Consider this: Equation f1 = x + y Equation f2 = z + f1(x -> z, y -> z) print f2(9) If you had global-level variables, then it would be difficult to make the above example work properly (passing z on as x and y when f2 invokes f1).. --Steve