2010/3/11 Jonathan S. Shapiro <[email protected]>: > Philipp indirectly raised a valid question: given the goals of BitC, does it > make sense to be trying to do bring-up on CLI. I have reservations, but I > think the answer is yes.
It does make sense to bring a safe language to a popular and safe platform with a good garbage collector. And because Java still doesn't have proper tail calls, CLI is a natural choice between the two. I do believe that modifying BitC's type system to understand the full CTS is an anti-goal, so BitC could never be a full-fledged .NET language: you can't use .Net interfaces without full support for the type system. >From the marketing point of view, CLI isn't really that good: - you cannot do smooth interop with .NET - the performance suffers due to non-optimal runtime - CLI already has languages such as F#, Ada/Spark, Spec#, C++/CLI and static analysis tools such as Code Contracts (which is bundled with .NET 4) - replacing C with something safe isn't a good argument anymore On the plus side, having a high-end garbage collector does help, even if it's not optimal for functional languages. And there aren't many open source compilers for CLI langauges. To the point: I think CLI is an important target, but I do believe that the native (or LLVM, C-- or C) backend should have the priority. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
