> 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 <[EMAIL PROTECTED]> tel. +420 2 2435 7264
or <[EMAIL PROTECTED]>, http://cmp.felk.cvut.cz/~kybic
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
