as well. But if we're going to do this, we may as well define a new "FC++ language" in its own right and write a compiler which converts this into C++ code.
Yes! I fully back this approach, please let me know if you start a project like this. I would propose to use a Haskell-like language as the "source", because it is nice, clean and FC++ is modeled after it anyway. This would simplify the tedious, repetitive and error-prone writing of FC++ signatures. I would only vote for making the language strict, not lazy by default, or perhaps controlling the strictness the way Clean does, since I found that (unwanted) laziness was slowing my programs tremendously at getting rid was difficult (for me) and made the programs ugly. The seamless interoperability with C++ would be a clear win for me, since there is so many libraries already available for C++ and besides, some parts of the program might be better suited for imperative programming. Yes, I had a look at the Felix programming language and I liked it, but I found it too Ocam-like - I find it's approach to genericity (C++ templates) using modules much heavier than in Haskell, where you get genericity without any extra effort, unless you ask for specialized version. Yours, Jan -- ------------------------------------------------------------------------- Jan Kybic <kybic@ieee.org> tel. +420 2 2435 7264 or <kybic@fel.cvut.cz>, http://cmp.felk.cvut.cz/~kybic